GCC builds are broken on powerpc64-unknown-linux-gnu since this patch to libiberty: http://gcc.gnu.org/ml/gcc-cvs/2004-12/msg00805.html. I configure with --build, --host, and --target=powerpc64-linux and --with-cpu=default32; see my recent test results for mainline for the complete set of configure options I use. This problem occurs even for simple builds of C only. The build in powerpc64-linux/64/libiberty tries to create libiberty.so.0.0.0 from 64-bit object files without specifying -m64. The build continues and eventually succeeds, but 'make install' tries the same thing and fails.
I don't have Linux/powerpc64. I have no problems with Linux/x86_64: [hjl@gnu-20 build-x86_64-linux]$ grep "^CC =" x86_64-unknown-linux- gnu/32/libiberty/Makefile x86_64-unknown-linux-gnu/libiberty/Makefile x86_64-unknown-linux-gnu/32/libiberty/Makefile:CC = /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc - B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -B/usr/gcc-4.0/x86_64-unknown- linux-gnu/bin/ -B/usr/gcc-4.0/x86_64-unknown-linux-gnu/lib/ -isystem /usr/gcc- 4.0/x86_64-unknown-linux-gnu/include -isystem /usr/gcc-4.0/x86_64-unknown- linux-gnu/sys-include -m32 x86_64-unknown-linux-gnu/libiberty/Makefile:CC = /export/build/gnu/gcc/build- x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ - B/usr/gcc-4.0/x86_64-unknown-linux-gnu/bin/ -B/usr/gcc-4.0/x86_64-unknown- linux-gnu/lib/ -isystem /usr/gcc-4.0/x86_64-unknown-linux-gnu/include - isystem /usr/gcc-4.0/x86_64-unknown-linux-gnu/sys-include I will try --with-cpu=default32 to see if it makes a difference.
Linux/x86_64 doesn't support --with-cpu=default32. I have no idea what went wrong on Linux/powerpc64.
Created attachment 7809 [details] A patch Janis, can you give this patch a try?
I encountered a similar problem on Linux/x86-64 - but only on one of my machines. This happened during "make install" into a clean tree (with make install install_root=/tmp/newdir). I'll investigate again... and report back
I just did a # make install DESTDIR=foo/bar on Linux/x86_64 without any problems.
Are you running with multilibs enabled? As I've said, it fails on one of my two test machines - the other one seems happy :-( I'll test with your patch now.
The patch doesn't work, the command to link 64-bit libiberty.so.0.0.0 still doesn't use -m64. This comment in libiberty/Makefile.in might provide a clue about the problem: # This is tricky. Even though CC in the Makefile contains # multilib-specific flags, it's overridden by FLAGS_TO_PASS from the # default multilib, so we have to take LIBCFLAGS into account as well, # since it will be passed the multilib flags. Let me know what additional information I can provide.
With the new patch, there are COMPILER = $(CC) @DEFS@ $(LIBCFLAGS) $(HDEFINES) @ac_libiberty_warn_cflags@ COMPILE.c = $(COMPILER) -c -I. -I$(INCDIR) LTCOMPILE = $(LIBTOOL) --mode=compile $(COMPILE.c) LINK = $(LIBTOOL) --mode=link $(COMPILER) Unless LINK is overriden somehow, the same command should be used to compile 64bit object file and build 64bit shared library. If -m64 is used to compile 64bit object file, -m64 should also be used to build 64bit shared library. Can you show me the output of # cd 64bit target libiberty # rm -f xexit.lo # cd 32bit target libiberty # rm -f xexit.lo # make I'd like to see how 32bit and 64bit object files and libraries are built.
Created attachment 7811 [details] A new patch Janis, can you try this new patch? It is possible that the 32bit -rpath is passed to libtool to build 64bit shared library, which makes ld unhappy.
There is no -rpath in the command to build 64-bit libiberty. It appears to be just $(CC) plus -shared, the list of object files, -Wl,-soname -Wl,libiberty.so.0 -o ././libs/libiberty.so.0.0.0. Where in the Makefile does this happen? I'm trying to follow it but can't figure out where the shared version is built so I can get more information.
You need to show me your build log. There should be .../libtool ... -o libiberty.la ... -rpath .... which will build both shared library and static archive.
Subject: Re: [4.0 Regression] build failure in libiberty multilibs On Thu, Dec 23, 2004 at 06:22:31PM -0000, hjl at lucon dot org wrote: > Unless LINK is overriden somehow, the same command should be used to compile > 64bit object file and build 64bit shared library. If -m64 is used to > compile 64bit object file, -m64 should also be used to build 64bit shared > library. Can you show me the output of > > # cd 64bit target libiberty > # rm -f xexit.lo > # cd 32bit target libiberty > # rm -f xexit.lo > # make > > I'd like to see how 32bit and 64bit object files and libraries are built. From powerpc64-linux I removed ./libiberty/xedit.lo, ./64/libiberty/xedit.lo, and ./nof/libiberty.xexit.lo, and then ran make from the top of the build directory. The compressed output is attached. Janis
Created attachment 7812 [details] make.libiberty.log.bz2
It looks like a libtool bug to me. There is /bin/sh ./libtool --mode=link /home/janis/build/gcc-mline/build-gcc-mline-20041222-hjl/gcc/xgcc -B/home/janis/build/gcc-mline/build-gcc-mline-20041222-hjl/gcc/ -B/home/janis/tools/gcc-mline-20041222-hjl/powerpc64-linux/bin/ -B/home/janis/tools/gcc-mline-20041222-hjl/powerpc64-linux/lib/ -isystem /home/janis/tools/gcc-mline-20041222-hjl/powerpc64-linux/include -isystem /home/janis/tools/gcc-mline-20041222-hjl/powerpc64-linux/sys-include -DHAVE_CONFIG_H -O2 -g -O2 -m64 -fPIC -mstrict-align -W -Wall -Wtraditional -pedantic -o ./libiberty.la -rpath /home/janis/tools/gcc-mline-20041222-hjl/lib \ ./regex.lo ./cplus-dem.lo ./cp-demangle.lo ./md5.lo ./alloca.lo ./argv.lo ./choose-temp.lo ./concat.lo ./cp-demint.lo ./dyn-string.lo ./fdmatch.lo ./fibheap.lo ./floatformat.lo ./fnmatch.lo ./getopt.lo ./getopt1.lo ./getpwd.lo ./getruntime.lo ./hashtab.lo ./hex.lo ./lbasename.lo ./lrealpath.lo ./make-relative-prefix.lo ./make-temp-file.lo ./objalloc.lo ./obstack.lo ./partition.lo ./physmem.lo ./pex-unix.lo ./safe-ctype.lo ./sort.lo ./spaces.lo ./splay-tree.lo ./strerror.lo ./strsignal.lo ./ternary.lo ./xatexit.lo ./xexit.lo ./xmalloc.lo ./xmemdup.lo ./xstrdup.lo ./xstrerror.lo ./mkstemps.lo; \ For some reason, libtool decides not to pass -m64 to gcc. How does it work for libstdc++?
An easier question is: how does libmudflap do it?
Janis, can you send me the build log of both 32bit and 64bit libmudflap.la? I only need the one for libmudflap.la.
Created attachment 7814 [details] output of rebuilding libmudflap.la from 20041215 sources I did a simple build of C from 20041215 sources, removed the following files, and then did 'make' from the top-level build directory. Output is attached. ./powerpc64-linux/libmudflap/.libs/libmudflap.la ./powerpc64-linux/libmudflap/libmudflap.la ./powerpc64-linux/64/libmudflap/.libs/libmudflap.la ./powerpc64-linux/64/libmudflap/libmudflap.la ./powerpc64-linux/nof/libmudflap/.libs/libmudflap.la ./powerpc64-linux/nof/libmudflap/libmudflap.la By the way, with libiberty-multilib-1.patch the path given to -rpath for libiberty is always ....lib/../lib and doesn't include /nof or 64.
Created attachment 7819 [details] Another patch Janis, could you please try this patch to see if it works around the libtool bug? As for multilib in libiberty, I believe it is a different bug, see bug 19145.
Created attachment 7824 [details] A new patch Janis, Andreas, please try this new patch. I have no idea why libtool doesn't pass the right flag to gcc sometimes. I can't reproduce it myself. This patch shouldn't need -m32/-m64. Hopefully, it will fix your problem.
This patch worked for me on the troubling machine. I'm testing it on my other machines now.
A build with the patch libiberty-multilib-3.patch applied to 20041222 sources succeeds, although it doesn't attempt to build libiberty as a shared object. I haven't tried libiberty-multilib-2.patch; is that still desired?
There is no need for testing libiberty-multilib-2.patch. Libliberty doesn't build a shared library. It just builds an archive with PIC objects.
The initial patch to libiberty has been reverted, so this issue should be fixed now.