GCC not finding runtime files under my OS

[mariuszp]

I had binutils ported and fully functional under my OS for quite some time, so after some playing around, I managed to build GCC to run natively on my OS, with canonical name x86_64-glidix.

I successfully built it and installed under my OS, so I decided to run a compile the trivial "hello world" C program. If I run:

Code: Select all

gcc -c hello.c -o hello.o

It successfully creates hello.o without problems, and I can even link it into an executable manually (by running "ld" etc). However, if I try to link using "gcc", it fails to find the runtime files (crt0.o, crtbegin.o, etc). "crtbegin" is actually located in the GCC library directories, while the rest are located under /lib. Also, it says it cannot read "libgcc.a". Here is the full verbose output (undex glidix):

Code: Select all

mariusz:/home/mariusz$ gcc -v hello.o -o hello
Using built-in specs.
COLLECT_GCC=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 --host=x86_64-glidix --prefix=/usr --enable-languages=c,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/x86_64-glidix/bin/
LIBRARY_PATH=/usr/lib/gcc/x86_64-glidix/4.9.0/:/usr/lib/:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-o' 'hello' '-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-glidix/4.9.0/collect2 -dynamic-linker /lib/glidixld.so -o hello crt0.o crti.o crtbegin.o -L/usr/lib/gcc/x86_64-glidix/4.9.0 hello.o -lgcc -lc -lgcc crtend.o crtn.o
collect2: error: ld terminated with signal -1 []
/usr/bin/ld: cannot find crt0.o: No such file or directory.
/usr/bin/ld: cannot find crti.o: No such file or directory.
/usr/bin/ld: cannot find crtbegin.o: No such file or directory.
/usr/lib/gcc/x86_64-glidix/4.9.0/libgcc.a: file not recognized: File format not recognized
gcc: internal compiler error:  (program collect2)
Invalid memory access
mariusz:/home/mariusz$

The verbose output looks quite different when I run the cross-compiler under Linux (targetting Glidix):

Code: Select all

$ x86_64-glidix-gcc -v hello.o -o hello
Using built-in specs.
COLLECT_GCC=x86_64-glidix-gcc
COLLECT_LTO_WRAPPER=/glidix/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 --with-sysroot=/glidix --enable-languages=c,c++
Thread model: single
gcc version 4.9.0 (GCC) 
COMPILER_PATH=/glidix/usr/libexec/gcc/x86_64-glidix/4.9.0/:/glidix/usr/libexec/gcc/x86_64-glidix/4.9.0/:/glidix/usr/libexec/gcc/x86_64-glidix/:/glidix/usr/lib/gcc/x86_64-glidix/4.9.0/:/glidix/usr/lib/gcc/x86_64-glidix/:/glidix/usr/lib/gcc/x86_64-glidix/4.9.0/../../../../x86_64-glidix/bin/
LIBRARY_PATH=/glidix/usr/lib/gcc/x86_64-glidix/4.9.0/:/glidix/usr/lib/gcc/x86_64-glidix/4.9.0/../../../../x86_64-glidix/lib/:/glidix/lib/:/glidix/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-o' 'hello' '-mtune=generic' '-march=x86-64'
 /glidix/usr/libexec/gcc/x86_64-glidix/4.9.0/collect2 -plugin /glidix/usr/libexec/gcc/x86_64-glidix/4.9.0/liblto_plugin.so -plugin-opt=/glidix/usr/libexec/gcc/x86_64-glidix/4.9.0/lto-wrapper -plugin-opt=-fresolution=/tmp/ccqQM6YX.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc --sysroot=/glidix -dynamic-linker /lib/glidixld.so -o hello /glidix/lib/crt0.o /glidix/lib/crti.o /glidix/usr/lib/gcc/x86_64-glidix/4.9.0/crtbegin.o -L/glidix/usr/lib/gcc/x86_64-glidix/4.9.0 -L/glidix/usr/lib/gcc/x86_64-glidix/4.9.0/../../../../x86_64-glidix/lib -L/glidix/lib -L/glidix/usr/lib hello.o -lgcc -lc -lgcc /glidix/usr/lib/gcc/x86_64-glidix/4.9.0/crtend.o /glidix/lib/crtn.o

What could be causing this?

