| Summary: | binutils 2.18 fails linking libopcodes.so due to missing symbols | ||
|---|---|---|---|
| Product: | binutils | Reporter: | Peter S. Mazinger <ps.m> |
| Component: | binutils | Assignee: | unassigned |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | bug-binutils, kirill, ldv |
| Priority: | P2 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Host: | i686-pc-linux-gnu | Target: | armv5te-softfloat-linux-uclibc |
| Build: | Last reconfirmed: | ||
| Attachments: | Add libiberty.a to the shared lib adds | ||
|
Description
Peter S. Mazinger
2008-10-02 19:47:04 UTC
Hi Peter, I have been trying to reproduce this problem but failing. Please could you show me a step-by-step guide as to how you made it happen ? Cheers Nick Subject: Re: binutils 2.18 fails linking libopcodes.so due to missing symbols I used a cross development script for this, it does something like mkdir build; cd build; LDFLAGS="-Wl,-z,defs" ../binutils-2.18/configure --target=armv5te-softfloat-linux-uclibc Peter -------- Original-Nachricht -------- > Datum: 3 Oct 2008 15:34:45 -0000 > Von: "nickc at redhat dot com" <sourceware-bugzilla@sourceware.org> > An: ps.m@gmx.net > Betreff: [Bug binutils/6937] binutils 2.18 fails linking libopcodes.so due to missing symbols > > ------- Additional Comments From nickc at redhat dot com 2008-10-03 15:34 > ------- > Hi Peter, > > I have been trying to reproduce this problem but failing. Please could > you > show me a step-by-step guide as to how you made it happen ? > > Cheers > Nick > > > -- > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |WAITING > > > http://sourceware.org/bugzilla/show_bug.cgi?id=6937 > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. Subject: Re: binutils 2.18 fails linking libopcodes.so
due to missing symbols
Hi Peter,
> mkdir build; cd build; LDFLAGS="-Wl,-z,defs" ../binutils-2.18/configure --target=armv5te-softfloat-linux-uclibc
That is exactly what I tried and yet it worked for me. (I assume that
you are using a bash like shell and a linux host, yes ?).
After the configure stage did you just run "make" or did you build the
opcodes library on its own ?
Cheers
Nick
I tried it with current cvs, the minimal configure that fails is: mkdir build; cd build; LDFLAGS="-Wl,-z,defs" ../src/configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=armv5te-unknown-linux-uclibc --enable shared --disable-werror ; make all disable-werror is only needed to avoid an earlier bailout on bfd/tekhex.c at line 434: wrong argument for memcpy, enable-shared is the magic, since else it won't try to compile shared libs on cross-build (shared would be enabled on a native build, if supported by target) Peter Created attachment 2985 [details]
Add libiberty.a to the shared lib adds
Hi Peter, Thanks for mentioning --enable-shared. That was the flag that I was missing when I tried the test the first time. I can now reproduce the problem and I have a patch for you to try out. If it works for you let me know and I will check it in. Cheers Nick patch is ok, consider to add ../libiberty/libiberty.a as a dependency too Hi Peter, I have checked the patch in with the dependency added as suggested. Cheers Nick opcodes/ChangeLog 2008-10-10 Nick Clifton <nickc@redhat.com> PR 6937 * configure.in (SHARED_LIBADD): Add libiberty.a. (SHARED_DEPENDENCIES): Add libiberty.a. This change provokes text relocations. I guess, PIC version of libiberty.a should be used. Subject: Re: binutils 2.18 fails linking libopcodes.so due to missing symbols Hi Kirill, > This change provokes text relocations. Sorry - please could you explain what that means and why it is undesirable ? > I guess, PIC version of libiberty.a should be used. A PIC version of libiberty is not normally generated even if configure with --enable-shared... Cheers Nick (In reply to comment #10) > Subject: Re: binutils 2.18 fails linking libopcodes.so > due to missing symbols > > Hi Kirill, > > > This change provokes text relocations. > > Sorry - please could you explain what that means and why it is undesirable ? http://people.redhat.com/drepper/textrelocs.html > > > I guess, PIC version of libiberty.a should be used. > > A PIC version of libiberty is not normally generated even if configure > with --enable-shared... Yep, you are right. :( Then I have no ideas how to fix it. (In reply to comment #10) > > I guess, PIC version of libiberty.a should be used. > > A PIC version of libiberty is not normally generated even if configure > with --enable-shared... This is not a problem: the PIC version should be used iff it is built. There is an appropriate configure check for PICFLAG in bfd/configure.in already. I think Nick's patch is wrong. :-( We don't ever build a shared libiberty, and libiberty.a usually contains non-pic objects. So linking libiberty.a against libopcodes.so will (depending on target) produce a libopcodes.so with text relocations. The way this used to work a very long time ago (binutils-2.8) was that libiberty/pic/*.o were pulled in directly when building libopcodes.so or the combined bfd and opcodes libbfd.so. Note that this provided the entirety of libiberty in libopcodes.so or libbfd.so, satisfying all of the binutils apps references to libiberty functions. I don't know why we lost this feature, or how much work it would take to fix. Subject: Re: binutils 2.18 fails linking libopcodes.so due to missing symbols > I think Nick's patch is wrong. :-( Doh! > We don't ever build a shared libiberty, Why not ? Wouldn't it be easy to solve this problem if we did build a shared libiberty ? (In reply to comment #14) > Subject: Re: binutils 2.18 fails linking libopcodes.so > due to missing symbols > > > I think Nick's patch is wrong. :-( > > Doh! > > > We don't ever build a shared libiberty, > > Why not ? Wouldn't it be easy to solve this problem if we did build a > shared libiberty ? > You may run into problems of different shared libiberty libraries from gcc and gdb/binutils. Hi Guys, Well - I do not know how to resolve this PR, but it seems obvious thatmy original patch was wrong, so I am going to revert it. Cheers Nick earlier there was a PIC version of libiberty.a built in a subdirectory pic/ if target supports it, maybe we could reenable it and use that to link, alternatively libiberty.a could be always built PIC (PICFLAGS=-fPIC|-fpic), although I think the second variant will get some objections... forgot to mention, if libiberty.a is not PIC, it will be buggy for cygwin too and if it is installed into any target (the binutils provided libiberty.a is usually installed on most distros I saw), it is not allowed to be linked into any shared library or PIE executable, since it will produce text relocations as well. Some apps providing only archive without shared library produce alternatively a lib*_pic.a file, meaning that all objects that went into it are -fPIC|-fpic compiled. Peter This bug has been partly fixed with my 2009-01-16 opcodes commit, in that libopcodes will now contain the pic libiberty functions if they are available. Using uclibc will still result in -zdefs errors due to needing libm, but that is convered by http://sourceware.org/bugzilla/show_bug.cgi?id=6768, so closing and marking this a dup. *** This bug has been marked as a duplicate of 6768 *** |