| Summary: | Shared libgcc not used for linking by default | ||
|---|---|---|---|
| Product: | gcc | Reporter: | The Written Word <bugzilla-gcc> |
| Component: | target | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ebotcazou, gcc-bugs, sje, wilson |
| Priority: | P3 | ||
| Version: | 3.4.3 | ||
| Target Milestone: | 3.4.5 | ||
| 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) | ||
|
Description
The Written Word
2005-11-07 19:24:10 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.
(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. 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. (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. 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.
(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. 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.
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.
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.
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.
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. (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. Created attachment 10223 [details]
Backport of eh_dummy logic in gcc/mklibgcc.in from 4.0 (credit to Eric Botcazou)
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. 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. > 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.
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. > 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?
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. (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. > 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. > 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.
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. (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'. 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. (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. 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. (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. 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. 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. 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. 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. (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. > 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.
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 Fixed and checked in on 3.4 branch in time for 3.4.5. |