GCC Bugzilla will be upgraded from version 4.4.9 to 5.0rc3 on Saturday, April 25, starting around 17:00 UTC. The upgrade process should only last a few minutes. Check bug 64968 for details.
Bug 24718 - Shared libgcc not used for linking by default
Shared libgcc not used for linking by default
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: target
3.4.3
: P3 normal
: 3.4.5
Assigned To: Not yet assigned to anyone
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-07 19:24 UTC by The Written Word
Modified: 2005-12-01 21:03 UTC (History)
4 users (show)

See Also:
Host: ia64-hp-hpux11.23
Target: ia64-hp-hpux11.23
Build: ia64-hp-hpux11.23
Known to work:
Known to fail:
Last reconfirmed: 2005-11-09 01:45:26


Attachments
Backport of eh_dummy logic in gcc/mklibgcc.in from 4.0 (credit to Eric Botcazou) (1.36 KB, patch)
2005-11-11 22:00 UTC, The Written Word
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description The Written Word 2005-11-07 19:24:10 UTC
I've built gcc-3.4.3 for HP-UX 11.23/IA-64 and used the pre-compiled
gcc-3.4.4 binary from the http://www.hp.com/go/gcc site. Both exhibit
the same problem. While trying to build Perl 5.8.6:
  $ gmake
  ...  
  gcc -v -o libperl.so -shared -fPIC perl.o  gv.o toke.o perly.o op.o
pad.o regcomp.o dump.o util.o mg.o reentr.o hv.o av.o run.o pp_hot.o
sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o
taint.o deb.o universal.o xsutils.o globals.o perlio.o perlapi.o
numeric.o locale.o pp_pack.o pp_sort.o  -lcl -lnsl -lnm -ldl -ldld -lm
-lsec -lpthread -lc
  ...
 /opt/TWWfsw/gcc343/libexec/gcc/ia64-hp-hpux11.23/3.4.3/collect2
+Accept TypeMismatch -b -o libperl.so -L/opt/TWWfsw/gcc343r/lib
-L/opt/TWWfsw/gcc343/lib/gcc/ia64-hp-hpux11.23/3.4.3 -L/usr/ccs/bin
-L/usr/ccs/lib
-L/opt/TWWfsw/gcc343/lib/gcc/ia64-hp-hpux11.23/3.4.3/../../.. perl.o
gv.o toke.o perly.o op.o pad.o regcomp.o dump.o util.o mg.o reentr.o
hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o
doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o
perlio.o perlapi.o numeric.o locale.o pp_pack.o pp_sort.o -lcl -lnsl
-lnm -ldl -ldld -lm -lsec -lpthread -lc -lgcc -lgcc
                                        ^^^^^^^^^^^

Notice the "-lgcc -lgcc" at the end of the collect2 command-line, not "-lgcc_s -lgcc_s".

On HP-UX 11.23/PA-RISC, I get:
  /opt/TWWfsw/gcc343/libexec/gcc/hppa2.0-hp-hpux11.23/3.4.3/collect2
-z -b -o libperl.sl -L/opt/TWWfsw/gcc343r/lib
-L/opt/TWWfsw/gcc343r/lib
-L/opt/TWWfsw/gcc343/lib/gcc/hppa2.0-hp-hpux11.23/3.4.3 -L/usr/ccs/bin
-L/usr/ccs/lib -L/opt/langtools/lib -L/opt/TWWfsw/gcc343/lib perl.o
gv.o toke.o perly.o op.o pad.o regcomp.o dump.o util.o mg.o reentr.o
hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o
doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o
perlio.o perlapi.o numeric.o locale.o pp_pack.o pp_sort.o -lcl -lnsl
-lnm -lmalloc -ldld -lm -lcrypt -lsec -lpthread -lc -lgcc_s -lgcc_s

Using the HP pre-compiled binary of gcc-4.0.2, I get:
 /opt/hp-gcc/4.0.2/bin/../libexec/gcc/ia64-hp-hpux11.23/4.0.2/collect2
