OS-specific toolchain and shared libraries

[mariuszp]

A month or so ago when I was creating a cross-compiler for my OS (glidix) it didn't automatically add crt0.o and such to the executable, so to force it to include them, I modified gcc/config/glidix.h and added a STARTFILE_SPEC and ENDFILE_SPEC at the end, here's what it looks like now:

Code: Select all

/* Useful if you wish to make target-specific gcc changes. */
#undef TARGET_GLIDIX
#define TARGET_GLIDIX 1
 
/* Don't automatically add extern "C" { } around header files. */
#undef  NO_IMPLICIT_EXTERN_C
#define NO_IMPLICIT_EXTERN_C 1
 
/* Additional predefined macros. */
#undef TARGET_OS_CPP_BUILTINS
#define TARGET_OS_CPP_BUILTINS()      \
  do {                                \
    builtin_define ("__glidix__");      \
    builtin_define ("__unix__");      \
    builtin_assert ("system=glidix");   \
    builtin_assert ("system=unix");   \
    builtin_assert ("system=posix");   \
  } while(0);

#undef ENDFILE_SPEC
#define ENDFILE_SPEC "crtend.o%s crtn.o%s"

#undef STARTFILE_SPEC
#define STARTFILE_SPEC "crt0.o%s crti.o%s crtbegin.o%s"

It now successfully builds static executable, but refuses to build a shared library, because when I run:

Code: Select all

x86_64-glidix-gcc -shared -o out/lib/libc.so out/lib/libc.a

("libc.a" does NOT contain the crt0.o files; they are seperate files installed under /glidix/lib), it tries to link crt0.o into libc.so, and fails due to undefined reference to 'main'. Is there something I am doing horribly wrong? And if so, what is it?

[gerryg400]

My command line looks like this

Code: Select all

x86_64-anvil-gcc -m64 -Wl,-e_start -shared -o libc.so *.o 

So I think your command line is okay. I specifically link in a special version of the start-up code in that list of *.o files because my libc.o is also my ld loader but you needn't do that.

The difference is likely in your STARTFILE_SPEC. You need to tell it to leave out the crt1.o file when you're building shared.

Code: Select all

#undef  STARTFILE_SPEC
#define STARTFILE_SPEC "%{!shared:crt1.o%s} \
   crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"

The first bit tells gcc not to include crt1.o if the -shared option is supplied

[mariuszp]

Thank you for your help. It also seems that when I create static executable, they are linked so that there is only one program header, which stores all code, data and bss in a single segment, with read-write-execute permission. Does anyone know why it may be creating this one segment instead of 2? There should be, by default, a segment for code (read-and-execute) and for data (read-and-write).

[mariuszp]

OK, I managed to get it to link the shared library but it was linked as an executable instead of a DYN...

EDIT: I used the -v flag and it turns out that GCC is not passing the -shared option to the linker:

Code: Select all

mariusz@mariusz-Satellite-A660:~/Madd/Glidix/glidix/userspace/libc/out/lib$ x86_64-glidix-gcc -v -shared -o libc.so libc.a
Using built-in specs.
COLLECT_GCC=x86_64-glidix-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-glidix/4.9.0/lto-wrapper
Target: x86_64-glidix
Configured with: ../glidix-gcc/configure --target=x86_64-glidix --prefix=/glidix/usr --exec-prefix=/usr --with-sysroot=/glidix --enable-languages=c --disable-nls
Thread model: single
gcc version 4.9.0 (GCC) 
COMPILER_PATH=/usr/libexec/gcc/x86_64-glidix/4.9.0/:/usr/libexec/gcc/x86_64-glidix/4.9.0/:/usr/libexec/gcc/x86_64-glidix/:/usr/lib/gcc/x86_64-glidix/4.9.0/:/usr/lib/gcc/x86_64-glidix/:/usr/lib/gcc/x86_64-glidix/4.9.0/../../../../../usr/x86_64-glidix/bin/
LIBRARY_PATH=/usr/lib/gcc/x86_64-glidix/4.9.0/:/usr/lib/gcc/x86_64-glidix/4.9.0/../../../../../usr/x86_64-glidix/lib/:/glidix/lib/
COLLECT_GCC_OPTIONS='-v' '-shared' '-o' 'libc.so' '-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-glidix/4.9.0/collect2 -plugin /usr/libexec/gcc/x86_64-glidix/4.9.0/liblto_plugin.so -plugin-opt=/usr/libexec/gcc/x86_64-glidix/4.9.0/lto-wrapper -plugin-opt=-fresolution=/tmp/cc3xbPRP.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc --sysroot=/glidix -o libc.so /glidix/lib/crti.o /usr/lib/gcc/x86_64-glidix/4.9.0/crtbegin.o -L/usr/lib/gcc/x86_64-glidix/4.9.0 -L/usr/lib/gcc/x86_64-glidix/4.9.0/../../../../../usr/x86_64-glidix/lib -L/glidix/lib libc.a -lgcc -lgcc /usr/lib/gcc/x86_64-glidix/4.9.0/crtend.o /glidix/lib/crtn.o
/usr/lib/gcc/x86_64-glidix/4.9.0/../../../../../usr/x86_64-glidix/bin/ld: warning: cannot find entry symbol _start; defaulting to 00000000004000c0

[gerryg400]

EDIT: I used the -v flag and it turns out that GCC is not passing the -shared option to the linker:

You need a LINK_SPEC to control what gets passed to the linker. Here's mine

Code: Select all

#undef  LINK_SPEC
#define LINK_SPEC "%{" SPEC_64 ":-m elf_x86_64} %{" SPEC_32 ":-m elf_i386} \
  %{shared:-shared} \
  %{!shared: \
    %{!static: \
      %{rdynamic:-export-dynamic} \
      %{" SPEC_32 ":-dynamic-linker " "/lib32/ld-anvil32.so" "} \
      %{" SPEC_64 ":-dynamic-linker " "/lib/ld-anvil.so" "}} \
    %{static:-static}}"

The %{shared:-shared} is the bit you need right now. But to support things like dlopen you need it all.

[gerryg400]

Thank you for your help. It also seems that when I create static executable, they are linked so that there is only one program header, which stores all code, data and bss in a single segment, with read-write-execute permission. Does anyone know why it may be creating this one segment instead of 2? There should be, by default, a segment for code (read-and-execute) and for data (read-and-write).

Did you fix this issue ?