https://sourceware.org/bugzilla/show_bug.cgi?id=32644
Michael Matz changed:
What|Removed |Added
CC||matz at suse dot de
--- Comment #3
https://sourceware.org/bugzilla/show_bug.cgi?id=32643
Michael Matz changed:
What|Removed |Added
CC||matz at suse dot de
--- Comment #3
https://sourceware.org/bugzilla/show_bug.cgi?id=32584
Michael Matz changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org |matz at suse dot de
Ever
https://sourceware.org/bugzilla/show_bug.cgi?id=32260
--- Comment #9 from Michael Matz ---
So, I have two patches for you, see above. It would be nice to know that
they work independendly, so if you could first test the first patch in
isolation,
so that we can know that the error handling now wo
https://sourceware.org/bugzilla/show_bug.cgi?id=32260
--- Comment #8 from Michael Matz ---
Created attachment 15747
--> https://sourceware.org/bugzilla/attachment.cgi?id=15747&action=edit
better estimates
Second patch for smaller estimates
--
You are receiving this mail because:
You are on t
https://sourceware.org/bugzilla/show_bug.cgi?id=32260
--- Comment #7 from Michael Matz ---
Created attachment 15746
--> https://sourceware.org/bugzilla/attachment.cgi?id=15746&action=edit
patch for improving error handling
First patch that improves error handling.
--
You are receiving this m
https://sourceware.org/bugzilla/show_bug.cgi?id=32260
--- Comment #6 from Michael Matz ---
Okay, so the errors need to be dealt with more reasonably here, it's really an
extreme example:
XXX bfdtab->count=1751 table->nbuckets=524288
XXX sec->size=2872400096
XXX added=1436200049
So the input sec
https://sourceware.org/bugzilla/show_bug.cgi?id=32260
--- Comment #1 from Michael Matz ---
Welcome back big testcase :-)
> XXX bfdtab->count=1751 table->nbuckets=524288
> XXX bfdtab->count=1752 table->nbuckets=0
So, something between those two wants to reallocate the hash table to have
more buc
https://sourceware.org/bugzilla/show_bug.cgi?id=32073
--- Comment #20 from Michael Matz ---
(In reply to Jan Beulich from comment #19)
> (In reply to Michael Matz from comment #14)
> > The scrubber removes whitespace between tokens of different classes, but
> > retains
> > whitespace between toke
https://sourceware.org/bugzilla/show_bug.cgi?id=32073
--- Comment #15 from Michael Matz ---
(In reply to Michael Matz from comment #14)
> invoke 1 2
> invoke 1 + 2 3
>
> (support invoke is a two-arg macro,
fat fingering on my part doesn't help :-/ 'suppose invoke is a ...' was what I
meant
https://sourceware.org/bugzilla/show_bug.cgi?id=32073
--- Comment #14 from Michael Matz ---
(In reply to Maciej W. Rozycki from comment #12)
> (In reply to Jan Beulich from comment #10)
> > In which case it would also be impossible to fix anomalies there. In turn
> > meaning that hardly any bug i
https://sourceware.org/bugzilla/show_bug.cgi?id=32073
--- Comment #9 from Michael Matz ---
(In reply to Jan Beulich from comment #8)
>
> I've looked into what the options are of fixing this particular issue.
> Dealing with the one question of "should blanks be skipped here" quickly
> turns into
https://sourceware.org/bugzilla/show_bug.cgi?id=32073
Michael Matz changed:
What|Removed |Added
CC||matz at suse dot de
--- Comment #7
https://sourceware.org/bugzilla/show_bug.cgi?id=31009
Michael Matz changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://sourceware.org/bugzilla/show_bug.cgi?id=31009
--- Comment #10 from Michael Matz ---
(In reply to Jonny Weir from comment #7)
> I made the following change:
Thanks!
> XXX resize 1: count=1598 added=1086327410 newnb=1048576
Gah, yeah. So, one of the input string sections (most likely on
https://sourceware.org/bugzilla/show_bug.cgi?id=31009
--- Comment #6 from Michael Matz ---
(In reply to Jonny Weir from comment #5)
> Ignore that last message, it is misleading, this is a more accurate
> representation of what is happening with the values:
Ah, yes. I was suspecting already that
https://sourceware.org/bugzilla/show_bug.cgi?id=31009
--- Comment #2 from Michael Matz ---
Another possible way forward: if you add '-save-temps' to the link/compile
command then the LTO phase will leave around the $foobar.ltransXXX.ltrans.o
files and the *.debug.o files, that are ultimately inpu
https://sourceware.org/bugzilla/show_bug.cgi?id=31009
Michael Matz changed:
What|Removed |Added
CC||matz at suse dot de
--
You are
https://sourceware.org/bugzilla/show_bug.cgi?id=30590
Michael Matz changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=30590
--- Comment #3 from Michael Matz ---
When you move the libs into a subdir (and accordingly don't have them in the
current dir anymore!) then your "lib1.a(*)" should have given you an error,
with old ld, with new ld and with patch:
% ls -l lib
https://sourceware.org/bugzilla/show_bug.cgi?id=30590
Michael Matz changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org |matz at suse dot de
Last
https://sourceware.org/bugzilla/show_bug.cgi?id=30590
Michael Matz changed:
What|Removed |Added
CC||matz at suse dot de
--- Comment #1
https://sourceware.org/bugzilla/show_bug.cgi?id=30499
--- Comment #9 from Michael Matz ---
(In reply to Nick Clifton from comment #7)
> Created attachment 14923 [details]
> Proposed patch
>
> Hi Michael,
>
>OK, what do you think of this patch ? It would change the wording to:
>
> ld: warn
https://sourceware.org/bugzilla/show_bug.cgi?id=30499
--- Comment #4 from Michael Matz ---
(In reply to Nick Clifton from comment #3)
> (In reply to Michael Matz from comment #2)
> > Hmm, on reflection this proposed message might not actually be correct.
> > Generally one can't just increase the
https://sourceware.org/bugzilla/show_bug.cgi?id=30499
--- Comment #2 from Michael Matz ---
Hmm, on reflection this proposed message might not actually be correct.
Generally one can't just increase the alignment of random data symbols like
here: they might be part of a larger object with known rel
https://sourceware.org/bugzilla/show_bug.cgi?id=30499
--- Comment #1 from Michael Matz ---
Patch would be trivial:
--- a/bfd/elflink.c
+++ b/bfd/elflink.c
@@ -5339,7 +5339,7 @@ elf_link_add_object_symbols (bfd *abfd, struct
bfd_link_info *info)
_bfd_error_handler
ty: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: matz at suse dot de
Target Milestone: ---
A customer of a customer of ours is requesting that the warning about
mismatching symbol alignments be reworded. Given this:
% c
https://sourceware.org/bugzilla/show_bug.cgi?id=30437
Michael Matz changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=30437
--- Comment #2 from Michael Matz ---
ld.gold gets the testcase correct:
% ld.gold -pie rela.o
% objdump -sRj .data a.out
a.out: file format elf64-littleaarch64
DYNAMIC RELOCATION RECORDS
OFFSET TYPE VALUE
000
https://sourceware.org/bugzilla/show_bug.cgi?id=30437
Michael Matz changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org |matz at suse dot de
erity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: matz at suse dot de
Target Milestone: ---
The aarch64 psABI prescribes that all RELA relocs are to be idempotent.
Amongst
other things that means they have to ignor
https://sourceware.org/bugzilla/show_bug.cgi?id=30358
--- Comment #16 from Michael Matz ---
Yes, the hacky patch is fine for you to use, it won't introduce further
problems
(knock on wood! :) ).
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=30358
Michael Matz changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://sourceware.org/bugzilla/show_bug.cgi?id=30367
Michael Matz changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://sourceware.org/bugzilla/show_bug.cgi?id=30358
--- Comment #11 from Michael Matz ---
The old (insertion-sort) code only added something to the output section list
if the considered section wasn't already either discarded or linked (by being
part of a group for instance). That is done by l
https://sourceware.org/bugzilla/show_bug.cgi?id=30358
Michael Matz changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org |matz at suse dot de
https://sourceware.org/bugzilla/show_bug.cgi?id=30367
--- Comment #2 from Michael Matz ---
No need to dig into trying with an empty ROM. It's easily reproducable with
many input files each being used in a wildstatement of a linker script. It's a
quadraticness problem. Proposed fix at
https:
|1
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at sourceware dot org |matz at suse dot de
--- Comment #1 from Michael Matz ---
So the specific feature heavily used in the linker script seems to be section
descriptions based on
https://sourceware.org/bugzilla/show_bug.cgi?id=30120
--- Comment #5 from Michael Matz ---
(In reply to Michael Matz from comment #4)
> commit 25a0d393c72 (with a little addition to a testcase to check for at
> least this problem)
FWIW, I've also checked all patterns touched by the initial patch
https://sourceware.org/bugzilla/show_bug.cgi?id=30120
Michael Matz changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://sourceware.org/bugzilla/show_bug.cgi?id=30120
Michael Matz changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org |jbeulich at suse dot com
--
Yo
https://sourceware.org/bugzilla/show_bug.cgi?id=30120
--- Comment #2 from Michael Matz ---
Came in with bd7828084 "x86: use ModR/M for FPU insns with operands".
The proper Reg field of ModRM for the popping variant of fucom is '5' not '4'.
So this:
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-
https://sourceware.org/bugzilla/show_bug.cgi?id=30120
--- Comment #1 from Michael Matz ---
The problem exists in current master. 2.39 and 2.40 seem to be okay.
--
You are receiving this mail because:
You are on the CC list for the bug.
Assignee: unassigned at sourceware dot org
Reporter: matz at suse dot de
Target Milestone: ---
% cat asm.s
fucomp %st(1)
% ./gas/as-new asm.s && objdump -d a.out
...
<.text>:
0: dd e1 fucom %st(1)
It should be 'dd e9fu
https://sourceware.org/bugzilla/show_bug.cgi?id=30079
Michael Matz changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=30079
--- Comment #3 from Michael Matz ---
The guards are supposed to be moved only, not removed:
if (!wild->filenames_sorted
&& (sec == NULL || sec->spec.sorted == none
|| sec->spec.sorted == by_none))
{
return wild->ri
||matz at suse dot de
Status|RESOLVED|REOPENED
--- Comment #3 from Michael Matz ---
This was wrong advise. The shared _modules_ (the collectors, those which are
loaded by dlopen) should indeed be placed in $(pkglibdir). But the shared
_library_
https://sourceware.org/bugzilla/show_bug.cgi?id=30043
--- Comment #3 from Michael Matz ---
Proper shared libraries (those which programs link against via DT_NEEDED) have
to be placed in directories in which the dynamic linker searches for them. You
can play games with DT_RUNPATH of course but th
https://sourceware.org/bugzilla/show_bug.cgi?id=29849
--- Comment #3 from Michael Matz ---
Thanks Nick for cleaning up after me. FWIW I was just testing an equivalent
patch on most targets without regressions, so it's good to go.
--
You are receiving this mail because:
You are on the CC list f
https://sourceware.org/bugzilla/show_bug.cgi?id=19962
--- Comment #6 from Michael Matz ---
(And just FWIW: aarch64 binutils 2.36 and 2.37 don't have the problem either).
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=19962
Michael Matz changed:
What|Removed |Added
CC||matz at suse dot de
https://sourceware.org/bugzilla/show_bug.cgi?id=28021
Michael Matz changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Assignee: unassigned at sourceware dot org
Reporter: matz at suse dot de
Target Milestone: ---
This is related to the fix for PR22756, which turns out to be incomplete.
We have seen the problem with GCC11 and it needs LTO, which makes this a bit
involved to reproduce. See
https://sourceware.org/bugzilla/show_bug.cgi?id=26018
--- Comment #9 from Michael Matz ---
So, this commit is at fault, but it's already reported as PR26928 and that is a
duplicate of PR26407. I was even involved in analyzing it there but obviously
forgot :-/
Then let me at least note that I di
https://sourceware.org/bugzilla/show_bug.cgi?id=26018
Michael Matz changed:
What|Removed |Added
CC||matz at suse dot de
--- Comment #8
https://sourceware.org/bugzilla/show_bug.cgi?id=27441
--- Comment #20 from Michael Matz ---
(In reply to Cary Coutant from comment #18)
> > > My understanding of when a shared object is needed:
> > >
> > > * it is linked at least once in --no-as-needed mode (i.e. --as-needed a.so
> > > --no-as-n
https://sourceware.org/bugzilla/show_bug.cgi?id=27441
--- Comment #17 from Michael Matz ---
(In reply to Fangrui Song from comment #16)
> (In reply to Alan Modra from comment #12)
> > (In reply to Michael Matz from comment #11)
> > > Yes, I thought so as well, until I read ELF.txt again :)
> >
>
https://sourceware.org/bugzilla/show_bug.cgi?id=27441
--- Comment #11 from Michael Matz ---
(In reply to Alan Modra from comment #8)
> (In reply to Michael Matz from comment #3)
> > % gcc -fPIC -Wl,--as-needed -fno-lto -shared -o good.so bad4.c -L. -l2 -l1
> > % readelf-dW good.so | grep lib
> >
https://sourceware.org/bugzilla/show_bug.cgi?id=27441
--- Comment #6 from Michael Matz ---
Probably just one more corner case (the last one!) ;-)
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=27441
--- Comment #4 from Michael Matz ---
(I've now verified that it doesn't happen with older binutils (2.26 :) ) but
does with 2.36, with otherwise same toolchain (some random gcc-9 compiler), so
it's not any gcc component)
--
You are receiving
https://sourceware.org/bugzilla/show_bug.cgi?id=27441
Michael Matz changed:
What|Removed |Added
Assignee|ccoutant at gmail dot com |unassigned at
sourceware dot or
https://sourceware.org/bugzilla/show_bug.cgi?id=27441
Michael Matz changed:
What|Removed |Added
CC||matz at suse dot de
--- Comment #2
https://sourceware.org/bugzilla/show_bug.cgi?id=27377
Michael Matz changed:
What|Removed |Added
CC||matz at suse dot de
--- Comment #2
https://sourceware.org/bugzilla/show_bug.cgi?id=27311
--- Comment #5 from Michael Matz ---
(In reply to Michael Matz from comment #4)
> (In reply to H.J. Lu from comment #2)
> > Please try users/hjl/pr26530/master branch:
> >
> > https://gitlab.com/x86-binutils/binutils-gdb/-/commits/users/hjl/p
https://sourceware.org/bugzilla/show_bug.cgi?id=27311
--- Comment #4 from Michael Matz ---
(In reply to H.J. Lu from comment #2)
> Please try users/hjl/pr26530/master branch:
>
> https://gitlab.com/x86-binutils/binutils-gdb/-/commits/users/hjl/pr26530/
> master
Yes, that patch series works, but
https://sourceware.org/bugzilla/show_bug.cgi?id=27311
--- Comment #3 from Michael Matz ---
FWIW, it's important that the symbol in question is defined in an indirect
shared lib with a symversion, and defined in an input object file itself. I.e.
this is more self-contained:
% cat lib1.c
void inl
https://sourceware.org/bugzilla/show_bug.cgi?id=27016
--- Comment #1 from Michael Matz ---
This also happen in 2.35 of course.
--
You are receiving this mail because:
You are on the CC list for the bug.
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: matz at suse dot de
Target Milestone: ---
Since the fix for PR ld/25749 and PR ld/25754, i.e. commit 382aae0632 ld
generates incorrect code in the following
https://sourceware.org/bugzilla/show_bug.cgi?id=26936
--- Comment #23 from Michael Matz ---
(In reply to Michael Matz from comment #22)
> (In reply to Fangrui Song from comment #20)
> > (I thought that .gnu.linkonce was deprecated almost 20 years ago and we
> > should phase out linkonce instead o
https://sourceware.org/bugzilla/show_bug.cgi?id=26936
--- Comment #22 from Michael Matz ---
(In reply to Fangrui Song from comment #20)
> (I thought that .gnu.linkonce was deprecated almost 20 years ago and we
> should phase out linkonce instead of adding more compatibility code...)
Deprecation
https://sourceware.org/bugzilla/show_bug.cgi?id=26936
--- Comment #17 from Michael Matz ---
(In reply to H.J. Lu from comment #15)
> My /lib/crti.o has
>
> COMDAT group section [1] `.group' [__x86.get_pc_thunk.bx] contains 1
> sections:
>[Index]Name
>[8] .text.__x86.get_pc_
https://sourceware.org/bugzilla/show_bug.cgi?id=26936
Michael Matz changed:
What|Removed |Added
CC||matz at suse dot de
--- Comment #14
https://sourceware.org/bugzilla/show_bug.cgi?id=26551
--- Comment #9 from Michael Matz ---
I think ld.bfd is completely fine to not export exe symbols only referenced by
mentioned but not otherwise needed libraries. It's follows from traditional
behaviour that executables don't export any symbol
https://sourceware.org/bugzilla/show_bug.cgi?id=26530
--- Comment #1 from Michael Matz ---
FWIW, I think the gold behaviour is the correct one. The order of libraries
on the cmdline is significant, and libfoo.so does fulfill the symbol request,
so the object from libtest.a shouldn't be considere
https://sourceware.org/bugzilla/show_bug.cgi?id=26407
Michael Matz changed:
What|Removed |Added
CC||matz at suse dot de
--- Comment #8
https://sourceware.org/bugzilla/show_bug.cgi?id=25708
--- Comment #10 from Michael Matz ---
(In reply to H.J. Lu from comment #9)
> >
> > Is it really a good idea to change the output format of basic tools that
> > might be
> > used in machine processing context? (And I note there doesn't seem
https://sourceware.org/bugzilla/show_bug.cgi?id=25708
Michael Matz changed:
What|Removed |Added
CC||matz at suse dot de
--- Comment #8
https://sourceware.org/bugzilla/show_bug.cgi?id=25593
Michael Matz changed:
What|Removed |Added
CC||matz at suse dot de
--- Comment #1
https://sourceware.org/bugzilla/show_bug.cgi?id=25210
--- Comment #1 from Michael Matz ---
FWIW, master still has the same problem and the same patch helps.
--
You are receiving this mail because:
You are on the CC list for the bug.
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: matz at suse dot de
Target Milestone: ---
This came up in our distro build when updating to binutils 2.33 (2.32 was still
fine) which then fails building GCC. But it
https://sourceware.org/bugzilla/show_bug.cgi?id=23008
Michael Matz changed:
What|Removed |Added
CC||matz at suse dot de
--- Comment #11
https://sourceware.org/bugzilla/show_bug.cgi?id=22868
--- Comment #4 from Michael Matz ---
FWIW, I'm using this patch in our binutils package:
--
Fixes two testsuite fails in the gold plugin tests of LLVM.
Aka binutils/PR22868
Index: binutils-2.30/gold
https://sourceware.org/bugzilla/show_bug.cgi?id=22981
Michael Matz changed:
What|Removed |Added
CC||matz at suse dot de
--
You are
https://sourceware.org/bugzilla/show_bug.cgi?id=22868
Michael Matz changed:
What|Removed |Added
CC||matz at suse dot de
--- Comment #1
https://sourceware.org/bugzilla/show_bug.cgi?id=21964
--- Comment #11 from Michael Matz ---
So I think in addition to what my patch did the following also needs solving:
* if a __start symbol is supposed to be created, then it should be created!
(i.e. not merely use some random other symbol com
https://sourceware.org/bugzilla/show_bug.cgi?id=21964
--- Comment #10 from Michael Matz ---
Created attachment 10356
--> https://sourceware.org/bugzilla/attachment.cgi?id=10356&action=edit
another testcase showing unpatched binutils broken
Like with this new testcase. The difference
is that w
https://sourceware.org/bugzilla/show_bug.cgi?id=21964
--- Comment #9 from Michael Matz ---
(In reply to Michael Matz from comment #8)
> Looking at this, that ld-gc/pr20002 doesn't fail without the patch from
> comment #4 is a nice thing, but I think it succeeds for the wrong reasons.
The testca
https://sourceware.org/bugzilla/show_bug.cgi?id=21964
--- Comment #8 from Michael Matz ---
You mean it shows an additional issue, I wasn't saying my patch is perfect,
merely that it fixes my reported problem. I think it's the same reason of why
the testcase ld-gc/pr20022 fails with the proposed
https://sourceware.org/bugzilla/show_bug.cgi?id=21964
--- Comment #6 from Michael Matz ---
Created attachment 10354
--> https://sourceware.org/bugzilla/attachment.cgi?id=10354&action=edit
tarball with testcase
Here is one. Unlike libqb it's not using dl_iterate_phdr and then dlopen with
the k
https://sourceware.org/bugzilla/show_bug.cgi?id=21964
--- Comment #4 from Michael Matz ---
Created attachment 10353
--> https://sourceware.org/bugzilla/attachment.cgi?id=10353&action=edit
Tentative patch
Well, the problem is quite obvious. Just compile this:
% cat t.c
#include
extern void *
https://sourceware.org/bugzilla/show_bug.cgi?id=21964
--- Comment #2 from Michael Matz ---
(In reply to H.J. Lu from comment #1)
> What should happen when there is _verbose section in more than one shared
> object?
As I said, the code in question uses dlsym, so nothing interesting happens,
multi
https://sourceware.org/bugzilla/show_bug.cgi?id=21964
Michael Matz changed:
What|Removed |Added
CC||amodra at gmail dot com,
t: ld
Assignee: unassigned at sourceware dot org
Reporter: matz at suse dot de
Target Milestone: ---
Commit cbd0eecf reworked the provision of __start_ and __stop_ symbols for
sections with C-representable names (e.g. to always provide them, not only
for orphaned sections). Am
https://sourceware.org/bugzilla/show_bug.cgi?id=21884
--- Comment #29 from Michael Matz ---
And commit b7a18930 from Nick fixed it on master for a x86_64 hosted binutils
(I'm qualifying this because I haven't checked a i586 hosted binutils yet).
So at the very minimum this patch needs to be on t
||matz at suse dot de
Resolution|FIXED |---
--- Comment #28 from Michael Matz ---
This still reproduces for me, on i586 and on x86_64. I don't need to build
binutils in any special way, on my host x86_64, with gcc 4.7:
% git status
# On b
https://sourceware.org/bugzilla/show_bug.cgi?id=17592
--- Comment #5 from Michael Matz ---
(In reply to H.J. Lu from comment #4)
> When there is a large readonly section, it makes no differences between
>
> text, plt, readonly, got
>
> and
>
> text, readonly, plt, got
>
> since text needs to
https://sourceware.org/bugzilla/show_bug.cgi?id=17592
--- Comment #3 from Michael Matz ---
(In reply to H.J. Lu from comment #2)
> It is an interesting idea.
Yeah, that's how I tested the large model back in the days when I implemented
some of it. Never got around to actually change the PLT lay
https://sourceware.org/bugzilla/show_bug.cgi?id=17592
Michael Matz changed:
What|Removed |Added
CC||matz at suse dot de
--- Comment #1
http://sourceware.org/bugzilla/show_bug.cgi?id=15167
Bug #: 15167
Summary: ld merges gnu_unique def and normal ref into normal
symbol
Product: binutils
Version: 2.24 (HEAD)
Status: NEW
Severity: normal
http://sourceware.org/bugzilla/show_bug.cgi?id=14915
--- Comment #3 from Michael Matz 2012-12-04 14:12:29 UTC
---
(In reply to comment #2)
>
> gcc -o libt2.so -shared -Wl,--copy-dt-needed-entries -L. -lt1 -v
/usr/lib64/gcc/x86_64-suse-linux/4.5/collect2 --build-id --eh-frame-hdr -m
elf_x86_64
1 - 100 of 114 matches
Mail list logo
