[Clfs-support] Clang -m32 passing incorrect crt1.o crti.o crtn.o paths to ld for 32-bit build.

[Roger Frost]

Greetings,

I make several deviation, but I hope that someone here has experienced 
the issue I'm having and is able to help.

I've built a x86_64 multilib system based on LFS 7.10 (package versions) 
and referencing CLFS 3.0.0 (build procedure). I also use Package Users. 
I'm now building BLFS 7.10 packages.

I've been fighting with LLVM + Clang + Compiler-RT version 3.8.1 for a 
couple of weeks now and have finally identified the cause of my problem.

In a nutshell, Clang doesn't play well with multilib GCC, at least newer 
version of one or both.

The problem is that 'clang -m32 ...' is unable to link 32-bit binaries 
because it passes incorrect paths to ld, specifically for crt{1,i,n}.o:

  "/usr/bin/ld" --eh-frame-hdr -m elf_i386 -dynamic-linker 
/lib/ld-linux.so.2 -o a.out 
/usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../crt1.o 
/usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../crti.o 
/usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/32/crtbegin.o 
-L/usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/32 
-L/usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2 
-L/usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../.. 
-L/usr/bin/../lib -L/lib -L/usr/lib /tmp/dummy-07e884.o -lgcc 
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s 
--no-as-needed 
/usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/32/crtend.o 
/usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../crtn.o

In contrast, the 'clang -m64 ...' ld call looks like this, and is correct:

  "/usr/bin/ld" --eh-frame-hdr -m elf_x86_64 -dynamic-linker 
/lib64/ld-linux-x86-64.so.2 -o a.out 
/usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/crt1.o 
/usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/crti.o 
/usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/crtbegin.o 
-L/usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2 
-L/usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64 
-L/usr/bin/../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 
-L/usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../.. 
-L/usr/bin/../lib -L/lib -L/usr/lib /tmp/dummy-4c0643.o -lgcc 
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s 
--no-as-needed 
/usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/crtend.o 
/usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib64/crtn.o

The correct 32-bit call would be like this, after inserting /../lib in 
those 3 paths:

  "/usr/bin/ld" --eh-frame-hdr -m elf_i386 -dynamic-linker 
/lib/ld-linux.so.2 -o a.out 
/usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib/crt1.o 
/usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib/crti.o 
/usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/32/crtbegin.o 
-L/usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/32 
-L/usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2 
-L/usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../.. 
-L/usr/bin/../lib -L/lib -L/usr/lib /tmp/dummy-07e884.o -lgcc 
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s 
--no-as-needed 
/usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/32/crtend.o 
/usr/bin/../lib64/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib/crtn.o

This seems to be an on-going issue in clang development, I think the 
earliest post that I seen mention it was from about 2011 or so.

Just for kicks, I also built the newest LLVM release, 3.9.1, and the 
issue remains.

Is anyone here able to get 32-bit output from recent versions of Clang/GCC?

Thanks,
Roger