[Bug gold/15478] -no-as-needed required to avoid runtime symbol lookup error

http://sourceware.org/bugzilla/show_bug.cgi?id=15478 --- Comment #3 from Cary Coutant 2013-05-17 04:50:56 UTC --- > Yes that mode of operation does work but is unfortunately not an option for us > as we would like to combine libmylib.so with a different API-compatible > libmyplugin.so in each of

using --output-type dyn on an arm executable

I have had success modifying and running a executable after changing it to a shared object via the use of *elfedit --output-type dyn /bin/grep* for an i386. But, I get a segmentation fault whenever I do similar for executables on an arm based machine. Here is what I think is the minimal set of co

[Bug gold/15478] -no-as-needed required to avoid runtime symbol lookup error

http://sourceware.org/bugzilla/show_bug.cgi?id=15478 --- Comment #2 from Dave Cunningham 2013-05-17 01:46:41 UTC --- > I think this is intended behavior for gold. It's expected that each > library will have its own dependencies recorded so that we only record > direct dependencies in the dynamic

[Bug gold/15478] -no-as-needed required to avoid runtime symbol lookup error

http://sourceware.org/bugzilla/show_bug.cgi?id=15478 --- Comment #1 from Cary Coutant 2013-05-16 23:51:51 UTC --- > situation (see attached tar.bz2 to reproduce): > libmylib.so has unresolved symbols that are found in libmyplugin.so > myapp.c++ calls into libmylib.so > myapp.c++ is being compile

[Bug gold/15478] New: -no-as-needed required to avoid runtime symbol lookup error

http://sourceware.org/bugzilla/show_bug.cgi?id=15478 Bug #: 15478 Summary: -no-as-needed required to avoid runtime symbol lookup error Product: binutils Version: 2.22 Status: NEW Severity: normal Prio

[Bug ld/15477] New: gld does not understand mapfiles correctly

http://sourceware.org/bugzilla/show_bug.cgi?id=15477 Bug #: 15477 Summary: gld does not understand mapfiles correctly Product: binutils Version: 2.23 Status: NEW Severity: normal Priority: P2 Component: ld

[Bug binutils/15474] Octet/byte confusion in srec backend

http://sourceware.org/bugzilla/show_bug.cgi?id=15474 --- Comment #2 from Ralf Dreesen 2013-05-16 08:27:03 UTC --- I think that I might have located a bug in the srecord backend, which shows up, if multiple object files are linked for a 2 octets-per-byte architecture with the output format srecor

[Bug binutils/15474] Octet/byte confusion in srec backend

http://sourceware.org/bugzilla/show_bug.cgi?id=15474 --- Comment #1 from Ralf Dreesen 2013-05-16 08:15:32 UTC --- Created attachment 7027 --> http://sourceware.org/bugzilla/attachment.cgi?id=7027 Proposed patch -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email

[Bug binutils/15474] New: Octet/byte confusion in srec backend

http://sourceware.org/bugzilla/show_bug.cgi?id=15474 Bug #: 15474 Summary: Octet/byte confusion in srec backend Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutil