[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