--- Comment #10 from jakub at gcc dot gnu dot org 2008-11-12 21:04 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--- Comment #7 from jsm28 at gcc dot gnu dot org 2008-02-01 16:54 ---
4.2.3 is being released now, changing milestones of open bugs to 4.2.4.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.4 |4.2.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33764
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-12 17:53 ---
P2.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3
--- Comment #3 from tromey at gcc dot gnu dot org 2008-01-09 22:03 ---
What should we do here?
I think the problem is that we have a single bindir, but we are
building multiple executables -- one per multilib.
--
tromey at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from rguenther at suse dot de 2008-01-09 22:14 ---
Subject: Re: [4.2/4.3 regression] gij is built as 32-bit
binary when building multilib gcc
On Wed, 9 Jan 2008, tromey at gcc dot gnu dot org wrote:
--- Comment #3 from tromey at gcc dot gnu dot org 2008-01-09
--- Comment #5 from tromey at gcc dot gnu dot org 2008-01-09 22:17 ---
Yeah. We have to make the binaries where we do. They rely on the
libraries we just built.
I suppose we could try to make a bin64 or whatever.
That sounds like a lot of work.
Maybe we could disable the executables
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-10-22 08:43 ---
This is most likely a timming issue. That is the 64bit multilib is built first
and then it rebuilds it as a 32bit program.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
