+++ This bug was initially created as a clone of Bug #147378 +++ Description of problem: The autofs package makefiles include strip commands to remove debug information from built package binaries, instead of allowing rpm to do the stripping. This results in a debuginfo package that contains stripped binaries, making them useless Version-Release number of selected component (if applicable): all How reproducible: always Steps to Reproduce: 1.install the autofs-4.1-3 (or any autofs) debuginfo package 2.run file on /usr/lib/debug/usr/sbin/automount.debug 3. Actual results: file reports that binary file is stripped Expected results: file should not be stripped Additional info: -- Additional comment from nhorman on 2005-02-07 13:56 EST -- Created an attachment (id=110737) patch to remove stripping from build Makefiles This patch removes the stripping stage from the Makefile.rules makefile used to build autofs. This allows rpmbuild to generate a symboled debuginfo package and still produce a stripped distribution package. -- Additional comment from jmoyer on 2005-02-07 13:58 EST -- Yeah. this has been bugging me for a while, but I haven't gotten around to fixing it yet. Thanks for doing the work! -Jeff -- Additional comment from nhorman on 2005-02-07 14:01 EST -- No worries, happy to help! -- Additional comment from berrange on 2005-02-14 05:38 EST -- That first patch only removes the $(STRIP) calls for shared libraries in the top level Makefile. There are a handful of calls to $(STRIP) in makefiles for building the binaries & loadable modules in the sub-directories too. The patch I attached to the UBS Issue Tracker ticket #65082 takes care of removing those calls too. --Dan. -- Additional comment from nhorman on 2005-02-14 07:27 EST -- Those targets should all probably just be removed entirely. The way the Makefile is constructed I believe all the modules are built using the c.so suffix rule in Makefile.rules. The individual so target rules are never used. If you just modify the LDFLAGS and CFLAGS macros and the c.so target in Makefile.rules, all the modules correctly build with symbols in place. -- Additional comment from berrange on 2005-02-14 08:05 EST -- That generic .c.so rule is used to build most of the modules, however, the lookup_*.so modules have custom rules which override this in modules/Makefile. Also, the rules to build .o files from .c in the lib directory which are then linked into the automount program binary, and rules for the binary itself all invoke $(STRIP) too.
For testing, you should be able to install the autofs and autofs-debuginfo packages, and run: $ gdb /usr/sbin/automount At the gdb prompt, issue the following commands. If you get the output listed here, then the debuginfo packages are useful. (gdb) whatis ap type = struct autofs_point (gdb) p (struct autofs_point) ap $2 = {path = 0x0, pipefd = 0, ioctlfd = 0, dev = 0, maptype = 0x0, type = 0, exp_timeout = 0, exp_runfreq = 0, ghost = 0, exp_process = 0, mounts = 0x0, lookup = 0x0, state = ST_INIT, state_pipe = {0, 0}, dir_created = 0}
Created attachment 127360 [details] Add a make option to not strip binaries. This patch adds the ability to specify "DONTSTRIP=1" on the make command line, in order to keep the build process from stripping binaries. The .spec file needs to be modified to use this option in the %build section.
A fix for this was committed to autofs-4.1.3-177.
This bug was put on Proposed while waiting for the autofs package to get put on the approved list. Now that autofs is approved, we'd like to get a qa_ack for this BZ, and move it to CanFix. Please ack.
I built an updated version of autofs which addresses the problems reported in this bug. Please test the package found here: http://people.redhat.com/jmoyer/rhel4u4-autofs/ There are builds for every architecture. The changes to this package are fairly invasive and, as such, I'd like to get testing feedback as soon as possible. If there is any unexpected change in behaviour, please be sure to report it. Thanks in advance! Jeff
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2006-0464.html