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

2004-12-28 Thread 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


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

2004-12-26 Thread 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

2004-12-26 Thread 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

2004-12-25 Thread 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

2004-12-23 Thread 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

2004-12-23 Thread 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

2004-12-23 Thread 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

2004-12-23 Thread 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

2004-12-23 Thread 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

2004-12-23 Thread 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

2004-12-23 Thread 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

2004-12-22 Thread 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

2004-12-22 Thread 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:

[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

2004-12-22 Thread 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

2004-12-22 Thread 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

2004-12-22 Thread pinskia at gcc dot gnu dot org


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

2004-12-22 Thread 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

2004-12-22 Thread 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

2004-12-22 Thread 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