[Clfs-dev] gcc MULTILIB_OSDIRS

DJ Lucas dj at linuxfromscratch.org
Fri Sep 2 23:23:03 PDT 2011


Guys, I had some host creep occurring in a refresh of the x86_64 
multilib build, gcc-4.6.1, glibc-2.14, binutils-2.21.1a, CLooG-0.16.3 
with ISL-0.07 backend....lots of changes.

In the file gcc/config/i386/t-linux64, you have the following line:

MULTILIB_OSDIRNAMES = ../lib64 $(if $(wildcard $(shell echo 
$(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)

As you all probably know, I don't follow LFS or CLFS verbatim any 
longer. And, as it happens, I do have a /lib32 and /usr/lib32 on this 
rather odd host along with a pair of lib -> ./lib64 symlinks and 
../lib32 was being chosen as the 32bit lib path for gcc internals. The 
error was not noticed until the temporary perl and the result was that 
it thought the compiler unable to create executables (actually, it was 
unable with the incorrect lib path). Unfortunately, I did not save the 
broken specs output or Configure.gnu output.

I believe the proper fix was to set MULTILIB_OSDIRNAMES in both temp 
builds (obviously this was not necessary in chroot) because it worked! 
I'm setting this explicitly with the following commands (borrowed from 
Nathan's multi-lib recipe) prior to changing to the build directory:

sed -e '/MULTILIB_OSDIRNAMES/d' -i gcc/config/i386/t-linux64 &&
echo "MULTILIB_OSDIRNAMES = ../lib64 ../lib" >> gcc/config/i386/t-linux64

Does this seem like a sensible approach? Has anybody else seen this 
behavior on say Debian/Ubuntu?

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.




More information about the Clfs-dev mailing list