http://sourceware.org/bugzilla/show_bug.cgi?id=13229
--- Comment #21 from cvs-commit at gcc dot gnu.org 2011-10-25 02:54:28 UTC ---
CVSROOT:/cvs/src
Module name:src
Branch: binutils-2_22-branch
Changes by:amo...@sourceware.org2011-10-25 02:54:25
Modified files:
bfd
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
--- Comment #20 from cvs-commit at gcc dot gnu.org 2011-10-25 02:51:26 UTC ---
CVSROOT:/cvs/src
Module name:src
Branch: binutils-2_22-branch
Changes by:amo...@sourceware.org2011-10-25 02:51:22
Modified files:
ld
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
--- Comment #18 from cvs-commit at gcc dot gnu.org 2011-10-08 07:50:24 UTC ---
CVSROOT:/cvs/src
Module name:src
Changes by:amo...@sourceware.org2011-10-08 07:50:19
Modified files:
bfd: ChangeLog elflink.c
Log
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
--- Comment #17 from Alan Modra 2011-10-08 07:48:34
UTC ---
This was the v2 implementation commit, which didn't appear here because I
typoed the pr number.
http://sourceware.org/ml/binutils-cvs/2011-10/msg00019.html
This one didn't appear her
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
--- Comment #16 from H.J. Lu 2011-10-07 16:47:06
UTC ---
(In reply to comment #15)
> elf_link_output_extsym shouldn't output any plugin symbols.
A patch is posed at
http://sourceware.org/ml/binutils/2011-10/msg00034.html
It also fixes PR 13
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
--- Comment #15 from H.J. Lu 2011-10-07 00:02:05
UTC ---
elf_link_output_extsym shouldn't output any plugin symbols.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: --
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
--- Comment #14 from Jan Hubicka 2011-10-06
19:09:55 UTC ---
Hmm, reproducing the situation is harder with the COMDAT hack in your compiler.
Here is testcase that reproduces w/o GCC patch.
With BFD and patch for V2 API:
jh@evans:/abuild/jh/t
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
--- Comment #13 from H.J. Lu 2011-10-05 21:41:29
UTC ---
(In reply to comment #12)
> The follwing should work in C++
>
> inline void test (void)
> {
> call_something();
> }
> void test2 (void)
> {
> test();
> }
>
> and compile with -flt
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
--- Comment #12 from hubicka at ucw dot cz 2011-10-05 20:49:35 UTC ---
>
> /* This is the prevailing definition of the symbol, with no
> references from regular objects. It is only referenced from IR
> code, but the symbol is expor
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #11 f
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
--- Comment #10 from Jan Hubicka 2011-10-01
15:51:57 UTC ---
I was wrong about .h trickery. It is default visibility in both libraries, but
because libxul do not link with any library that would (mistakely) export it,
it gets optimized out the
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
--- Comment #9 from Jan Hubicka 2011-10-01
15:19:27 UTC ---
OK,
I now understand the problem. It is partly GNU LD issue.
What happens is
1) nsGNOMEShellService includes header that define gfxUnknownSurface.
The class is obviously uunused
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
--- Comment #8 from hubicka at ucw dot cz 2011-10-01 14:23:01 UTC ---
Hi,
the following is a diff from GNU LD to Gold build. I previously complained
about RESOLVED_DYN/UNDEF difference. It is harmless since internall for GCC it
does not make di
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
--- Comment #7 from hubicka at ucw dot cz 2011-10-01 13:50:13 UTC ---
> http://sourceware.org/bugzilla/show_bug.cgi?id=13229
>
> --- Comment #6 from hubicka at ucw dot cz 2011-10-01 13:14:11 UTC ---
> > I guess Gold is just tolerant here and I
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
--- Comment #6 from hubicka at ucw dot cz 2011-10-01 13:14:11 UTC ---
> I guess Gold is just tolerant here and I would say that GNU LD should be too.
> I will work out how this symbol appears in the symbol table.
Filled in as PR13244.
Honza
--
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
--- Comment #5 from hubicka at ucw dot cz 2011-09-30 17:10:55 UTC ---
> Hi,
> I can build Mozilla with GNU LD with resulting binary being about the same
> size
> as gold's so it seems to be all fine.
> Also the TLS problems are gone.
Actually
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
--- Comment #4 from hubicka at ucw dot cz 2011-09-30 16:31:05 UTC ---
Hi,
I can build Mozilla with GNU LD with resulting binary being about the same size
as gold's so it seems to be all fine.
Also the TLS problems are gone.
Thanks a lot!
Honza
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
Alan Modra changed:
What|Removed |Added
Attachment #5951|0 |1
is obsolete|
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
--- Comment #2 from Alan Modra 2011-09-29 11:12:59
UTC ---
Oh, and ignore the ld testsuite failures. The plugin tests need updating.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
--- Comment #1 from Alan Modra 2011-09-29 11:09:08
UTC ---
Created attachment 5951
--> http://sourceware.org/bugzilla/attachment.cgi?id=5951
proposed patch
Jan, can you test that this behaves correctly?
--
Configure bugmail: http://source
http://sourceware.org/bugzilla/show_bug.cgi?id=13229
Alan Modra changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at
22 matches
Mail list logo
