[Bug bootstrap/17646] New: xgcc links 64bit objects into a 32bit target

[Bug bootstrap/17646] New: xgcc links 64bit objects into a 32bit target

[olh at suse dot de]

current mainline configured for a native powerpc64-linux system fails to bootstrap:
it links /usr/lib64/crti.o and /usr/lib64/crtn.o into 32/nof/libgcc_s_nof.so.1


looks like last successful bootstrap was on Jun 10 2004. EEP!

mandarine:/usr/src/packages/BUILD/gcc-4.0.0-20040923/obj-powerpc64-suse-linux/gcc$ ./xgcc -v -B./ -B/usr/powerpc64-suse-linux/bin/ -isystem /usr/powerpc64-suse-linux/include -isystem /usr/powerpc64-suse-linux/sys-include -L/usr/src/packages/BUILD/gcc-4.0.0-20040923/obj-powerpc64-suse-linux/gcc/../ld -O2  -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include  -mno-minimal-toc -fPIC -specs=bispecs -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -shared -nodefaultlibs -Wl,--soname=libgcc_s_nof.so.1 -Wl,--version-script=libgcc/32/nof/libgcc.map -o 32/nof/libgcc_s_nof.so.1  -m32 -msoft-float -fPIC -mstrict-align  libgcc/32/nof/_muldi3.o libgcc/32/nof/_negdi2.o libgcc/32/nof/_lshrdi3.o libgcc/32/nof/_ashldi3.o libgcc/32/nof/_ashrdi3.o libgcc/32/nof/_cmpdi2.o libgcc/32/nof/_ucmpdi2.o libgcc/32/nof/_floatdidf.o libgcc/32/nof/_floatdisf.o libgcc/32/nof/_fixunsdfsi.o libgcc/32/nof/_fixunssfsi.o libgcc/32/nof/_fixunsdfdi.o libgcc/32/nof/_fixdfdi.o libgcc/32/nof/_fixunssfdi.o libgcc/32/nof/_fixsfdi.o libgcc/32/nof/_fixxfdi.o libgcc/32/nof/_fixunsxfdi.o libgcc/32/nof/_floatdixf.o libgcc/32/nof/_fixunsxfsi.o libgcc/32/nof/_fixtfdi.o libgcc/32/nof/_fixunstfdi.o libgcc/32/nof/_floatditf.o libgcc/32/nof/_clear_cache.o libgcc/32/nof/_enable_execute_stack.o libgcc/32/nof/_trampoline.o libgcc/32/nof/__main.o libgcc/32/nof/_absvsi2.o libgcc/32/nof/_absvdi2.o libgcc/32/nof/_addvsi3.o libgcc/32/nof/_addvdi3.o libgcc/32/nof/_subvsi3.o libgcc/32/nof/_subvdi3.o libgcc/32/nof/_mulvsi3.o libgcc/32/nof/_mulvdi3.o libgcc/32/nof/_negvsi2.o libgcc/32/nof/_negvdi2.o libgcc/32/nof/_ctors.o libgcc/32/nof/_ffssi2.o libgcc/32/nof/_ffsdi2.o libgcc/32/nof/_clz.o libgcc/32/nof/_clzsi2.o libgcc/32/nof/_clzdi2.o libgcc/32/nof/_ctzsi2.o libgcc/32/nof/_ctzdi2.o libgcc/32/nof/_popcount_tab.o libgcc/32/nof/_popcountsi2.o libgcc/32/nof/_popcountdi2.o libgcc/32/nof/_paritysi2.o libgcc/32/nof/_paritydi2.o libgcc/32/nof/_divdi3.o libgcc/32/nof/_moddi3.o libgcc/32/nof/_udivdi3.o libgcc/32/nof/_umoddi3.o libgcc/32/nof/_udiv_w_sdiv.o libgcc/32/nof/_udivmoddi4.o libgcc/32/nof/_pack_sf.o libgcc/32/nof/_unpack_sf.o libgcc/32/nof/_addsub_sf.o libgcc/32/nof/_mul_sf.o libgcc/32/nof/_div_sf.o libgcc/32/nof/_fpcmp_parts_sf.o libgcc/32/nof/_compare_sf.o libgcc/32/nof/_eq_sf.o libgcc/32/nof/_ne_sf.o libgcc/32/nof/_gt_sf.o libgcc/32/nof/_ge_sf.o libgcc/32/nof/_lt_sf.o libgcc/32/nof/_le_sf.o libgcc/32/nof/_unord_sf.o libgcc/32/nof/_si_to_sf.o libgcc/32/nof/_sf_to_si.o libgcc/32/nof/_negate_sf.o libgcc/32/nof/_make_sf.o libgcc/32/nof/_sf_to_df.o libgcc/32/nof/_sf_to_tf.o libgcc/32/nof/_thenan_sf.o libgcc/32/nof/_sf_to_usi.o libgcc/32/nof/_usi_to_sf.o libgcc/32/nof/_pack_df.o libgcc/32/nof/_unpack_df.o libgcc/32/nof/_addsub_df.o libgcc/32/nof/_mul_df.o libgcc/32/nof/_div_df.o libgcc/32/nof/_fpcmp_parts_df.o libgcc/32/nof/_compare_df.o libgcc/32/nof/_eq_df.o libgcc/32/nof/_ne_df.o libgcc/32/nof/_gt_df.o libgcc/32/nof/_ge_df.o libgcc/32/nof/_lt_df.o libgcc/32/nof/_le_df.o libgcc/32/nof/_unord_df.o libgcc/32/nof/_si_to_df.o libgcc/32/nof/_df_to_si.o libgcc/32/nof/_negate_df.o libgcc/32/nof/_make_df.o libgcc/32/nof/_df_to_sf.o libgcc/32/nof/_df_to_tf.o libgcc/32/nof/_thenan_df.o libgcc/32/nof/_df_to_usi.o libgcc/32/nof/_usi_to_df.o libgcc/32/nof/tramp.o libgcc/32/nof/ppc64-fp.o libgcc/32/nof/darwin-ldouble.o  libgcc/32/nof/unwind-dw2.o libgcc/32/nof/unwind-dw2-fde-glibc.o libgcc/32/nof/unwind-sjlj.o libgcc/32/nof/gthr-gnat.o libgcc/32/nof/unwind-c.o -lc && rm -f libgcc_s_32_nof.so && ln -s 32/nof/libgcc_s_nof.so.1 libgcc_s_32_nof.so
Reading specs from ./specs
Reading specs from ./bispecs
Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,f95,java --enable-checking --with-slibdir=/lib64 --with-system-zlib --enable-shared --enable-__cxa_atexit powerpc64-suse-linux
Thread model: posix
gcc version 4.0.0 20040923 (experimental) (SUSE Linux)
 ./collect2 --eh-frame-hdr -V -Qy -shared -m elf32ppclinux -o 32/nof/libgcc_s_nof.so.1 /usr/lib64/crti.o ./32/nof/crtbeginS.o -L/usr/src/packages/BUILD/gcc-4.0.0-20040923/obj-powerpc64-suse-linux/gcc/../ld -L./32/nof -L. -L/usr/powerpc64-suse-linux/bin -L/usr/lib64/../powerpc64-suse-linux/lib -L/usr/lib64 --soname=libgcc_s_nof.so.1 --version-script=libgcc/32/nof/libgcc.map libgcc/32/nof/_muldi3.o libgcc/32/nof/_negdi2.o libgcc/32/nof/_lshrdi3.o libgcc/32/nof/_ashldi3.o libgcc/32/nof/_ashrdi3.o libgcc/32/nof/_cmpdi2.o libgcc/32/nof/_ucmpdi2.o libgcc/32/nof/_floatdidf.o libgcc/32/nof/_floatdisf.o libgcc/32/nof/_fixunsdfsi.o libgcc/32/nof/_fixunssfsi.o libgcc/32/nof/_fixunsdfdi.o libgcc/32/nof/_fixdfdi.o libgcc/32/nof/_fixunssfdi.o libgcc/32/nof/_fixsfdi.o libgcc/32/nof/_fixxfdi.o libgcc/32/nof/_fixunsxfdi.o libgcc/32/nof/_floatdixf.o libgcc/32/nof/_fixunsxfsi.o libgcc/32/nof/_fixtfdi.o libgcc/32/nof/_fixunstfdi.o libgcc/32/nof/_floatditf.o libgcc/32/nof/_clear_cache.o libgcc/32/nof/_enable_execute_stack.o libgcc/32/nof/_trampoline.o libgcc/32/nof/__main.o libgcc/32/nof/_absvsi2.o libgcc/32/nof/_absvdi2.o libgcc/32/nof/_addvsi3.o libgcc/32/nof/_addvdi3.o libgcc/32/nof/_subvsi3.o libgcc/32/nof/_subvdi3.o libgcc/32/nof/_mulvsi3.o libgcc/32/nof/_mulvdi3.o libgcc/32/nof/_negvsi2.o libgcc/32/nof/_negvdi2.o libgcc/32/nof/_ctors.o libgcc/32/nof/_ffssi2.o libgcc/32/nof/_ffsdi2.o libgcc/32/nof/_clz.o libgcc/32/nof/_clzsi2.o libgcc/32/nof/_clzdi2.o libgcc/32/nof/_ctzsi2.o libgcc/32/nof/_ctzdi2.o libgcc/32/nof/_popcount_tab.o libgcc/32/nof/_popcountsi2.o libgcc/32/nof/_popcountdi2.o libgcc/32/nof/_paritysi2.o libgcc/32/nof/_paritydi2.o libgcc/32/nof/_divdi3.o libgcc/32/nof/_moddi3.o libgcc/32/nof/_udivdi3.o libgcc/32/nof/_umoddi3.o libgcc/32/nof/_udiv_w_sdiv.o libgcc/32/nof/_udivmoddi4.o libgcc/32/nof/_pack_sf.o libgcc/32/nof/_unpack_sf.o libgcc/32/nof/_addsub_sf.o libgcc/32/nof/_mul_sf.o libgcc/32/nof/_div_sf.o libgcc/32/nof/_fpcmp_parts_sf.o libgcc/32/nof/_compare_sf.o libgcc/32/nof/_eq_sf.o libgcc/32/nof/_ne_sf.o libgcc/32/nof/_gt_sf.o libgcc/32/nof/_ge_sf.o libgcc/32/nof/_lt_sf.o libgcc/32/nof/_le_sf.o libgcc/32/nof/_unord_sf.o libgcc/32/nof/_si_to_sf.o libgcc/32/nof/_sf_to_si.o libgcc/32/nof/_negate_sf.o libgcc/32/nof/_make_sf.o libgcc/32/nof/_sf_to_df.o libgcc/32/nof/_sf_to_tf.o libgcc/32/nof/_thenan_sf.o libgcc/32/nof/_sf_to_usi.o libgcc/32/nof/_usi_to_sf.o libgcc/32/nof/_pack_df.o libgcc/32/nof/_unpack_df.o libgcc/32/nof/_addsub_df.o libgcc/32/nof/_mul_df.o libgcc/32/nof/_div_df.o libgcc/32/nof/_fpcmp_parts_df.o libgcc/32/nof/_compare_df.o libgcc/32/nof/_eq_df.o libgcc/32/nof/_ne_df.o libgcc/32/nof/_gt_df.o libgcc/32/nof/_ge_df.o libgcc/32/nof/_lt_df.o libgcc/32/nof/_le_df.o libgcc/32/nof/_unord_df.o libgcc/32/nof/_si_to_df.o libgcc/32/nof/_df_to_si.o libgcc/32/nof/_negate_df.o libgcc/32/nof/_make_df.o libgcc/32/nof/_df_to_sf.o libgcc/32/nof/_df_to_tf.o libgcc/32/nof/_thenan_df.o libgcc/32/nof/_df_to_usi.o libgcc/32/nof/_usi_to_df.o libgcc/32/nof/tramp.o libgcc/32/nof/ppc64-fp.o libgcc/32/nof/darwin-ldouble.o libgcc/32/nof/unwind-dw2.o libgcc/32/nof/unwind-dw2-fde-glibc.o libgcc/32/nof/unwind-sjlj.o libgcc/32/nof/gthr-gnat.o libgcc/32/nof/unwind-c.o -lc ./32/nof/crtsavres.o ./32/nof/crtendS.o /usr/lib64/crtn.o
