[Bug bootstrap/19135] New: build failure in libiberty multilibs

[Bug bootstrap/19135] New: build failure in libiberty multilibs

[janis187 at us dot ibm dot com]

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.

-- 
           Summary: build failure in libiberty multilibs
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: bootstrap
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: janis187 at us dot ibm dot com
                CC: gcc-bugs at gcc dot gnu dot org,hjl at gnu dot org
 GCC build triplet: powerpc64-linux
  GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135

[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs

[pinskia at gcc dot gnu dot org]

-- 
           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

[hjl at lucon dot org]

------- 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:

[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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135

[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs

[hjl at lucon dot org]

-- 
           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

[hjl at lucon dot org]

------- 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

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-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

[aj at gcc dot gnu dot org]

------- 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

[hjl at lucon dot org]

------- 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

[aj at gcc dot gnu dot org]

------- 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

[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs

[janis187 at us dot ibm dot com]

------- 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

[hjl at lucon dot org]

------- 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

[janis187 at us dot ibm dot com]

------- 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

[hjl at lucon dot org]

------- 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

[hjl at lucon dot org]

------- 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

[janis187 at us dot ibm dot com]

------- 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

[hjl at lucon dot org]

------- 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

[aj at gcc dot gnu dot org]

------- 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

[janis187 at us dot ibm dot com]

------- 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

[hjl at lucon dot org]

------- 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

[aj at gcc dot gnu dot org]

------- 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