Errors when compiling kernel, what do they mean?
 

Having monster problems recompiling Mandy 8.1 for SCSI support. So that I don't just have to keep going in an messing around with the config, then doing all the makes over and over again in the forlon hope it might actually work at the millionth attempt, how do you decipher what the errors mean?

eg

Leaving directory /usr/src/linux2.4.8/drivers/block
*** [__modsubdir_block] error 2
Leaving directory /usr/src/linux2.4.8/drivers
*** [__modsubdir_drivers] error 2

all this after a load of undeclared vmalloc.h:xx type messages.

I take it recompiling the kernel is possible, it's not just some wind up to occupy fools like me for a while? <g>

The stock kernel on any given distro is a beast to get to compile right as the defaults they have left you when you start changing things through menuconfig or Xconfigur, or whatever, are so bloody hard to keep from creating accidental dependency mistakes.

Right now my record is this:
1 for >10 on recompiles of distro supplied kernels. Oddly enough that 1 was on Mandy.

30+ for 30+ on compiles from pure, pristine, fresh as the laundry kernel source from www.kernel.org.

Mandy will complain bitterly after you compile a new kernel for it. You will probably have to recompile anything else in /usr/src, typically ALSA, and possibly PCMCIA if this is a laptop. Wait, a laptop with SCSI... probably not.

Luck,

Finegan

>> The stock kernel on any given distro is a beast to get to compile right as the defaults they have left you when you start changing things through menuconfig or Xconfigur, or whatever, are so bloody hard to keep from creating accidental dependency mistakes. <<

Hmmm, so what you're saying is that the menuconfig doesn't take what the current state of your kernel is and start there?

>> Right now my record is this:
1 for >10 on recompiles of distro supplied kernels. Oddly enough that 1 was on Mandy.

30+ for 30+ on compiles from pure, pristine, fresh as the laundry kernel source from www.kernel.org. <<

Aye carumba. It takes so long too! And the bloody thing always failed on the last leg of the whole thing!

>> Mandy will complain bitterly after you compile a new kernel for it. You will probably have to recompile anything else in /usr/src, typically ALSA, and possibly PCMCIA if this is a laptop. <<#

Don't understand that bit. Care to expand?! Bear in mind, the programming I've done in the past has been mostly assembly language for embedded processors. Have done a little embedded C, but try to avoid the damn language as much as possible! <g>

>> Wait, a laptop with SCSI... probably not. <<

The SCSI is for a USB camera, not an actual SCSI card. If a had a SCSI card, Mandy would've done it on install I'd have thought!

The kernel configs done by the hackers at Mandrake are probably done by hand, line by line, with 'configure'. So, if you change some setting with menuconfig, it usually leaves some neurotic dependancy hanging. That's what I've noticed the one time I got serious about 'why doesn't this thing compile!'.

The kernel compile goes through the bits in the order you see them in menuconfig... USB is at the end, so that's where it chokes on those dependancy juggles.

No worries, I should have been less colloqiual. Oh, and I've never even dealt with something as low level as asembly before... you're way ahead of me on this.

Mandrake's entire init-script set up, everything in rc.d and init.d is built to handle the kernel that it comes with. If you upgrade kernels, they want you to do it through RPMs. RH is even worse, you have to really work through the installation to get it to install a compiler. When you change the kernel, for instance build something directly into the kernel instead of as a module, the usual depmod -a doesn't keep Mandrake from complaining that what it wants isn't there. When I boot my Mandrake 8.0 laptop, I still get a mess of complaints about missing nfs.o modules for instance. Well, when I recompiled the kernel, I stuck them in the kernel, and its trying to load the module. Everything works just fine, but I'm too slack to go and hack out whatever is trying to load the mod.

Also, Mandrake, as opposed to RH, is still using a lot of external to the kernel packages that have to be compiled against the kernel. The ALSA sound stuff is one example, whereas the pcmcia-cs package is another. You just have to recompile it against a new kernel. My Mandrake 8.0 installation is actually running 2.4.14 although it shipped with 2.4.3. Everything works fine, but I still get a bunch of those init 'ghost' errors.

Probably, I hope... I've only ever done SCSI with good ol'Slack, which always gives you a slim starting kernel because the idea behind the distro is that a re-compile is one of the first things you're going to do.

Offhand, is this one of those bizarratudes where the USB camera requires SCSI emulation?

-Cheers,

Finegan

Now you metntioned thr alsa stuff, I've done a Google trawl and found a few places where it says things like:

"After you upgrade your kernel, you probably need to recompile the ALSA drivers. If they are still in the original /usr/src directory, then please do not forget to issue a make clean before you do the ./configure, make, make install thing. "

Problem is, I haven't a clue *how* to recompile these drivers! One thing I've noticed is that in the:

/lib/modules/2.4.8-26mdk/pcmcia

and

/lib/modules/2.4.8-26mdk/alsa

directories all the files are o.gz, whereas in the others (/lib/modules/2.4.8-26mdk/kernel/net etc), they're .o. I'm assuming the .o files are object files - the gz are zipped aren't they? Is it something to do with these files needing to be unzipped? Could it be that simple?

If not, I just don't know how to compile them!

Also, I don't have a kernel-header*.rpm file on my Mandy CD. Is that a problem? I know that normally a C program wouldn't compile without the headers, but this gets so far down the line, I'm sure it'd have fallen over before it was a grave problem.

Your assumption about it being this utterly bizarre need for SCSI to make the camera work is correct. I don't know anywhere near enough about the innards of Linux to know why this is nescessary. SCSI *emulation* is already installed, but when I do the

/mount /dev/sda1 /mnt/fuji

thing, it say, device sda1 doesn't exist.

Wish my wife'd never bought me the damn camera now! Or that I wasn't so stubborn and would run it on Windoze!

>> Oh, and I've never even dealt with something as low level as asembly before... you're way ahead of me on this. <<

People think I'm a luddite/geek/weirdo liking assembly so much!

Thanks for all this help, sorry to be so null! ;-)

For some reason they were able to include a kernel feature recently to compress all of the un-used kernel modules. Mandrake and RedHat have picked up on. It doesn't really save much space in the long run, and actually seems quite silly when the typical RH install these days is at lteast a 1.5Gb.

Yeah, after you get the kernel to compile, in order to fix alsa, just cd into the alsa dir:

make clean
./configure
make
make install

Alsa goes together really easily. I don't know about the kernel-header include file. All it should ever take to compile a kernel is glibc, a shell, and a working compiler. The rest is in the source, I think.

I'm not absolutely certain thats how you're supposed to mount a digicam drive, but mine is a Vivitar and about the only thing I still boot to windows for... well, okay, Diablo II. I'll poke around on digicam resources when I get back from lunch.

Honestly, try compiling 2.4.16 or 17. Weed out the features you don't need, it'll cut down compile times drastically.

Cheers,

Finegan

>> Yeah, after you get the kernel to compile, in order to fix alsa, just cd into the alsa dir:

make clean
./configure
make
make install <<

Aftern unzipping it? There's *only* .gz files, no make files, so it won't allow me to do that and can't configure or anything.

Off to play footy - at this time of night, yes!

Thanks again for all the help. :-)