Linking in libgcc

[uglyoldbob]

I am using the autotools to compile my kernel and OS.
I have successfully compiled a cross-compiler. I call configure so that it uses my cross-compiler to compile everything. I even setup distcheck so that it call configure and use the cross-compiler.
I can call
./configure --host=i386-elf-doors
make
and it works fine
but make distcheck does not work.

Here are the relevant makefile.am lines. This is an issue of linking in libgcc.
Here is the hard way to do it (which doesn't work right with make distcheck)
kernel_LDADD = libgcc.a
libgcc.a: $(shell $(CC) -print-libgcc-file-name)
cp $(shell $(CC) -print-libgcc-file-name) $(srcdir)/libgcc.a

The easy way to do it would be like this.
kernel_LDFLAGS = -lgcc -T $(srcdir)/x86/link.ld
But I still get undefined references to the functions defined in libgcc.a when I do it that way (__divdi3 and others).

[JamesM]

I am using the autotools to compile my kernel and OS.
I have successfully compiled a cross-compiler. I call configure so that it uses my cross-compiler to compile everything. I even setup distcheck so that it call configure and use the cross-compiler.
I can call
./configure --host=i386-elf-doors
make
and it works fine
but make distcheck does not work.

Here are the relevant makefile.am lines. This is an issue of linking in libgcc.
Here is the hard way to do it (which doesn't work right with make distcheck)
kernel_LDADD = libgcc.a
libgcc.a: $(shell $(CC) -print-libgcc-file-name)
cp $(shell $(CC) -print-libgcc-file-name) $(srcdir)/libgcc.a

The easy way to do it would be like this.
kernel_LDFLAGS = -lgcc -T $(srcdir)/x86/link.ld
But I still get undefined references to the functions defined in libgcc.a when I do it that way (__divdi3 and others).

Get rid of -no-stdlib from your CFLAGS.

[uglyoldbob]

Removing -nostdlib from the compile options works, but it also causes libraries I don't want to be brought in (-lstdc++ -lm -lg -lc). I can add -nostartfiles to get rid of the crt stuff, but some of the crt files (crtend.o and crtbegin.o) might be usable in the kernel. I am trying to find a "prettier" method of doing the C/C++ startup and exit routines. Would creating a kernel-level crt0.o object and linking with that work? Or am I just wasting my time?
The gcc docs seems to say that nostdlib and lgcc can be specified at the same time and it '"should"' work, but it doesn't. I have a feeling it may be the order in which the arguments are passed to the linker (lgcc should probably be passed after nostdlib but it not). Slight tickling of my automake configuration might be in order? I can provide output of the link phase with the -### flag if it would help any. I would post it now but it is a lot and would just add more clutter.
I was under the impression that you were only supposed to use libraries from the "system independent" directory in the kernel and the rest of it was fair game for "user" programs.
For my setup that directory is /usr/local/lib/gcc/i386-elf-doors/4.3.2.
The "system dependent" directory should be for user programs right (/usr/local/i386-elf-doors/lib on my system).

Also, I am trying to setup the build system and everything else so that it can be ported relatively easily to another architecture.

[quok]

Removing -nostdlib from the compile options works, but it also causes libraries I don't want to be brought in (-lstdc++ -lm -lg -lc). I can add -nostartfiles to get rid of the crt stuff, but some of the crt files (crtend.o and crtbegin.o) might be usable in the kernel. I am trying to find a "prettier" method of doing the C/C++ startup and exit routines. Would creating a kernel-level crt0.o object and linking with that work? Or am I just wasting my time?
The gcc docs seems to say that nostdlib and lgcc can be specified at the same time and it '"should"' work, but it doesn't. I have a feeling it may be the order in which the arguments are passed to the linker (lgcc should probably be passed after nostdlib but it not). Slight tickling of my automake configuration might be in order? I can provide output of the link phase with the -### flag if it would help any. I would post it now but it is a lot and would just add more clutter.
I was under the impression that you were only supposed to use libraries from the "system independent" directory in the kernel and the rest of it was fair game for "user" programs.
For my setup that directory is /usr/local/lib/gcc/i386-elf-doors/4.3.2.
The "system dependent" directory should be for user programs right (/usr/local/i386-elf-doors/lib on my system).

Also, I am trying to setup the build system and everything else so that it can be ported relatively easily to another architecture.

If you use -nostdlib and -lgcc, make sure that -nostdlib is listed before -lgcc on the command line. I've seen some versions of binutils that would wipe -lgcc if it was specified before -nostdlib. Also remember that by default symbols in libraries are only resolved if they have already occurred when the library is linked. That is to say, if you have:

Code: Select all

ld ... file1.o file2.o libgcc.a file3.o ...

then only file1.o and file2.o will get their external symbols resolved, and anything in file3.o that calls something in libgcc.a will still be undefined. To fix this, specify -lgcc and other libraries as the last things on the command line, or use --start-group and --end-group.

[uglyoldbob]

Here is what I am trying in my makefile.am.

kernel_LDFLAGS = -nostdlib -lgcc -T $(srcdir)/x86/link.ld

I posted on the autotools mailing list. Hopefully someone over there has seen this on a cross compile configuration before. I think it is definitely an ordering problem with the way automake does it and the way I have it configured. I just have to figure out how to get automake to do it the "right" way.