* [Bug bootstrap/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target
2004-09-24 6:59 [Bug bootstrap/17646] New: xgcc links 64bit objects into a 32bit target olh at suse dot de
@ 2004-09-24 11:56 ` pinskia at gcc dot gnu dot org
2004-10-06 5:14 ` [Bug target/17646] " pinskia at gcc dot gnu dot org
` (19 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-09-24 11:56 UTC (permalink / raw)
To: gcc-bugs
--
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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target
2004-09-24 6:59 [Bug bootstrap/17646] New: xgcc links 64bit objects into a 32bit target olh at suse dot de
2004-09-24 11:56 ` [Bug bootstrap/17646] [4.0 Regression] " pinskia at gcc dot gnu dot org
@ 2004-10-06 5:14 ` pinskia at gcc dot gnu dot org
2004-10-06 7:28 ` olh at suse dot de
` (18 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-10-06 5:14 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target
2004-09-24 6:59 [Bug bootstrap/17646] New: xgcc links 64bit objects into a 32bit target olh at suse dot de
2004-09-24 11:56 ` [Bug bootstrap/17646] [4.0 Regression] " pinskia at gcc dot gnu dot org
2004-10-06 5:14 ` [Bug target/17646] " pinskia at gcc dot gnu dot org
@ 2004-10-06 7:28 ` olh at suse dot de
2004-10-06 7:32 ` aj at gcc dot gnu dot org
` (17 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: olh at suse dot de @ 2004-10-06 7:28 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target
2004-09-24 6:59 [Bug bootstrap/17646] New: xgcc links 64bit objects into a 32bit target olh at suse dot de
` (2 preceding siblings ...)
2004-10-06 7:28 ` olh at suse dot de
@ 2004-10-06 7:32 ` aj at gcc dot gnu dot org
2004-10-06 9:27 ` matz at suse dot de
` (16 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: aj at gcc dot gnu dot org @ 2004-10-06 7:32 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target
2004-09-24 6:59 [Bug bootstrap/17646] New: xgcc links 64bit objects into a 32bit target olh at suse dot de
` (3 preceding siblings ...)
2004-10-06 7:32 ` aj at gcc dot gnu dot org
@ 2004-10-06 9:27 ` matz at suse dot de
2004-10-06 9:29 ` matz at suse dot de
` (15 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: matz at suse dot de @ 2004-10-06 9:27 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target
2004-09-24 6:59 [Bug bootstrap/17646] New: xgcc links 64bit objects into a 32bit target olh at suse dot de
` (4 preceding siblings ...)
2004-10-06 9:27 ` matz at suse dot de
@ 2004-10-06 9:29 ` matz at suse dot de
2004-10-06 9:34 ` olh at suse dot de
` (14 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: matz at suse dot de @ 2004-10-06 9:29 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target
2004-09-24 6:59 [Bug bootstrap/17646] New: xgcc links 64bit objects into a 32bit target olh at suse dot de
` (5 preceding siblings ...)
2004-10-06 9:29 ` matz at suse dot de
@ 2004-10-06 9:34 ` olh at suse dot de
2004-10-06 9:37 ` matz at suse dot de
` (13 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: olh at suse dot de @ 2004-10-06 9:34 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target
2004-09-24 6:59 [Bug bootstrap/17646] New: xgcc links 64bit objects into a 32bit target olh at suse dot de
` (6 preceding siblings ...)
2004-10-06 9:34 ` olh at suse dot de
@ 2004-10-06 9:37 ` matz at suse dot de
2004-10-06 9:56 ` olh at suse dot de
` (12 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: matz at suse dot de @ 2004-10-06 9:37 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target
2004-09-24 6:59 [Bug bootstrap/17646] New: xgcc links 64bit objects into a 32bit target olh at suse dot de
` (7 preceding siblings ...)
2004-10-06 9:37 ` matz at suse dot de
@ 2004-10-06 9:56 ` olh at suse dot de
2004-10-06 9:59 ` matz at suse dot de
` (11 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: olh at suse dot de @ 2004-10-06 9:56 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target
2004-09-24 6:59 [Bug bootstrap/17646] New: xgcc links 64bit objects into a 32bit target olh at suse dot de
` (8 preceding siblings ...)
2004-10-06 9:56 ` olh at suse dot de
@ 2004-10-06 9:59 ` matz at suse dot de
2004-10-06 13:32 ` pinskia at gcc dot gnu dot org
` (10 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: matz at suse dot de @ 2004-10-06 9:59 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target
2004-09-24 6:59 [Bug bootstrap/17646] New: xgcc links 64bit objects into a 32bit target olh at suse dot de
` (9 preceding siblings ...)
2004-10-06 9:59 ` matz at suse dot de
@ 2004-10-06 13:32 ` pinskia at gcc dot gnu dot org
2004-10-09 15:53 ` olh at suse dot de
` (9 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-10-06 13:32 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17646
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target
2004-09-24 6:59 [Bug bootstrap/17646] New: xgcc links 64bit objects into a 32bit target olh at suse dot de
` (10 preceding siblings ...)
2004-10-06 13:32 ` pinskia at gcc dot gnu dot org
@ 2004-10-09 15:53 ` olh at suse dot de
2004-10-19 21:26 ` jgrimm2 at us dot ibm dot com
` (8 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: olh at suse dot de @ 2004-10-09 15:53 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target
2004-09-24 6:59 [Bug bootstrap/17646] New: xgcc links 64bit objects into a 32bit target olh at suse dot de
` (11 preceding siblings ...)
2004-10-09 15:53 ` olh at suse dot de
@ 2004-10-19 21:26 ` jgrimm2 at us dot ibm dot com
2004-10-27 15:38 ` jgrimm2 at us dot ibm dot com
` (7 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: jgrimm2 at us dot ibm dot com @ 2004-10-19 21:26 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target
2004-09-24 6:59 [Bug bootstrap/17646] New: xgcc links 64bit objects into a 32bit target olh at suse dot de
` (12 preceding siblings ...)
2004-10-19 21:26 ` jgrimm2 at us dot ibm dot com
@ 2004-10-27 15:38 ` jgrimm2 at us dot ibm dot com
2004-12-20 1:02 ` pinskia at gcc dot gnu dot org
` (6 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: jgrimm2 at us dot ibm dot com @ 2004-10-27 15:38 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target
2004-09-24 6:59 [Bug bootstrap/17646] New: xgcc links 64bit objects into a 32bit target olh at suse dot de
` (13 preceding siblings ...)
2004-10-27 15:38 ` jgrimm2 at us dot ibm dot com
@ 2004-12-20 1:02 ` pinskia at gcc dot gnu dot org
2004-12-20 5:57 ` aj at gcc dot gnu dot org
` (5 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-12-20 1:02 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target
2004-09-24 6:59 [Bug bootstrap/17646] New: xgcc links 64bit objects into a 32bit target olh at suse dot de
` (14 preceding siblings ...)
2004-12-20 1:02 ` pinskia at gcc dot gnu dot org
@ 2004-12-20 5:57 ` aj at gcc dot gnu dot org
2005-01-06 14:12 ` jakub at gcc dot gnu dot org
` (4 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: aj at gcc dot gnu dot org @ 2004-12-20 5:57 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target
2004-09-24 6:59 [Bug bootstrap/17646] New: xgcc links 64bit objects into a 32bit target olh at suse dot de
` (15 preceding siblings ...)
2004-12-20 5:57 ` aj at gcc dot gnu dot org
@ 2005-01-06 14:12 ` jakub at gcc dot gnu dot org
2005-01-06 14:16 ` pinskia at gcc dot gnu dot org
` (3 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: jakub at gcc dot gnu dot org @ 2005-01-06 14:12 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target
2004-09-24 6:59 [Bug bootstrap/17646] New: xgcc links 64bit objects into a 32bit target olh at suse dot de
` (16 preceding siblings ...)
2005-01-06 14:12 ` jakub at gcc dot gnu dot org
@ 2005-01-06 14:16 ` pinskia at gcc dot gnu dot org
2005-01-06 21:58 ` olh at suse dot de
` (2 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-01-06 14:16 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target
2004-09-24 6:59 [Bug bootstrap/17646] New: xgcc links 64bit objects into a 32bit target olh at suse dot de
` (17 preceding siblings ...)
2005-01-06 14:16 ` pinskia at gcc dot gnu dot org
@ 2005-01-06 21:58 ` olh at suse dot de
2005-01-06 22:42 ` pinskia at gcc dot gnu dot org
2005-01-06 23:46 ` olh at suse dot de
20 siblings, 0 replies; 22+ messages in thread
From: olh at suse dot de @ 2005-01-06 21:58 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target
2004-09-24 6:59 [Bug bootstrap/17646] New: xgcc links 64bit objects into a 32bit target olh at suse dot de
` (18 preceding siblings ...)
2005-01-06 21:58 ` olh at suse dot de
@ 2005-01-06 22:42 ` pinskia at gcc dot gnu dot org
2005-01-06 23:46 ` olh at suse dot de
20 siblings, 0 replies; 22+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2005-01-06 22:42 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread* [Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target
2004-09-24 6:59 [Bug bootstrap/17646] New: xgcc links 64bit objects into a 32bit target olh at suse dot de
` (19 preceding siblings ...)
2005-01-06 22:42 ` pinskia at gcc dot gnu dot org
@ 2005-01-06 23:46 ` olh at suse dot de
20 siblings, 0 replies; 22+ messages in thread
From: olh at suse dot de @ 2005-01-06 23:46 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 22+ messages in thread