-z +Accept TypeMismatch -b -o libperl.so
-L/opt/hp-gcc/4.0.2/bin/../lib/gcc/ia64-hp-hpux11.23/4.0.2
-L/opt/hp-gcc/4.0.2/bin/../lib/gcc
-L/opt/hp-gcc/4.0.2//lib/gcc/ia64-hp-hpux11.23/4.0.2 -L/usr/ccs/bin
-L/usr/ccs/lib
-L/opt/hp-gcc/4.0.2/bin/../lib/gcc/ia64-hp-hpux11.23/4.0.2/../../..
-L/opt/hp-gcc/4.0.2//lib/gcc/ia64-hp-hpux11.23/4.0.2/../../.. perl.o
gv.o toke.o perly.o op.o pad.o regcomp.o dump.o util.o mg.o reentr.o
hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o
doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o
perlio.o perlapi.o numeric.o locale.o pp_pack.o pp_sort.o -lcl -lnsl
-lnm -ldl -ldld -lm -lsec -lpthread -lc -lgcc_s -lunwind -lgcc_s
-lunwind

The "*libgcc" line from the 3.4.3/3.4.4 specs file:
  *libgcc:
  %{shared-libgcc:%{!mlp64:-lgcc_s}%{mlp64:-lgcc_s_hpux64} %{static|static-libgcc:-lgcc -lgcc_eh
-lunwind}%{!static:%{!static-libgcc:%{!shared:%{!shared-libgcc:-lgcc -lgcc_eh
-lunwind}%{shared-libgcc:-lgcc_s%M -lunwind -lgcc}}%{shared:-lgcc_s%M
-lunwind}}}}    %{!shared-libgcc:-lgcc}

The "*libgcc" line from the 4.0.2 specs file (via -dumpspecs):
  *libgcc:
  %{static|static-libgcc:-lgcc -lgcc_eh -lunwind}%{!static:%{!static-libgcc:%{!shared:%{!shared-libgcc:-lgcc -lgcc_eh -lunwind}%{shared-libgcc:-lgcc_s -lunwind -lgcc}}%{shared:-lgcc_s -lunwind}}}

Is the problem in the "*libgcc" entry? It seems !shared-libgcc is true, though I don't know why.
  $ /opt/TWWfsw/gcc343/bin/gcc -v
  Reading specs from
  /opt/TWWfsw/gcc343/lib/gcc/ia64-hp-hpux11.23/3.4.3/specs
  Configured with: /opt/build/gcc-3.4.3/configure --with-gnu-as
  --with-as=/opt/TWWfsw/gcc343/ia64-hp-hpux11.23/bin/as
  --with-included-gettext --enable-shared
  --datadir=/opt/TWWfsw/gcc343/share --enable-languages=c,c++,f77
  --with-local-prefix=/opt/TWWfsw/gcc343 --prefix=/opt/TWWfsw/gcc343
  Thread model: single
  gcc version 3.4.3 (TWW)
Comment 1 Jim Wilson 2005-11-08 01:41:15 UTC
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 sources.

