Problem with ld, static libs, and BareBones...

[Colonel Kernel]

I'm trying to set up a workable source tree and build environment for my OS, and I'm having a small problem. I've started with the BareBones C example, and added a bit of code to display a "Hello Kernel" message. Now, I want to start separating things into logical subsystems, and I want each subsystem to build into a static lib. The idea is that all the libs will link into a single kernel image.

The problem is, the loader.o file from BareBones cannot be in a lib -- if it is, I get a linker warning and a 0-byte file. Here's what I'm doing (libArchitecture.a contains video.o, libExecutive.a contains main.o, and libBoot.a contains loader.o):

Code: Select all

21: Bruce_orion$ /usr/cross/bin/i586-elf-ld -L./ -lBoot -lExecutive -lArchitecture -T ../Build/precurnl.ld -o test
/usr/cross/bin/i586-elf-ld: warning: cannot find entry symbol _loader; not setting start address

The referenced linker script is virtually identical to the BareBones C example (just added an OUTPUT_FORMAT(binary) to it). If I replace -lBoot with loader.o (assuming it is in the current directory), it works fine.

Any ideas...? One thing I noticed is that if I put -lArchitecture before -lExecutive (and loader.o instead of -lBoot), I get linker errors because of the one-pass manner in which ld searches archives. So, I figured putting -lBoot first would solve it, but no dice. ???

I've tried this with both Cygwin and Linux (Mandrake 9.2), using a cross-compiler I built on each (from the OSFAQ, of course ) and the same problem happens on both (which I would expect).

[Dreamsmith]

The problem is your compile line has nothing but libraries, no code. The linker is smart enough to only pull in code from libraries if you actually use it in the program you're linking. Can you imagine the size of an executable if the entire libc needed to be attached to it just because you called fputs? Any linker worth using is going to aggressively drop any code from libraries that isn't being used by the program being linked. Specifying something as a library on a link line rather than as object code is a command not to include it, but to only include what you need out of it -- including nothing at all if nothing is called in it. If you don't specify any code at all, it can safely drop every bit of library code. End result? A zero byte executable! This is not an error, this is exactly what you asked for -- you're linker would be broken if it gave you anything more than that. Saying "loader.o" means "include all this code in my program". Saying "-lBoot" means "I may need parts of this, but for gods' sakes don't attach the whole bloody thing if I don't need it". The linker's just doing what you asked...

[Colonel Kernel]

Doh! I realize that it's going to try and drop unused code, but I was led astray by the fact that this seems to work:

Code: Select all

[~/osdev/precursor/Lib]
10: Bruce_orion$ /usr/cross/bin/i586-elf-ld -L./ -lExecutive -lArchitecture -o test
/usr/cross/bin/i586-elf-ld: warning: cannot find entry symbol _start; not setting start address

[~/osdev/precursor/Lib]
11: Bruce_orion$ vdir
total 3
-rw-r--r--    1 Bruce    None          846 Sep 20 23:29 libArchitecture.a
-rw-r--r--    1 Bruce    None          978 Sep 20 23:29 libExecutive.a
-rwxr-xr-x    1 Bruce    None          453 Sep 20 23:30 test

That executable isn't 0 bytes, but that's because I forgot the --oformat=binary. The 453 bytes must be the elf header. Once again, doh.

[Dreamsmith]

Heh. I know what you're trying to do, and I've even done it before, but I don't remember how off the top of my head. There's a command line option though to perform a "partial link", where you link together a bunch of .o files, but the end result is just another .o file, which can then be linked into a program. I think that's what you really want here, rather than making libraries out of this stuff.

[Neo]

There's a command line option though to perform a "partial link", where you link together a bunch of .o files, but the end result is just another .o file, which can then be linked into a program. I think that's what you really want here, rather than making libraries out of this stuff.

Would that be the '-r' option with 'ld'. It generates relocatable output.

[Solar]

If you fancy a bit of GRUB trickery, you could load your "libs" as individual kernel modules... look it up in the GRUB docs.

[Colonel Kernel]

If you fancy a bit of GRUB trickery, you could load your "libs" as individual kernel modules... look it up in the GRUB docs.

I'm saving that one for things like the boot filesystem driver and machine-specific stuff...