[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs
--- Additional Comments From aj at gcc dot gnu dot org 2004-12-28 15:42 --- The initial patch to libiberty has been reverted, so this issue should be fixed now. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135
[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs
--- Additional Comments From janis187 at us dot ibm dot com 2004-12-26 23:39 --- 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? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135
[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs
--- Additional Comments From hjl at lucon dot org 2004-12-27 02:41 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135
[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs
--- Additional Comments From aj at gcc dot gnu dot org 2004-12-25 08:25 --- This patch worked for me on the troubling machine. I'm testing it on my other machines now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135
[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs
--- Additional Comments From janis187 at us dot ibm dot com 2004-12-23 17:18 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135
[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs
--- Additional Comments From hjl at lucon dot org 2004-12-23 18:22 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135
[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs
--- Additional Comments From janis187 at us dot ibm dot com 2004-12-23 18:50 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135
[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs
--- Additional Comments From hjl at lucon dot org 2004-12-23 18:55 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135
[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs
--- Additional Comments From hjl at lucon dot org 2004-12-23 19:30 --- 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++? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135
[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs
--- Additional Comments From janis187 at us dot ibm dot com 2004-12-23 19:44 --- An easier question is: how does libmudflap do it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135
[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs
--- Additional Comments From hjl at lucon dot org 2004-12-23 21:40 --- Janis, can you send me the build log of both 32bit and 64bit libmudflap.la? I only need the one for libmudflap.la. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135
[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs
-- What|Removed |Added Severity|normal |critical Keywords||build Priority|P2 |P1 Summary|build failure in libiberty |[4.0 Regression] build |multilibs |failure in libiberty ||multilibs Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135
[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs
--- Additional Comments From hjl at lucon dot org 2004-12-23 01:14 --- I don't have Linux/powerpc64. I have no problems with Linux/x86_64: [EMAIL PROTECTED] 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135
[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs
--- Additional Comments From hjl at lucon dot org 2004-12-23 01:20 --- Linux/x86_64 doesn't support --with-cpu=default32. I have no idea what went wrong on Linux/powerpc64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135
[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs
-- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135
[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs
-- What|Removed |Added Status|WAITING |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-23 01:22:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135
[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs
--- Additional Comments From aj at gcc dot gnu dot org 2004-12-23 05:57 --- 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 -- What|Removed |Added CC||aj at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135
[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs
--- Additional Comments From hjl at lucon dot org 2004-12-23 06:53 --- I just did a # make install DESTDIR=foo/bar on Linux/x86_64 without any problems. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135
[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs
--- Additional Comments From aj at gcc dot gnu dot org 2004-12-23 07:06 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135