I do not have an ia64-hpux machine, so I can not easily investigate this.
Comment 2 The Written Word 2005-11-08 03:15:15 UTC
(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 as I do not
> see this problem in the FSF sources.

Note the HP gcc-3.4.4 binary had the same problem. I just built gcc-3.4.4 with just one patch to fix the sco_math issue in PR24688:
  http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00985.html

The new binary exhibits the same problem.
Comment 3 Steve Ellcey 2005-11-08 21:22:03 UTC
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) -shared does not imply -shared-libgcc but in 4.0 it does.
Comment 4 The Written Word 2005-11-08 21:49:03 UTC
(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 this might have happened, that in 3.4 (with C) -shared does not
> imply -shared-libgcc but in 4.0 it does.

If -shared did not imply -shared-libgcc, why does gcc -shared on HP-UX 10.20/PA, 11.00/PA, 11.11/PA, and 11.23/PA behave as if -shared-libgcc was included? The question is why HP-UX 11.23/IA-64 is different than HP-UX/PA.
Comment 5 wilson@specifix.com 2005-11-09 00:34:16 UTC
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 is an obvious bug.  Have you actually looked at the specs in 
question?  They have %{shared-libgcc ... %{static-libgcc ...}} which 
can't possibly be right.

However, there is no bug in FSF gcc.  I suspect a bug in the gcc sources 
being distributed from the HP web site.  I haven't checked that.
Comment 6 The Written Word 2005-11-09 00:47:47 UTC
(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 -------
> > I am not convinced that this is a bug.
> 
> There is an obvious bug.  Have you actually looked at the specs in 
> question?  They have %{shared-libgcc ... %{static-libgcc ...}} which 
> can't possibly be right.
> 
> However, there is no bug in FSF gcc.  I suspect a bug in the gcc sources 
> being distributed from the HP web site.  I haven't checked that.

As indicated in comment #2, we built gcc-3.4.4 from the FSF sources and still encountered the bug.
Comment 7 Jim Wilson 2005-11-09 01:45:26 UTC
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 rules for shared and static libgcc.

The config/ia64/hpux.h file redefines LIBGCC_SPEC as 
#define LIBGCC_SPEC \
  "%{shared-libgcc:%{!mlp64:-lgcc_s}%{mlp64:-lgcc_s_hpux64} -lgcc} \
   %{!shared-libgcc:-lgcc}"

So after the substitution, we now have %{shared-libgcc ... %{static-libgcc ...}} which is obviously wrong.

If the config/ia64/hpux.h file is changed to look something like
#define LIBGCC_SPEC \
  "%{shared-libgcc:%{!mlp64:-lgcc_s}%{mlp64:-lgcc_s_hpux64}} -lgcc"
then it will work much better.  I think this can be simplified further without loss of functionality to
#define LIBGCC_SPEC \
  "%{shared-libgcc:%{mlp64:-lgcc_s_hpux64}} -lgcc"
The important part here is that -lgcc must not appear inside any braces, because it will be substituted by init_gcc_specs.

Alternatively, we could try disabling the init_gcc_specs rewriting for the ia64-hpux target, and then putting the entire rule we want in the config/ia64/hpux.h file, but I don't think that big of a patch is needed.

A better alternative would be deleting the LIBGCC_SPEC rule in config/ia64/hpux.h, but I don't know if that will work.  That might result in the libgcc_s_hpux64 file not being used anymore.  I also don't know whether that matters.  I would guess that the multilibbing support should find and use it automatically, so in theory it shouldn't be needed, but I am unable to check.

gcc-4.0 and later do not have a problem, because they don't define LIBGCC_SPEC in the config/ia64/hpux.h file.

I can't test the suggested patches, as I don't have an ia64-hpux machine.
Comment 8 Steve Ellcey 2005-11-10 00:08:08 UTC
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"

But if I compile with -shared, I still see -lgcc:

        install/bin/gcc -shared -v hi.c -o x.so

        /proj/opensrc/sje/svn/gcc.34/install/libexec/gcc/ia64-hp-hpux11.23/3.4.4
/collect2 +Accept TypeMismatch -b -o x.so -L/proj/opensrc/sje/svn/gcc.34/install
/lib/gcc/ia64-hp-hpux11.23/3.4.4 -L/usr/ccs/bin -L/usr/ccs/lib -L/proj/opensrc/s
je/svn/gcc.34/install/lib/gcc/ia64-hp-hpux11.23/3.4.4/../../.. /var/tmp//ccJVUul
W.o -lgcc -lgcc

If I look at the specs file I see:

*libgcc:
%{shared-libgcc:%{mlp64:-lgcc_s_hpux64}} -lgcc

I am not sure what is going on here.
Comment 9 Jim Wilson 2005-11-10 03:04:27 UTC
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 the problem.

Try debugging init_specs where it calls init_gcc_specs.  There might be
something about the code that is causing it to misbehave for you.  Don't
configure with --disable-shared, that will prevent this code from doing
anything.

It occurred to me that another possible solution is to change init_specs
and/or the ia64-hpux LIBGCC_SPEC so that all uses of -lgcc will be
replaced instead of just the first one.  That would also fix the
problem.  Looking at the code, I think adding a space before the second
-lgcc in the current ia64-hpux LIBGCC_SPEC would do the trick, because
that will cause in_sep to be set again.


Comment 10 Steve Ellcey 2005-11-10 18:20:41 UTC
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 bootstrap/test now and will submit a patch for the 3.4.* branch when I have finished testing.
Comment 11 Steve Ellcey 2005-11-11 21:39:34 UTC
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/gcc/ia64-hp-hpux11.23/3.4.5/libgcc_eh.a, it might be mis
sing or corrupted. Skipping library /proj/opensrc/sje/test2/gcc-ia64-hp-hpux11.2
3-std/lib/gcc/ia64-hp-hpux11.23/3.4.5/libgcc_eh.a.

because libgcc_eh.a is empty.  For some reason on 3.4 this file is completely empty (nm returns nothing) but on ToT the file is mostly empty, but it has
a symbol table and empty test/bss/data and debug sections in it.  On 3.4 I have
no symbol table in the file which is why I get the warning message.  I used the same binutils for each compiler so I don't know yet why there is this difference.

Comment 12 The Written Word 2005-11-11 21:58:37 UTC
(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/opensrc/sje/test2/gcc-ia
> 64-hp-hpux11.23-std/lib/gcc/ia64-hp-hpux11.23/3.4.5/libgcc_eh.a, it might be
> mis
> sing or corrupted. Skipping library
> /proj/opensrc/sje/test2/gcc-ia64-hp-hpux11.2
> 3-std/lib/gcc/ia64-hp-hpux11.23/3.4.5/libgcc_eh.a.
> 
> because libgcc_eh.a is empty.  For some reason on 3.4 this file is completely
> empty (nm returns nothing) but on ToT the file is mostly empty, but it has
> a symbol table and empty test/bss/data and debug sections in it.  On 3.4 I have
> no symbol table in the file which is why I get the warning message.  I used the
> same binutils for each compiler so I don't know yet why there is this
> difference.
> 

Look at gcc/mklibgcc.in in the 4.0 branch. They add a dummy eh_dummy.o file to libgcc_eh.a to work around this. We had Eric Botcazou backport it to the 3.4 branch for us but a PR hasn't been created. I don't know if its considered a safe enough fix. I haven't tested it yet but I'll attach the patch to this PR.
Comment 13 The Written Word 2005-11-11 22:00:04 UTC
Created attachment 10223 [details]
Backport of eh_dummy logic in gcc/mklibgcc.in from 4.0 (credit to Eric Botcazou)
Comment 14 Jim Wilson 2005-11-11 22:15:56 UTC
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 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

See this patch:
    http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01123.html
The first part of it fixes this problem.  The second part may not be
safe without other changes.

2005-02-19  Zack Weinberg  <zack@codesourcery.com>

        * mklibgcc.in: If libgcc_eh.a would be empty, put a dummy
        object inside.
        * config/ia64/hpux.h: Don't define LIBGCC_SPEC.



Comment 15 Steve Ellcey 2005-11-11 23:42:29 UTC
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.
Comment 16 Eric Botcazou 2005-11-12 08:17:37 UTC
> 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 because the multilib logic has changed in mklibgcc.in.
Comment 17 Steve Ellcey 2005-11-14 15:44:23 UTC
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.
Comment 18 Eric Botcazou 2005-11-14 15:52:42 UTC
> 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 -mlp64?
Comment 19 Steve Ellcey 2005-11-14 16:01:42 UTC
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 when compiling and linking C or C++, with or without -mlp64 and with or without -shared.
Comment 20 The Written Word 2005-11-14 16:07:32 UTC
(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 do not getting any warnings messages from ld when compiling and
> linking C or C++, with or without -mlp64 and with or without -shared.

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 add enough symbolic information to the archive library. Change it to 'int __libgcc_eh_dummy;' worked for us.

Looking at Zack's patch, I don't see how eh_dummy.o would get added to libgcc_eh.a on gcc-3.4 without adding it to $libgcc2_eh_static_objs.
Comment 21 Eric Botcazou 2005-11-14 16:09:59 UTC
> 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 when compiling and
> linking C or C++, with or without -mlp64 and with or without -shared.

I must have dreamt... could you send to <ebotcazou@libertysurf.fr> the patched 3.4.x mklibgcc.in as well as the generated $objdir/gcc/libgcc.mk?  Thanks in advance.
Comment 22 Eric Botcazou 2005-11-14 16:28:16 UTC
> 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 add enough symbolic information to
> the archive library. Change it to 'int __libgcc_eh_dummy;' worked for us.

It could be nice to compare the versions of 'ar' and 'ranlib' you have.
Comment 23 Steve Ellcey 2005-11-14 16:33:36 UTC
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 may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.

ranlib --version
GNU ranlib 2.16.91 20051103
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.
Comment 24 The Written Word 2005-11-14 16:59:22 UTC
(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 but ar doesn't work:
$ ./ar
/usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylsp' in load module '/usr/lib/hpux32/libl.so.1'.
/usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyolsp' in load module '/usr/lib/hpux32/libl.so.1'.
/usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyfnd' in load module '/usr/lib/hpux32/libl.so.1'.
/usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yytextuc' in load module '/usr/lib/hpux32/libl.so.1'.
/usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylenguc' in load module '/usr/lib/hpux32/libl.so.1'.
/usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylstate' in load module '/usr/lib/hpux32/libl.so.1'.
/usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyprevious' in load module '/usr/lib/hpux32/libl.so.1'.
/usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yytextarr' in load module '/usr/lib/hpux32/libl.so.1'.
/usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyextra' in load module '/usr/lib/hpux32/libl.so.1'.
Comment 25 Steve Ellcey 2005-11-14 17:05:42 UTC
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 look OK to me, I.e. they have a symbol table in them and thus should not get the warning message.
Comment 26 The Written Word 2005-11-14 17:18:53 UTC
(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 just building eh_dummy.o and .a by hand and they look OK to
> me, I.e. they have a symbol table in them and thus should not get the warning
> message.

Ok, I have a working binutils-2.16 ar. And, binutils-2.16 ar creates a libgcc_eh.a that does not cause linker errors whereas HP as does _not_, with the _same_ eh_dummy.o file. Replace your libgcc_eh.a in your GCC tree with the version created by the system ar and I expect you'll see the same as me.
Comment 27 Steve Ellcey 2005-11-14 17:26:35 UTC
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 assembler are you using when you get the problem.
Comment 28 The Written Word 2005-11-14 17:29:39 UTC
(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 using the binutils as (assembler) command.  Which assembler are
> you using when you get the problem.

Oops. "HP as" -> "HP ar". So, with a eh_dummy.o created from an eh_dummy.c with 'struct eh_dummy;', libgcc_eh.a created by HP ar gives me a linker warning and a libgcc_eh.a created by binutils-2.16 ar does not give me a linker warning.
Comment 29 Steve Ellcey 2005-11-14 17:31:36 UTC
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.
Comment 30 Steve Ellcey 2005-11-14 17:35:32 UTC
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 31 The Written Word 2005-11-14 17:41:13 UTC
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.
Comment 32 Steve Ellcey 2005-11-14 17:46:51 UTC
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.
Comment 33 The Written Word 2005-11-14 17:51:30 UTC
(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.
Comment 34 Eric Botcazou 2005-11-14 17:51:44 UTC
> 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 Steve.
Comment 35 Steve Ellcey 2005-11-16 17:06:56 UTC
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 for libgcc_eh.a
	* config/ia64/hpux.h (LIBGCC_SPEC): Remove.

Modified:
    branches/gcc-3_4-branch/gcc/ChangeLog
    branches/gcc-3_4-branch/gcc/config/ia64/hpux.h
    branches/gcc-3_4-branch/gcc/mklibgcc.in

Comment 36 Steve Ellcey 2005-12-01 21:03:36 UTC
Fixed and checked in on 3.4 branch in time for 3.4.5.