Re: Can't run "install-strip" in binutils 2.18 ... ?
Hi Paul, Is there another/better way to do this? Not really, sorry. :-( I wanted to have the binutils tools stripped when they are installed. Typically for autoconfiscated environments I run "make install-strip" to do this. For binutils if I try this I get: make: *** No rule to make target `install-strip'. Stop. > It looks like the top-level makefile in binutils doesn't grok the install-strip target. Correct. If you are really miffed by this, please file a bug report at http://sourceware.org/bugzilla/. The top level binutils makefile is shared by the gcc and gdb projects, so any changes to it will have to be acceptable to them as well. However if I look at the individual targets like the binutils subdirectory, they do have install-strip. True. I am hoping that this is sufficient for your purposes. On the gripping hand, though, I'm trying to cross-compile binutils and it doesn't work to cd directly to binutils-2.18/binutils and run "make install-strip" then it tries to use the "strip" command (which fails) instead of the cross-strip program, because the sub-makefiles expect the cross-tools to be provided as command-line overrides on the make invocation. When I tried this on my machine it worked without any problems. I am not sure exactly what you mean when you complain that it uses the "strip" command instead of the cross-strip program, since surely it is the host's strip command that should be used. For example this is what happens when I run "make install-strip" in the binutils build directory of an arm-eabi toolchain. [Edited to remove superfluous stuff]: make INSTALL_PROGRAM="/bin/sh /work/sources/binutils/current/install-sh -c -s" \ install_sh_PROGRAM="/bin/sh /work/sources/binutils/current/install-sh -c -s" \ INSTALL_STRIP_FLAG=-s `test -z 'strip' || \ echo "INSTALL_PROGRAM_ENV=STRIPPROG='strip'"` install [...] STRIPPROG='strip' /bin/sh ./libtool --mode=install /bin/sh /work/sources/binutils/current/install-sh -c -s 'size' '/dev/shm/del-me/install/bin/arm-eabi-size' libtool: install: /bin/sh /work/sources/binutils/current/install-sh -c -s size /dev/shm/del-me/install/bin/arm-eabi-size [...] And libtool then installs a stripped binary into the install directory: % file ../install/bin/arm-eabi-readelf ../install/bin/arm-eabi-readelf: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped According to a comment in the binutils/configure file you can also use the environment variable STRIP to override the strip program used when installing stripped binaries. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/6937] binutils 2.18 fails linking libopcodes.so due to missing symbols
-- What|Removed |Added CC||kirill at shutemov dot name http://sourceware.org/bugzilla/show_bug.cgi?id=6937 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/6937] binutils 2.18 fails linking libopcodes.so due to missing symbols
--- Additional Comments From kirill at shutemov dot name 2008-10-13 15:06 --- This change provokes text relocations. I guess, PIC version of libiberty.a should be used. -- http://sourceware.org/bugzilla/show_bug.cgi?id=6937 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Can't run "install-strip" in binutils 2.18 ... ?
On Mon, 2008-10-13 at 10:31 +0100, Nick Clifton wrote: > > It looks like the top-level makefile in binutils doesn't grok the > > install-strip target. > > Correct. If you are really miffed by this, please file a bug report at > http://sourceware.org/bugzilla/. OK thanks! > > However if I look at the individual targets like > > the binutils subdirectory, they do have install-strip. > > True. I am hoping that this is sufficient for your purposes. See below. So far I've had to use "make install" then run the strip operation by hand afterwards. > > On the gripping hand, though, I'm trying to cross-compile binutils and > > it doesn't work to cd directly to binutils-2.18/binutils and run "make > > install-strip" then it tries to use the "strip" command (which fails) > > instead of the cross-strip program, because the sub-makefiles expect the > > cross-tools to be provided as command-line overrides on the make > > invocation. > > When I tried this on my machine it worked without any problems. I am > not sure exactly what you mean when you complain that it uses the > "strip" command instead of the cross-strip program, since surely it is > the host's strip command that should be used. Sorry, I wasn't explicit enough. When I say "cross-compile binutils", I mean exactly that: I'm building binutils with a cross-compiler, so that the resulting executable will run on a different architecture. I don't mean that I'm building binutils to BE part of a cross-compiler: in that case you're right, I'd need to use the host's strip command. What I'm doing is building binutils on Intel but I want it to run on PPC. Thus, the resulting binaries are PPC binaries and in order to strip them I need to use the cross-compiler's "strip" command, not the native system's "strip". > According to a comment in the binutils/configure file you can also use > the environment variable STRIP to override the strip program used when > installing stripped binaries. This is exactly what I did: I set STRIP='powerpc-linux-gnu-strip' in the environment before I invoked configure. In the top-level makefile, I see that the STRIP variable has been set to powerpc-linux-gnu-strip. I also see that when the top-level makefile invokes the sub-makes, it sends that value (along with CC and the rest of it) to the sub-makes as overrides on the command line. But, when I look at the binutils/Makefile, I see that the STRIP variable is simply set to "strip", not the cross-compiler version of "strip". So if I invoke "make install-strip" directly from within the binutils subdirectory rather than from the top level, the cross-compiler version of STRIP is not set and it tries to use "strip" instead... which fails. Cheers! -- --- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.us "Please remain calm...I may be mad, but I am a professional." --Mad Scientist ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: [Bug binutils/6937] 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 ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/6937] binutils 2.18 fails linking libopcodes.so due to missing symbols
--- Additional Comments From nickc at redhat dot com 2008-10-13 15:28 --- Subject: Re: binutils 2.18 fails linking libopcodes.so dueto 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 -- http://sourceware.org/bugzilla/show_bug.cgi?id=6937 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/6937] binutils 2.18 fails linking libopcodes.so due to missing symbols
--- Additional Comments From kirill at shutemov dot name 2008-10-13 18:27 --- (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. -- http://sourceware.org/bugzilla/show_bug.cgi?id=6937 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/6937] binutils 2.18 fails linking libopcodes.so due to missing symbols
--- Additional Comments From ldv at altlinux dot org 2008-10-13 22:56 --- (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. -- http://sourceware.org/bugzilla/show_bug.cgi?id=6937 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/6937] binutils 2.18 fails linking libopcodes.so due to missing symbols
-- What|Removed |Added CC||ldv at altlinux dot org http://sourceware.org/bugzilla/show_bug.cgi?id=6937 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/6937] binutils 2.18 fails linking libopcodes.so due to missing symbols
--- Additional Comments From amodra at bigpond dot net dot au 2008-10-14 00:38 --- 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. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://sourceware.org/bugzilla/show_bug.cgi?id=6937 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
