LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   Slackware's recent gcc upgrades (https://www.linuxquestions.org/questions/slackware-14/slackwares-recent-gcc-upgrades-394245/)

LocoMojo 12-18-2005 02:59 PM

Slackware's recent gcc upgrades
 
I compiled my own 2.6.13 kernel a while back and recently I upgraded my gcc packages from ggc-3.3.6 to gcc-3.4.5. Today I went to upgrade my Nvidia driver from 7676 to 8174, but it kept failing due to wrong kernel sources. This had me flustered for a while because I had upgraded to 7676 after I compiled my 2.6.13 kernel with no problems and I haven't touched my kernel since, but then I figured out that I was having problems upgrading my Nvidia driver because I compiled my kernel with the older gcc version. I downgraded to gcc-3.3.6 and upgraded my Nvidia driver with no problems.

My question is, are you supposed to recompile your kernel every time you upgrade your gcc version, especially if you want to be able to compile future drivers?

Also, I compiled the new Gaim 2.0 beta last night using using gcc-3.4.5 and the kernel sources built with gcc-3.3.6 and it compiled with no problems. Why was Gaim able to compile, but not the Nvidia driver?

Thanks in advance.

LocoMojo

cathectic 12-18-2005 03:57 PM

In my experience (at least with Alsa), any modules dependent on the kernel need to be compiled with the same GCC version as the kernel (e.g. you can't build Alsa with GCC 3.4 with a kernel built using 3.3). I believe the same applies to the nVidia drivers.

On the other hand, Gaim is not directly dependent on the kernel version, so does not have this problem.

MMYoung 12-18-2005 05:02 PM

Quote:

Originally Posted by LocoMojo
I compiled my own 2.6.13 kernel a while back and recently I upgraded my gcc packages from ggc-3.3.6 to gcc-3.4.5. Today I went to upgrade my Nvidia driver from 7676 to 8174, but it kept failing due to wrong kernel sources. This had me flustered for a while because I had upgraded to 7676 after I compiled my 2.6.13 kernel with no problems and I haven't touched my kernel since, but then I figured out that I was having problems upgrading my Nvidia driver because I compiled my kernel with the older gcc version. I downgraded to gcc-3.3.6 and upgraded my Nvidia driver with no problems.

My question is, are you supposed to recompile your kernel every time you upgrade your gcc version, especially if you want to be able to compile future drivers?

If the gcc upgrade is a minor upgrade, say from 3.3.6 to 3.3.x, you would've been OK. Since this is a major upgrade, from 3.3.x to 3.4.x, you will need to recompile your kernel using the newer gcc to compile anything that goes into the kernel, such as video drivers.
Quote:

Originally Posted by LocoMojo
Also, I compiled the new Gaim 2.0 beta last night using using gcc-3.4.5 and the kernel sources built with gcc-3.3.6 and it compiled with no problems. Why was Gaim able to compile, but not the Nvidia driver?

As cathectic stated, Gaim doesn't add anything to the kernel so it would compile fine. The only programs you will have problems with are those that make "hooks" (for lack of a better term) to the kernel or to kernel modules.

HTH,
MMYoung

LocoMojo 12-18-2005 07:31 PM

Cathetic and MMYoung,

Thanks to the both of you for your replies.

Makes sense that you would need to recompile your kernel for modules that are inserted into the kernel itself, but not for software that isn't part of the kernel.

I went ahead and upgraded my kernel to 2.6.14.4. I compiled it using gcc-3.4.5 then I rebuilt my Nvidia module and it worked like a charm. I also had to recompile my pwc module (for my webcam) and that's working fine too. Funny though, I didn't have to recompile my Alsa driver, I only had to redo 'alsactl store' to save my settings and it is working fine.

I never knew that you had to recompile your kernel after major gcc upgrades...learn something new everyday.

Thanks for your help.

LocoMojo

MMYoung 12-18-2005 08:19 PM

Quote:

Originally Posted by LocoMojo
Funny though, I didn't have to recompile my Alsa driver, I only had to redo 'alsactl store' to save my settings and it is working fine.

That's because ALSA is part of the kernel, so when you recompile your kernel you recompiled your ALSA drivers as well.

Later,
MMYoung

LocoMojo 12-18-2005 10:38 PM

Quote:

Originally Posted by MMYoung
That's because ALSA is part of the kernel, so when you recompile your kernel you recompiled your ALSA drivers as well.

You're right because I remember seeing the modules in .config:

Quote:

~/build/linux-2.6.14.4$ less .config | grep -i snd_emu10k1
CONFIG_SND_EMU10K1=m
CONFIG_SND_EMU10K1X=m
But now I'm confused because I also have:

Quote:

/var/log/packages$ ls alsa*
alsa-driver-1.0.10_2.4.32-i486-1 alsa-lib-1.0.10-i486-1 alsa-oss-1.0.10-i486-1 alsa-utils-1.0.10-i486-1
So what's going on here? Are you saying that when I recompiled my kernel it used the sources in the above packages to create the modules?

If so, I just learned something else new today!

One thing though, probably a very dumb question, but how did the kernel compilation know where to find the alsa sources to build the modules? I didn't specify the path to the alsa sources nor is there anything about alsa in my env.

Pkgconfig?

LocoMojo scratches his head

slackb0t 12-18-2005 10:49 PM

I upgraded to the new gcc using slapt-get.. i would like to go back to the older version b/c I don't won't to recompile the kernel etc... and I too did not realize that the upgrade would require a new kernel...

So what is the best and easiest way to go back??

LocoMojo 12-19-2005 12:57 AM

Quote:

Originally Posted by slackb0t
I upgraded to the new gcc using slapt-get.. i would like to go back to the older version b/c I don't won't to recompile the kernel etc... and I too did not realize that the upgrade would require a new kernel...

So what is the best and easiest way to go back??

I've never used slapt-get, but if you have the old gcc packages just open up the console then:

Quote:

cd to directory containing packages
su
<password>
upgradepkg gcc-<version>.tgz
This will remove the new gcc package and replace it it with the older package. Though you are using 'upgradepkg', you are really downgrading to a lower version of gcc.

Good luck.

LocoMojo

MMYoung 12-19-2005 05:06 AM

Quote:

Originally Posted by LocoMojo
So what's going on here? Are you saying that when I recompiled my kernel it used the sources in the above packages to create the modules?

Nope, the ALSA is now included with the kernel. The "generic" kernel packages that Slackware provides do not include ALSA so Pat provides an individual package for the drivers. If you will notice the ALSA driver package actually SPECIFIES the kernel version that it is for (2.4.32) and so those drivers will ONLY work with the 2.4.32 kernel.
Quote:

Originally Posted by LocoMojo
One thing though, probably a very dumb question, but how did the kernel compilation know where to find the alsa sources to build the modules? I didn't specify the path to the alsa sources nor is there anything about alsa in my env.

No such thing as a dumb question, unless it's the one that doesn't get asked, IMHO.

The ALSA source has been included with the kernel for a while now. When you built your new kernel it compiled the modules and installed them to /lib/modules/new.kernel.number/kernel/sound/cardname. The only time you have to compile ALSA drivers individually is if a new release comes out between kernel updates, and then just if you want to or not.

Later,
MMYoung

LocoMojo 12-19-2005 08:39 AM

Quote:

Originally Posted by MMYoung
Nope, the ALSA is now included with the kernel. The "generic" kernel packages that Slackware provides do not include ALSA so Pat provides an individual package for the drivers. If you will notice the ALSA driver package actually SPECIFIES the kernel version that it is for (2.4.32) and so those drivers will ONLY work with the 2.4.32 kernel.

Teach me to pay attention to the packages, will ya? :D

Here I was running 2.6.X kernels with an Alsa driver package meant for 2.4.X kernels thinking I was all that and a bag of chips, heh.

Quote:

No such thing as a dumb question, unless it's the one that doesn't get asked, IMHO.
Thanks! I was real close to sulking off feeling like a total idiot. Glad you're alright with dumb questions.

Quote:

The ALSA source has been included with the kernel for a while now. When you built your new kernel it compiled the modules and installed them to /lib/modules/new.kernel.number/kernel/sound/cardname. The only time you have to compile ALSA drivers individually is if a new release comes out between kernel updates, and then just if you want to or not.
Now what about the alsa-lib, alsa-utils, and alsa-oss packages? I still need those, right?

I wonder what else I have on my system that I don't need. I need to go over my installed packages again and get rid of the ones I'm not using. I'd also like to pare down my kernel (I already did, somewhat) to reduce the kernel size and unnecessary security holes, but it's difficult to know what I need and don't need.

Am I right in thinking that unused modules don't pose any security holes? I mean, if there's a security hole with X module, but I'm not using it, then there's no security problems with that particular module? Or as long as that module is sitting around it could be used maliciously by someone with an agenda?

Am I also right in thinking that unused modules don't contribute to the kernel's resource usage? Or does the kernel scan through all the modules in its "inventory" and hold that inventory in memory somewhere?

Thanks for all your help.

LocoMojo

MMYoung 12-19-2005 06:52 PM

Quote:

Originally Posted by LocoMojo
Now what about the alsa-lib, alsa-utils, and alsa-oss packages? I still need those, right?

Yep, they're always good to have around ;).
Quote:

Originally Posted by LocoMojo
Am I right in thinking that unused modules don't pose any security holes? I mean, if there's a security hole with X module, but I'm not using it, then there's no security problems with that particular module? Or as long as that module is sitting around it could be used maliciously by someone with an agenda?

As far as I know, if it ain't being used it ain't a threat. I'm not sure about someone hacking into your PC and gaining access to any spare modules laying around. I suppose it *could* happen, I've learned a long time ago to never say never, but I can't really say for sure.
Quote:

Originally Posted by LocoMojo
Am I also right in thinking that unused modules don't contribute to the kernel's resource usage? Or does the kernel scan through all the modules in its "inventory" and hold that inventory in memory somewhere?

If it ain't needed then it ain't used so they don't consume memory/cpu resources, just hard drive space.

Later,
MMYoung

kaon 12-19-2005 07:20 PM

So in such case everything needs to get recompiled to ensure everything functions properly, right? If so, it would be tedious to do so since you may left some libraries compiled against the old one.

Correct me if I am wrong.


All times are GMT -5. The time now is 01:00 PM.