[Bug driver/24718] New: Shared libgcc not used for linking by default

[Bug driver/24718] New: Shared libgcc not used for linking by default

[bugzilla-gcc at thewrittenword dot com]

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)


-- 
           Summary: Shared libgcc not used for linking by default
           Product: gcc
           Version: 3.4.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: driver
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: bugzilla-gcc at thewrittenword dot com
 GCC build triplet: ia64-hp-hpux11.23
  GCC host triplet: ia64-hp-hpux11.23
GCC target triplet: ia64-hp-hpux11.23


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

[Bug target/24718] Shared libgcc not used for linking by default

[wilson at gcc dot gnu dot org]

------- 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 sources.

I do not have an ia64-hpux machine, so I can not easily investigate this.


-- 


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

[Bug target/24718] Shared libgcc not used for linking by default

[bugzilla-gcc at thewrittenword dot com]

------- 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 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.


-- 


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

[Bug target/24718] Shared libgcc not used for linking by default

[sje at cup dot hp dot com]

------- 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) -shared does not
imply -shared-libgcc but in 4.0 it does.


-- 

sje at cup dot hp dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sje at cup dot hp dot com


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

[Bug target/24718] Shared libgcc not used for linking by default

[bugzilla-gcc at thewrittenword dot com]

------- 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 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.


-- 


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

[Bug target/24718] Shared libgcc not used for linking by default

[wilson at specifix dot com]

------- 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 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.


-- 


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

[Bug target/24718] Shared libgcc not used for linking by default

[bugzilla-gcc at thewrittenword dot com]

------- 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 -------
> > 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.


-- 


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

[Bug target/24718] Shared libgcc not used for linking by default

[wilson at gcc dot gnu dot org]

------- 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 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.


-- 

wilson at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wilson at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-11-09 01:45:26
               date|                            |


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

[Bug target/24718] Shared libgcc not used for linking by default

[sje at cup dot hp dot com]

------- 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"

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.


-- 


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

[Bug target/24718] Shared libgcc not used for linking by default

[wilson at tuliptree dot org]

------- 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 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.


-- 


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

[Bug target/24718] Shared libgcc not used for linking by default

[sje at cup dot hp dot com]

------- 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 bootstrap/test now
and will submit a patch for the 3.4.* branch when I have finished testing.


-- 


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

[Bug target/24718] Shared libgcc not used for linking by default

[sje at cup dot hp dot com]

------- 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/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.


-- 


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

[Bug target/24718] Shared libgcc not used for linking by default

[bugzilla-gcc at thewrittenword dot com]

------- 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/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.


-- 


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

[Bug target/24718] Shared libgcc not used for linking by default

[bugzilla-gcc at thewrittenword dot com]

------- 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.gnu.org/bugzilla/show_bug.cgi?id=24718

[Bug target/24718] Shared libgcc not used for linking by default

[wilson at tuliptree dot org]

------- 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 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.


-- 


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

[Bug target/24718] Shared libgcc not used for linking by default

[sje at cup dot hp dot com]

------- 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

[Bug target/24718] Shared libgcc not used for linking by default

[ebotcazou at gcc dot gnu dot org]

------- 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 because the multilib logic
has changed in mklibgcc.in.


-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu dot
                   |                            |org


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

[Bug target/24718] Shared libgcc not used for linking by default

[sje at cup dot hp dot com]

------- 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

[Bug target/24718] Shared libgcc not used for linking by default

[ebotcazou at gcc dot gnu dot org]

------- 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 -mlp64?


-- 


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

[Bug target/24718] Shared libgcc not used for linking by default

[sje at cup dot hp dot com]

------- 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 when compiling and
linking C or C++, with or without -mlp64 and with or without -shared.


-- 


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

[Bug target/24718] Shared libgcc not used for linking by default

[bugzilla-gcc at thewrittenword dot com]

------- 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 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.


-- 


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

[Bug target/24718] Shared libgcc not used for linking by default

[ebotcazou at gcc dot gnu dot org]

------- 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 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.


-- 


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

[Bug target/24718] Shared libgcc not used for linking by default

[ebotcazou at gcc dot gnu dot org]

------- 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 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.


-- 


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

[Bug target/24718] Shared libgcc not used for linking by default

[sje at cup dot hp dot com]

------- 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 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.


-- 


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

[Bug target/24718] Shared libgcc not used for linking by default

[bugzilla-gcc at thewrittenword dot com]

------- 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 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'.


-- 


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

[Bug target/24718] Shared libgcc not used for linking by default

[sje at cup dot hp dot com]

------- 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 look OK to
me, I.e. they have a symbol table in them and thus should not get the warning
message.


-- 


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

[Bug target/24718] Shared libgcc not used for linking by default

[bugzilla-gcc at thewrittenword dot com]

------- 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 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.


-- 


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

[Bug target/24718] Shared libgcc not used for linking by default

[sje at cup dot hp dot com]

------- 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 assembler are
you using when you get the problem.


-- 


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

[Bug target/24718] Shared libgcc not used for linking by default

[bugzilla-gcc at thewrittenword dot com]

------- 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 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.


-- 


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

[Bug target/24718] Shared libgcc not used for linking by default

[sje at cup dot hp dot com]

------- 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_bug.cgi?id=24718

[Bug target/24718] Shared libgcc not used for linking by default

[sje at cup dot hp dot com]

------- 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.


-- 


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

[Bug target/24718] Shared libgcc not used for linking by default

[bugzilla-gcc at thewrittenword dot com]

------- 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.cgi?id=24718

[Bug target/24718] Shared libgcc not used for linking by default

[sje at cup dot hp dot com]

------- 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

[Bug target/24718] Shared libgcc not used for linking by default

[bugzilla-gcc at thewrittenword dot com]

------- 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://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718

[Bug target/24718] Shared libgcc not used for linking by default

[ebotcazou at gcc dot gnu dot org]

------- 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 Steve.


-- 


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

[Bug target/24718] Shared libgcc not used for linking by default

[sje at gcc dot gnu dot org]

------- 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 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


-- 


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

[Bug target/24718] Shared libgcc not used for linking by default

[sje at cup dot hp dot com]

------- 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
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |3.4.5


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