The only thing I can think of that might be causing this is mmap() calls - the filesystem driver does not support memory mapping yet, so when mmap() is called for mapping a file for read-only, the C library maps anonymous memory into the given region, then reads from the file into that memory, and seeks back to the original position in the file. My mmap() returns a different pointer than the "hint" - namely, it returns the hint but page-aligned, which the standard says is acceptable (mmap() is allowed to return a different location than the requested hint).

[gerryg400]

Hi, I took a pic of the same process on my OS so that you can compare. My LIBRARY_PATH has more entries. Perhaps that is the problem.

[mariuszp]

your compiler also seems to specify the paths of crt0 etc fully (/lib/../crt0.o etc instead of just "crt0.o"), did you have to specify those somewhere in the compiler code?

[gerryg400]

your compiler also seems to specify the paths of crt0 etc fully (/lib/../crt0.o etc instead of just "crt0.o"), did you have to specify those somewhere in the compiler code?

I think that comes from multilib options in my t-anvil64 fragment.

Code: Select all

MULTILIB_OPTIONS = m64/m32
MULTILIB_DIRNAMES = 64 32 
MULTILIB_OSDIRNAMES = ../lib ../lib32

[mariuszp]

I never modified any file containing something similar. It still seems to work for cross-compilation (i'm only targetting 64-bit so I never configured any multilib stuff).

[mariuszp]

OH WAIT...
I think it might be the fact that glidix does not accept double slashes in pathnames.

[gerryg400]

That could be it...

[mariuszp]

I fixed the problem with slashes but the compiler still cannot find the runtime files and outputs the same error message.

[mariuszp]

Is it possible that it's actually binutils that is misconfigured?

I traced the open() and stat() calls made by ld, and it never bothers to try to find crt0.o etc in /lib or /usr/lib; it only looks for them in the current working directory, and also seems to be unable to understand the format of libgcc.a.

could it be binutils that is at fault?

EDIT: But actually, it appears like the cross-compiler running on Linux specifies the full path of those files, as seen in my original post. My ENDFILE_SPEC and STARTFILE_SPEC (in gcc/config/glidix.h) are as follows:

Code: Select all

#undef ENDFILE_SPEC
#define ENDFILE_SPEC "%{!shared:crtend.o%s} %{!shared:crtn.o%s}"

#undef STARTFILE_SPEC
#define STARTFILE_SPEC "%{!shared:crt0.o%s} %{!shared:crti.o%s} %{!shared:crtbegin.o%s}"

#undef LINK_SPEC
#define LINK_SPEC "\
  %{shared:-shared} \
  %{!shared: \
    %{!static: \
      %{rdynamic:-export-dynamic} \
      -dynamic-linker /lib/glidixld.so} \
      %{static:-static}}"

Is this the correct way to specify them? If I do not have those specs, the cross-compiler doesn't link them in automatically.

[gerryg400]

Hi, for reference mine look like this

Code: Select all

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

#define ENDFILE_SPEC "%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s"

Furthermore, the 2 patch fragments in my gcc/config.gcc

Code: Select all

+*-*-anvil*)
+  # Assume that newlib is being used and so __cxa_atexit is provided.
+  extra_parts="crtbegin.o crtend.o"
+  gas=yes
+  gnu_ld=yes
+  default_use_cxa_atexit=yes
+  use_gcc_stdint=none
+  ;;

Code: Select all

+x86_64-*-anvil*)
+	tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h newlib-stdint.h i386/i386elf.h i386/x86-64.h i386/anvil_64.h"
+    tmake_file="${tmake_file} i386/t-anvil64 t-svr4 i386/t-crtstuff i386/t-crtpc i386/t-crtfm t-dfprules"
+	use_fixproto=yes
+	;;

and a patch fragment in libgcc/config.host

Code: Select all

+x86_64-*-anvil*)
+    extra_parts="$extra_parts crtbegin.o crtbeginS.o crtbeginT.o crtend.o crtendS.o crtprec32.o crtprec64.o crtprec80.o crtfastmath.o"
+    tmake_file="${tmake_file} t-crtstuff-pic t-libgcc-pic i386/t-crtpc i386/t-crtfm i386/t-crtstuff t-dfprules"
+    ;;

[mariuszp]

Did you also specify a STARTFILE_PREFIX?

EDIT: Furthermore, I traced calls to stat() and open() made by GCC. It calls stat() on /lib/crt0.o, which returns 0, but then calls it on /usr/lib/crt0.o which returns -1 (because it doesn't exist), as if it was stilltrying to find the file despite having made a successful stat() call on it. Why could this be?