[Bug ld/27441] Small inconsistency in between gold and bfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27441 Alan Modra changed: What|Removed |Added Target Milestone|--- |2.37 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #19 from Alan Modra --- Fixed on both mainline and 2.36 branch. (In reply to Fangrui Song from comment #16) > * or it has a non-weak definition resolving a reference No, the correct formulation is: "or it has a definition resolving a non-weak reference". I was confused about this too. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27548] New: Mr-yycis()
https://sourceware.org/bugzilla/show_bug.cgi?id=27548 Bug ID: 27548 Summary: Mr-yycis() Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: karolin at 6681788 dot com Target Milestone: --- Created attachment 13295 --> https://sourceware.org/bugzilla/attachment.cgi?id=13295=edit Web elu lemah -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26706] pad strings in .dynstr
https://sourceware.org/bugzilla/show_bug.cgi?id=26706 --- Comment #3 from Ben Woodard --- Do you think it is worth me chiming in saying ‘what he said’? You captured my intent perfectly. I guess I’m kind of hung up on “assume” in “what I assume Ben, the original reporter, is after” or is that just a polite assume. -ben > On Mar 7, 2021, at 9:04 AM, mark at klomp dot org > wrote: > > https://sourceware.org/bugzilla/show_bug.cgi?id=26706 > > --- Comment #2 from Mark Wielaard --- > (In reply to Fangrui Song from comment #1) >> You can additionally link an object file with an artificial long symbol >> name. Since that symbol is not used, you can change its .dynstr > > I think that is really fragile. The way Solaris does this (what I assume Ben, > the original reporter, is after) is by introducing a new dynamic section entry > that provides the padding that is still available. That way tools know where > and how much space they can use for dynamic strings. > > We could introduce DT_GNU_STRPAD and suggest that linkers initially set it to > 256 (and add that to DT_STRSZ) to make such manipulations easy and robust. Any > tool manipulating the .dynstr segement can then use (and update) that when > adding a new string. > > See also: http://www.linker-aliens.org/blogs/ali/entry/changing_elf_runpaths/ > > -- > You are receiving this mail because: > You reported the bug. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27302] windres: -I of preprocessor command line should be quoted
https://sourceware.org/bugzilla/show_bug.cgi?id=27302 katayama.hirofumi.mz at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |NOTABUG -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27302] windres: -I of preprocessor command line should be quoted
https://sourceware.org/bugzilla/show_bug.cgi?id=27302 --- Comment #4 from katayama.hirofumi.mz at gmail dot com --- Execuse me, that was "--preprocessor=(pathname with space)". -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27302] windres: -I of preprocessor command line should be quoted
https://sourceware.org/bugzilla/show_bug.cgi?id=27302 --- Comment #3 from katayama.hirofumi.mz at gmail dot com --- Created attachment 13294 --> https://sourceware.org/bugzilla/attachment.cgi?id=13294=edit Screenshot that shows working It works. However, --preprocessor="(pathname with space)" won't work. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27546] New: undefined reference error fix-hint suggestion
https://sourceware.org/bugzilla/show_bug.cgi?id=27546 Bug ID: 27546 Summary: undefined reference error fix-hint suggestion Product: binutils Version: 2.26 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: srbvsr at gmail dot com Target Milestone: --- I was trying to build a binary, invoking a C-function (fileA.c) within a C++ function (fileB.cpp). The build ended with a linker error: undefined reference error on the C-function. Going over the objdump i was able to narrow its due to C++ name mangling. Examaple symbol output: *UND* _Z14ns_test_customv g F .text 01d9 ns_test_custom The enhancement idea here is to provide a suggestion to the end-user a possibility of C++ name mangling scanning the symbol table. There are similar user-suggestions available in the gnu compilers and hope the same can be adopted in the linker. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/27441] Small inconsistency in between gold and bfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27441 Cary Coutant changed: What|Removed |Added CC||ccoutant at gmail dot com --- Comment #18 from Cary Coutant --- > > 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-needed a.so => needed) > > * or it has a non-weak definition resolving a reference from a live section > > (not discarded by --gc-sections) > > > > I think both LLD and gold's rules are like this. > > Then they both have the same bug (in the second item of your list). As Alan > explains, as-needed behaviour intends to reflect behaviour of static archives > (where that applies; here any difference in behaviour doesn't seem useful). > > The only thing about weak definitions is that there may be validly multiple > ones > without error (the first one or the single non-weak definition wins). This contradicts the ld manual: --as-needed --no-as-needed This option affects ELF DT_NEEDED tags for dynamic libraries mentioned on the command line after the --as-needed option. Normally the linker will add a DT_NEEDED tag for each dynamic library mentioned on the command line, regardless of whether the library is actually needed or not. --as-needed causes a DT_NEEDED tag to only be emitted for a library that at that point in the link satisfies a non-weak undefined symbol reference from a regular object file or, if the library is not found in the DT_NEEDED lists of other needed libraries, a non-weak undefined symbol reference from another needed dynamic library. Object files or libraries appearing on the command line after the library in question do not affect whether the library is seen as needed. This is similar to the rules for extraction of object files from archives. --no-as-needed restores the default behaviour. Note where it says "that at that point in the link satisfies a *non-weak* undefined symbol reference from a regular object file or, if the library is not found in the DT_NEEDED lists of other needed libraries, a *non-weak* undefined symbol reference from another needed dynamic library." (emphasis added) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27297] libctf.a malformed, build fails on x86_64-apple-darwin18.7.0
https://sourceware.org/bugzilla/show_bug.cgi?id=27297
Nick Alcock changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED|RESOLVED
--- Comment #5 from Nick Alcock ---
Fixed (some time back, but couldn't update the bug) in master in a series in
which the most important commits are these:
(not sure if it is worthy of going back into 2.36. The commits it relies on are
quite big and invasive.)
commit 95148614026da7353721411dd020d024667e3482
Author: Nick Alcock
Date: Wed Feb 3 18:42:06 2021 +
bfd, opcodes, libctf: support --with-included-gettext
Right now, these libraries hardwire -L../intl -lintl on a few fixed
platforms, which works fine on those platforms but on other platforms
leads to shared libraries that lack libintl_* symbols when configured
--with-included-gettext, and/or static libraries that contain libintl as
*another* static library. If we instead use the LIBINTL variable
defined in ../intl/config.intl, this gives us the right thing on all
three classes of platform (gettext in libc, gettext in system libintl,
gettext in ../intl/libintl.a).. This also means we can rip out some
Darwin-specific machinery from configure.ac and also simplify the Cygwin
side.
This also means that the libctf testsuite (and other places that include
libbfd, libopcodes or libctf) don't need to grow libintl dependencies
just on account of those libraries (though they still need such
dependencies if they themselves use gettext machinery).
bfd/ChangeLog
2021-02-03 Nick Alcock
* configure.ac (SHARED_LIBADD): Remove explicit -lintl population
in
favour of LIBINTL.
* configure: Regenerated.
libctf/ChangeLog
2021-02-02 Nick Alcock
* configure.ac (CTF_LIBADD): Remove explicit -lintl population in
favour of LIBINTL.
* Makefile.am (libctf_nobfd_la_LIBADD): No longer explicitly
include $(LIBINTL).
(check-DEJAGNU): Pass down to tests as well.
* configure: Regenerated.
* Makefile.in: Likewise.
opcodes/ChangeLog
2021-02-04 Nick Alcock
* configure.ac (SHARED_LIBADD): Remove explicit -lintl population
in
favour of LIBINTL.
* configure: Regenerated.
commit aee224d6434c08a1404a4357cf0a664a4c2f02eb
Author: Nick Alcock
Date: Thu Feb 4 16:58:35 2021 +
intl: turn LIBINTL into -L / -l form
This variable currently refers directly, not to a .la file, but to an .a
file. This produces wrong results when building into a library on some
platforms: so convert it to the general form "-L${top_builddir}../intl
-lintl ..." ... so that both libtool and non-libtool builds will always
do the right thing for both static and shared links.
intl/ChangeLog
2021-02-04 Nick Alcock
* configure.ac (LIBINTL): Transform into -L/-lintl form.
* configure: Regenerate.
commit 53d4244ec0ac70438d75abf3326cb3392bb9c828
Author: Nick Alcock
Date: Tue Feb 2 15:39:26 2021 +
intl: always picify
libintl is included in several shared libraries (at least
libinproctrace.so and libctf.so): unconditionally picify with code
borrowed from libiberty configure. (It's not performance-critical, so
don't bother making separate PIC and non-PIC libraries like libiberty
does.)
intl/ChangeLog
2021-02-02 Nick Alcock
* aclocal.m4: include picflag.m4.
* configure.ac (PICFLAG): Add and substitute.
* Makefile.in (PICFLAG): New.
(COMPILE): Use it.
* configure: Regenerate.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/27441] Small inconsistency in between gold and bfd
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 :) > > > > Huh, I can hardly believe I was making such a completely wrong assumption. > > How stupid is that? I just checked elflink.c plus archive.c code and ran a > > test to properly convince myself I was wrong. Yes, a weak definition does > > indeed cause an archive element to be extracted to satisfy a strong > > undefined reference. > > > > Testing the binding of the definition was just plain wrong. > > 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-needed a.so => needed) > * or it has a non-weak definition resolving a reference from a live section > (not discarded by --gc-sections) > > I think both LLD and gold's rules are like this. Then they both have the same bug (in the second item of your list). As Alan explains, as-needed behaviour intends to reflect behaviour of static archives (where that applies; here any difference in behaviour doesn't seem useful). The only thing about weak definitions is that there may be validly multiple ones without error (the first one or the single non-weak definition wins). -- You are receiving this mail because: You are on the CC list for the bug.
