Jeremy Huntwork wrote:
> Jeremy Huntwork wrote:
>
>> Now for the debugging...
>>
>
> Well, this is forcing me to read up about gcc internals.
>
> The error is occurring when building for stage3. First impression is
> that there is difficulty processing the specs file. You can truncate the
> specs file (located in ./gcc/specs) or point xgcc to use an empty file
> with the '-specs' flag and the same 'specs: Invalid argument' error
> appears. However, if you delete the specs file entirely and don't
> provide an alternate, forcing xgcc to use its built-in specs, this error
> shows up:
>
> $ echo 'main(){}' | ./gcc/xgcc -xc -v -
> Using built-in specs.
> Target: x86_64-unknown-linux-gnu
> Configured with: ../gcc-4.2.1/configure --prefix=/tools
> --with-local-prefix=/tools --disable-nls --disable-shared
> --enable-languages=c --disable-multilib
> Thread model: posix
> gcc version 4.2.1
> cc1 -quiet -v -iprefix
> /mnt/lfs/sources/gcc-build/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.2.1/
> - -quiet -dumpbase - -mtune=generic -auxbase - -version -o /tmp/ccDiOCyh.s
> xgcc: error trying to exec 'cc1': execvp: No such file or directory
>
> I'm not exactly sure how cc1 is meant to be used, but running it
> directly without any arguments produces some worrying results:
>
> $ ./gcc/cc1
> cc1: error: /tools/include: Invalid argument
> cc1: error: /tools/lib/gcc/x86_64-unknown-linux-gnu/4.2.1/include:
> Invalid argument
> cc1: error: /tools/lib/../x86_64-unknown-linux-gnu/include: Invalid argument
> cc1: error: /usr/include: Invalid argument
> cc1: error: stdout: Invalid argument
>
> Going to have to do some more reading on how cc1 is employed, and the
> order in which things are done when gcc compiles a file.
>
All these "Invalid argument" errors indicate that either parameters are
passed incorrectly to glibc functions, or the return codes of glibc
functions are misinterpreted. The guess is that gcc stage1 doesn't
understand Debian's multilib setup and picks up wrong files in
/usr/include (and thus, stage2 is miscompiled). One more confirmation of
this idea: if you don't add --disable-libmudflap, you get a compilation
error about redeclaration of something with a different size.
Conclusion: Debian Lenny x86 multilib setup (which is clearly a huge
deviation from upstream gcc) is not going to be supported by any native
build method. The fact that "non-bootstrap of gcc pass1" works is pure luck.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
