--- Comment #36 from sje at cup dot hp dot com 2005-12-01 21:03 ---
Fixed and checked in on 3.4 branch in time for 3.4.5.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #35 from sje at gcc dot gnu dot org 2005-11-16 17:06 ---
Subject: Bug 24718
Author: sje
Date: Wed Nov 16 17:06:52 2005
New Revision: 107090
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107090
Log:
PR target/24718
* mklibgcc.in: Create dummy object f
--- Comment #34 from ebotcazou at gcc dot gnu dot org 2005-11-14 17:51
---
> Sure. I don't understand how Zack's patch works but as long as we have a
> solution that works, fine by me. Eric might be interested in reviewing the
> patch too.
The misunderstanding has been cleared with Ste
--- Comment #33 from bugzilla-gcc at thewrittenword dot com 2005-11-14
17:51 ---
(In reply to comment #32)
> Do you see this problem on the Top-of-tree and/or 4.0 sources? That seems to
> use the same eh_dummy.c file (struct eh_dummy;) as 3.4.
4.0.2 had the same problem.
--
http:
--- Comment #32 from sje at cup dot hp dot com 2005-11-14 17:46 ---
Do you see this problem on the Top-of-tree and/or 4.0 sources? That seems to
use the same eh_dummy.c file (struct eh_dummy;) as 3.4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
--- Comment #31 from bugzilla-gcc at thewrittenword dot com 2005-11-14
17:41 ---
Sure. I don't understand how Zack's patch works but as long as we have a
solution that works, fine by me. Eric might be interested in reviewing the
patch too.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #30 from sje at cup dot hp dot com 2005-11-14 17:35 ---
OK, I have reproduced it with GNU as (assembler) and HP ar. Should we bypass
the whole issue by putting 'int __libgcc_eh_dummy;' in eh_dummy.o and use that
as the 3.4 patch? I am willing to test and submit such a patch
--- Comment #29 from sje at cup dot hp dot com 2005-11-14 17:31 ---
In my comment I meant to say I could reproduce the problem with the HP
assembler, but not with the GNU assembler (even if I use the GNU ar). I will
test some more combinations.
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #28 from bugzilla-gcc at thewrittenword dot com 2005-11-14
17:29 ---
(In reply to comment #27)
> In your last comment you mention the binutils ar, but later the binutils as.
> I
> cannot reproduce the problem by just using the binutils ar command but I can
> reproduce it u
--- Comment #27 from sje at cup dot hp dot com 2005-11-14 17:26 ---
In your last comment you mention the binutils ar, but later the binutils as. I
cannot reproduce the problem by just using the binutils ar command but I can
reproduce it using the binutils as (assembler) command. Which
--- Comment #26 from bugzilla-gcc at thewrittenword dot com 2005-11-14
17:18 ---
(In reply to comment #25)
> I build binutils with --disable-shared and using flex/bison instead of
> lex/yacc, that is probably why my ar works. I experimented with the use of
> the
> system ar/ranlib by
--- Comment #25 from sje at cup dot hp dot com 2005-11-14 17:05 ---
I build binutils with --disable-shared and using flex/bison instead of
lex/yacc, that is probably why my ar works. I experimented with the use of the
system ar/ranlib by just building eh_dummy.o and .a by hand and they
--- Comment #24 from bugzilla-gcc at thewrittenword dot com 2005-11-14
16:59 ---
(In reply to comment #23)
> I build binutils 2.16 as part of my GCC build/test so I used that ar and
> ranlib
> when building GCC:
We're using the system ar/ranlib. I built binutils-2.16 with _no_ patches
--- Comment #23 from sje at cup dot hp dot com 2005-11-14 16:33 ---
I build binutils 2.16 as part of my GCC build/test so I used that ar and ranlib
when building GCC:
ar --version
GNU ar 2.16.91 20051103
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you ma
--- Comment #22 from ebotcazou at gcc dot gnu dot org 2005-11-14 16:28
---
> Odd. We have the latest linker patch installed on our system (PHSS_33349) and
> applying Eric's patch added eh_dummy.o to libgcc_eh.a but the linker still
> gave
> a warning. I guess 'struct eh_dummy;' didn't
--- Comment #21 from ebotcazou at gcc dot gnu dot org 2005-11-14 16:09
---
> Yes, I checked the installed libgcc_eh.a
> (lib/gcc/ia64-hp-hpux11.23/3.4.5/libgcc_eh.a and
> lib/gcc/ia64-hp-hpux11.23/3.4.5/hpux64/libgcc_eh.a) and both contain
> eh_dummy.o. I do not getting any warnings mes
--- Comment #20 from bugzilla-gcc at thewrittenword dot com 2005-11-14
16:07 ---
(In reply to comment #19)
> Yes, I checked the installed libgcc_eh.a
> (lib/gcc/ia64-hp-hpux11.23/3.4.5/libgcc_eh.a and
> lib/gcc/ia64-hp-hpux11.23/3.4.5/hpux64/libgcc_eh.a) and both contain
> eh_dummy.o. I
--- Comment #19 from sje at cup dot hp dot com 2005-11-14 16:01 ---
Yes, I checked the installed libgcc_eh.a
(lib/gcc/ia64-hp-hpux11.23/3.4.5/libgcc_eh.a and
lib/gcc/ia64-hp-hpux11.23/3.4.5/hpux64/libgcc_eh.a) and both contain
eh_dummy.o. I do not getting any warnings messages from ld wh
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2005-11-14 15:52
---
> Eric, can you be more specific about what won't work? The regression testing
> with Zack's patch seemed to go fine and hand testing some cases looks OK too.
Do you have a eh_dummy.o file for both -milp32 and
--- Comment #17 from sje at cup dot hp dot com 2005-11-14 15:44 ---
Eric, can you be more specific about what won't work? The regression testing
with Zack's patch seemed to go fine and hand testing some cases looks OK too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2005-11-12 08:17
---
> The patch from comment 14 seems to be working fine without any other changes.
> I have bootstrapped and am currently running the testsuite. Looks OK so far.
Zack's patch for 4.x doesn't work as-is for 3.4.x
--- Comment #15 from sje at cup dot hp dot com 2005-11-11 23:42 ---
The patch from comment 14 seems to be working fine without any other changes.
I have bootstrapped and am currently running the testsuite. Looks OK so far.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
--- Comment #14 from wilson at tuliptree dot org 2005-11-11 22:15 ---
Subject: Re: Shared libgcc not used for linking by
default
On Fri, 2005-11-11 at 13:39, sje at cup dot hp dot com wrote:
> --- Comment #11 from sje at cup dot hp dot com 2005-11-11 21:39 ---
> I have
--- Comment #13 from bugzilla-gcc at thewrittenword dot com 2005-11-11
22:00 ---
Created an attachment (id=10223)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10223&action=view)
Backport of eh_dummy logic in gcc/mklibgcc.in from 4.0 (credit to Eric
Botcazou)
--
http://gcc.gn
--- Comment #12 from bugzilla-gcc at thewrittenword dot com 2005-11-11
21:58 ---
(In reply to comment #11)
> I have run into a problem with my testing, the link line looks good but I get
> warnings from the HP linker like:
>
> ld: (Warning) Cannot load library symbol table in
> /proj/o
--- Comment #11 from sje at cup dot hp dot com 2005-11-11 21:39 ---
I have run into a problem with my testing, the link line looks good but I get
warnings from the HP linker like:
ld: (Warning) Cannot load library symbol table in
/proj/opensrc/sje/test2/gcc-ia
64-hp-hpux11.23-std/lib/gc
--- Comment #10 from sje at cup dot hp dot com 2005-11-10 18:20 ---
I can't believe I configured with --disable-shared. OK, without that things
look better. I changed LIBGCC to "%{shared-libgcc:%{mlp64:-lgcc_s_hpux64}}
-lgcc" and I get -lgcc_s on the link command. I am doing a bootstr
--- Comment #9 from wilson at tuliptree dot org 2005-11-10 03:04 ---
Subject: Re: Shared libgcc not used for linking by
default
On Wed, 2005-11-09 at 16:08, sje at cup dot hp dot com wrote:
> I tried Jim Wilson's suggested changes (with 3.4.4 GCC) but they didn't
> seem to fix
--- Comment #8 from sje at cup dot hp dot com 2005-11-10 00:08 ---
I tried Jim Wilson's suggested changes (with 3.4.4 GCC) but they didn't
seem to fix the problem.
I changed LIBGCC_SPEC to:
#define LIBGCC_SPEC \
"%{shared-libgcc:%{mlp64:-lgcc_s_hpux64}} -lgcc"
--- Comment #7 from wilson at gcc dot gnu dot org 2005-11-09 01:45 ---
I see the problem now. It is present in the FSF gcc-3.4.x sources.
The problem is that init_gcc_specs in gcc.c rewrites the LIBGCC_SPEC rule. It
looks for the first -lgcc, and replaces it with target independent ru
--- Comment #6 from bugzilla-gcc at thewrittenword dot com 2005-11-09
00:47 ---
(In reply to comment #5)
> Subject: Re: Shared libgcc not used for linking by default
>
> sje at cup dot hp dot com wrote:
> > --- Comment #3 from sje at cup dot hp dot com 2005-11-08 21:22 ---
>
--- Comment #5 from wilson at specifix dot com 2005-11-09 00:34 ---
Subject: Re: Shared libgcc not used for linking by default
sje at cup dot hp dot com wrote:
> --- Comment #3 from sje at cup dot hp dot com 2005-11-08 21:22 ---
> I am not convinced that this is a bug.
There
--- Comment #4 from bugzilla-gcc at thewrittenword dot com 2005-11-08
21:49 ---
(In reply to comment #3)
> I am not convinced that this is a bug. Was there an intentional change
> between
> 3.4.* and 4.0 that made -shared imply -shared-libgcc? I can't find one but it
> seems like thi
--- Comment #3 from sje at cup dot hp dot com 2005-11-08 21:22 ---
I am not convinced that this is a bug. Was there an intentional change between
3.4.* and 4.0 that made -shared imply -shared-libgcc? I can't find one but it
seems like this might have happened, that in 3.4 (with C) -sha
--- Comment #2 from bugzilla-gcc at thewrittenword dot com 2005-11-08
03:15 ---
(In reply to comment #1)
> See the thread on the gcc list discussing this bug.
> http://gcc.gnu.org/ml/gcc/2005-11/msg00331.html
>
> I suspect this is a bug in patches applied to the gcc-3.4.x sources a
--- Comment #1 from wilson at gcc dot gnu dot org 2005-11-08 01:41 ---
See the thread on the gcc list discussing this bug.
http://gcc.gnu.org/ml/gcc/2005-11/msg00331.html
I suspect this is a bug in patches applied to the gcc-3.4.x sources as I do not
see this problem in the FSF sour
36 matches
Mail list logo