/usr/powerpc64-suse-linux/bin/ld: skipping incompatible /usr/lib64/libc.so when searching for -lc
/usr/powerpc64-suse-linux/bin/ld: skipping incompatible /usr/lib64/libc.a when searching for -lc
/usr/powerpc64-suse-linux/bin/ld: skipping incompatible /usr/lib64/libc.so when searching for -lc
/usr/powerpc64-suse-linux/bin/ld: skipping incompatible /usr/lib64/libc.a when searching for -lc
/usr/powerpc64-suse-linux/bin/ld: warning: powerpc:common64 architecture of input file `/usr/lib64/crti.o' is incompatible with powerpc:common output
/usr/powerpc64-suse-linux/bin/ld: warning: powerpc:common64 architecture of input file `/usr/lib64/crtn.o' is incompatible with powerpc:common output
/usr/lib64/crti.o(.text+0xe): In function `.call_gmon_start':
/usr/src/packages/BUILD/glibc-2.3/cc/csu/crti.S:25: relocation truncated to fit: R_PPC64_TOC16_DS .toc
GNU ld version 2.15.91.0.2 20040727 (SuSE Linux)
  Supported emulations:
   elf64ppc
   elf32ppclinux
   elf32ppc
   elf32ppcsim
collect2: ld returned 1 exit status
mandarine:/usr/src/packages/BUILD/gcc-4.0.0-20040923/obj-powerpc64-suse-linux/gcc$

-- 
           Summary: xgcc links 64bit objects into a 32bit target
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: bootstrap
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: olh at suse dot de
                CC: gcc-bugs at gcc dot 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=17646

[Bug bootstrap/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |critical
            Summary|xgcc links 64bit objects    |[4.0 Regression] xgcc links
                   |into a 32bit target         |64bit objects into a 32bit
                   |                            |target
   Target Milestone|---                         |4.0.0


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

[Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-06 05:14 -------
How do you explain: <http://gcc.gnu.org/ml/gcc-testresults/2004-10/msg00259.html>?

I think your configure options should/can never work.
 --libdir=/usr/lib64 --libexecdir=/usr/lib64  --with-slibdir=/lib64

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|bootstrap                   |target


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

[Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target

[olh at suse dot de]

------- Additional Comments From olh at suse dot de  2004-10-06 07:28 -------
they do work with the hammer branch at least.

Reading specs from /usr/lib64/gcc-lib/powerpc64-suse-linux/3.3.4/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --enable-languages=c,c++,f77,objc,java --disable-checking --libdir=/usr/lib64 --enable-libgcj --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib64 --with-system-zlib --enable-shared --enable-__cxa_atexit --enable-biarch powerpc64-suse-linux
Thread model: posix
gcc version 3.3.4 (pre 3.3.5 20040809)



-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matz at suse dot de, aj at
                   |                            |suse dot de


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

[Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target

[aj at gcc dot gnu dot org]

------- Additional Comments From aj at gcc dot gnu dot org  2004-10-06 07:32 -------
(In reply to comment #1) 
 
> I think your configure options should/can never work. 
>  --libdir=/usr/lib64 --libexecdir=/usr/lib64  --with-slibdir=/lib64 
 
Those configure options work fine on x86-64 and s390x. 
 

-- 


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

[Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target

[matz at suse dot de]

------- Additional Comments From matz at suse dot de  2004-10-06 09:27 -------
The system compiler (with which stage1 is compiled) is a gcc which produces 32 
bit code by default, isn't it?  In that case the problem is that this gcc 
is also used to compile for instance build-<target>/libiberty/ (without 
any special options, hence to 32 bit). 
 
But the HEAD compiler which is built produces 64 bit code by default. 
The problem is, that also stage2 is linked to the above libiberty.  But stage2 
(being compiled by stage1) is 64bit code.  Hence linker errors result 
when building the gen* tools. 
 
I'm not totally sure if this is the same problem, but it at least is also 
some multilib 64/32 bit confusion in gcc. 

-- 


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

[Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target

[matz at suse dot de]

------- Additional Comments From matz at suse dot de  2004-10-06 09:29 -------
Andrew: note how the submitted testresults have --with-cpu=default32 in 
the configure args.  That might change the behaviour quite a bit. 

-- 


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

[Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target

[olh at suse dot de]

------- Additional Comments From olh at suse dot de  2004-10-06 09:34 -------
thats likely the case, I use a full 64bit tree to bootstrap.


-- 


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

[Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target

[matz at suse dot de]

------- Additional Comments From matz at suse dot de  2004-10-06 09:37 -------
Ehm, so it is _not_ the case that the system compiler produces 32 bit code 
by default, right? 

-- 


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

[Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target

[olh at suse dot de]

------- Additional Comments From olh at suse dot de  2004-10-06 09:56 -------
I used the 'ppc64' dist, not 'ppc'


-- 


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

[Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target

[matz at suse dot de]

------- Additional Comments From matz at suse dot de  2004-10-06 09:59 -------
So, it's not exactly the same problem I saw.  Still might be connected, 
though. 

-- 


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

[Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |build


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

[Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target

[olh at suse dot de]

------- Additional Comments From olh at suse dot de  2004-10-09 15:53 -------
--libdir=/foo is the culprit


-- 


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

[Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target

[jgrimm2 at us dot ibm dot com]

------- Additional Comments From jgrimm2 at us dot ibm dot com  2004-10-19 21:25 -------
I see this too.  Or rather, I see what Michael is describing. Should there be a
new bug for the problem as described by Michael?  My test scenario was from
desire to build 64-bit biarch compiler that defaults to m64.  The system
compiler was 32-bit biarch compiler that defaults to m32.   


Here's how I had configured: 
/home/jgrimm/gcc_priv_mline_anoncvs/gcc/configure
--prefix=/home/jgrimm/tools/gcc-work --build=powerpc64-linux
--host=powerpc64-linux --target=powerpc64-linux --with-cpu=default64
--with-as=/home/jgrimm/tools/binutils/bin/as
--with-ld=/home/jgrimm/tools/binutils/bin/ld --enable-threads=\posix
--enable-shared --enable-__cxa_atexit --enable-languages=c --enable-biarch

Error output:
...
stage1/xgcc -Bstage1/ -B/home/jgrimm/tools/gcc-work/powerpc64-linux/bin/   -g
-O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
 -fno-common   -DHAVE_CONFIG_H -DGENERATOR_FILE  -o build/genmodes \
 build/genmodes.o build/errors.o ../build-powerpc64-linux/libiberty/libiberty.a
/home/jgrimm/tools/binutils/bin/ld: warning: powerpc:common architecture of
input file `../build-powerpc64-linux/libiberty/libiberty.a(hashtab.o)' is
incompatible with powerpc:common64 output
/home/jgrimm/tools/binutils/bin/ld: warning: powerpc:common architecture of
input file `../build-powerpc64-linux/libiberty/libiberty.a(xmalloc.o)' is
incompatible with powerpc:common64 output
/home/jgrimm/tools/binutils/bin/ld: warning: powerpc:common architecture of
input file `../build-powerpc64-linux/libiberty/libiberty.a(xstrdup.o)' is
incompatible with powerpc:common64 output
/home/jgrimm/tools/binutils/bin/ld: warning: powerpc:common architecture of
input file `../build-powerpc64-linux/libiberty/libiberty.a(xexit.o)' is
incompatible with powerpc:common64 output
/home/jgrimm/tools/binutils/bin/ld: can not size stub section: Bad value


-- 


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

[Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target

[jgrimm2 at us dot ibm dot com]

------- Additional Comments From jgrimm2 at us dot ibm dot com  2004-10-27 15:38 -------
What I've finally done to get my 64-bit biarch default64 compiler is to first
build a 32-bit biarch default64 compiler.  I can then make bootstrap using this
intermediate compiler as the host compiler to build all stages 64-bit.  I'd
classify my earlier attempts as user error, though still think it should be
possible to do this eventually in one swoop on ppc64.  

Otherwise, i've been able to bootstrap just fine, though obviously I'm
configuring my build a bit differently than below. I just wanted to post back in
case others runs across my comments in sometime in the future and wanted to
close out those comments. 

-- 


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

[Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-20 01:02 -------
Is this fixed now?

-- 


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

[Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target

[aj at gcc dot gnu dot org]

------- Additional Comments From aj at gcc dot gnu dot org  2004-12-20 05:57 -------
It is not fixed, it still fails the same way 

-- 


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

[Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target

[jakub at gcc dot gnu dot org]

------- Additional Comments From jakub at gcc dot gnu dot org  2005-01-06 14:12 -------
There is no bug, the compiler has been configured incorrectly.
--libdir=/usr/lib64 should not be used for multilibbed gcc's,  --libdir=/usr/lib
is what you want.  The os multilib magic will DTRT.
Similarly, --libexecdir=/usr/lib64  --with-slibdir=/lib64 is wrong too,
you should either just use --prefix=/usr and not pass these at all, or
pass --libdir=/usr/lib --libexecdir=/usr/lib --with-slibdir=/lib.
powerpc64 gcc defaulting to -m64 works just fine that way for years.

-- 


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

[Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-06 14:16 -------
So closing as invalid.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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

[Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target

[olh at suse dot de]

------- Additional Comments From olh at suse dot de  2005-01-06 21:58 -------
I tried this:

 /home/abuild/gcc-4.0.0-20050103/configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --enable-languages=c,c++,objc,f95,java --enable-checking  --with-system-zlib --enable-shared --enable-__cxa_atexit --without-system-libunwind powerpc64-suse-linux  &>clog
 make bootstrap-lean -j12 &>mlog
 make install DESTDIR=$HOME/foobar &>ilog

That appears to work. Only the binaries like cc1 end up in
/usr/libexec/gcc/powerpc64-suse-linux/4.0.0
This should be /usr/lib64/gcc-lib (at least thats the place where cc1 is now).
So is just passing --libexecdir=/usr/lib64 supposed to work? Have to try it now.
No idea what /usr/libexec is and why SuSE did never use it.


-- 


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

[Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-06 22:42 -------
(In reply to comment #17)
> I tried this:

> That appears to work. Only the binaries like cc1 end up in
> /usr/libexec/gcc/powerpc64-suse-linux/4.0.0
> This should be /usr/lib64/gcc-lib (at least thats the place where cc1 is now).
> So is just passing --libexecdir=/usr/lib64 supposed to work? Have to try it now.
> No idea what /usr/libexec is and why SuSE did never use it.

No /usr/libexec is correct for executables which are never to be executed by the user themselves.
>From BSD's hier man page:
libexec/  system daemons & system utilities (executed by other programs).
before 3.4, we did place cc1 in /usr/lib/gcc-lib/ but that was plainly wrong, this changed and now we
place the cc1 (and the related files) in /usr/libexec/gcc/ which is more correct.


-- 


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

[Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target

[olh at suse dot de]

------- Additional Comments From olh at suse dot de  2005-01-06 23:46 -------
Ok, libexec always looked like a sane place, to me.
But anyway. I will leave it to Andreas to update our rpm spec file.

I still wonder why the same configure options work on x86_64-linux


-- 


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