Description of problem: libldap.a is stripped and this causes problems when trying to debug anything that has been linked against it Version-Release number of selected component (if applicable): openldap-2.3.43-12.el5_6.5 How reproducible: Always Steps to Reproduce: 1. readelf -d /usr/lib/libldap.a or readelf -d /usr/lib64/libldap.a 2. Debug an application that has linked against one of the libraries which has itself linked to libldap.a 3. Actual results: No debugging symbols found Expected results: Debugging symbols found Additional info: This bugzilla is related to 684629
Created attachment 484117 [details] patch Attaching patch. It adds STRIP="" to every 'make install' in spec file.
*** Bug 684629 has been marked as a duplicate of this bug. ***
*** Bug 605567 has been marked as a duplicate of this bug. ***
Resolved in openldap-2.3.43-20.el5
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: - openldap-* packages installed, always - debuginfo for some libraries/binary files is not available - added make options not to strip debuginfo data at the early stage of the build process, before creating openldap-debuginfo package - openldap-debuginfo package is complete, all parts of OpenLDAP can be debugged
I still see the same with both old and new versions: #1 0x00002b6a62dc8a65 in ldap_result () from /lib64/libnss_ldap.so.2 No symbol table info available. However, there are more debugging symbols when debugging e.g. ldapsearch. Anyway, I do not think that the original problem is fixed. Here's my reproducer: A) for getent #!/bin/bash cat >/etc/ldap.conf<<EOF base dc=redhat,dc=com uri ldap://ldap.corp.redhat.com/ EOF getent -s 'passwd: ldap' passwd >/dev/null 2>&1 & sleep 3 gcore `pgrep getent` >/dev/null 2>&1 ( expect <<EOF spawn gdb getent `ls core*` expect "(gdb)" { send "bt full\r" } expect "(gdb)" { send "quit\r" ; exit 0 } EOF ) >out 2>&1 grep -A 1 "ldap_result" out rm core* out B) for ldapsearch #!/bin/bash ldapsearch -H ldap://ldap.corp.redhat.com/ -b dc=redhat,dc=com -x '*' >/dev/null 2>&1 & sleep 3 gcore `pgrep ldapsearch` >/dev/null 2>&1 ( expect <<EOF spawn gdb ldapsearch `ls core*` expect "(gdb)" { send "bt full\r" } expect "(gdb)" { send "quit\r" ; exit 0 } EOF ) >out 2>&1 grep -B 1 "No symbol" out rm core* out
Ondrej, this was really fixed only partially. Stripping of dynamic libraries is fine. But RPM strips static libraries, therefore no tools linked against these static libraries can be debugged (like nss_ldap). I didn't know that. Linking against static libraries is very unusual, but we need it in this case. I looked around and it seems that the only way of disabling the stripping of static libraries by rpmbuild is to override "__os_install_post" macro in the specfile and remove the execution of /usr/lib/rpm/redhat/brp-strip-static-archive. And the packages linked statically against libldap will have to be rebuild. Which is very unfortunate at the moment. It would make sense to respin the openldap package thus any future builds of any tools linking libldap statically would contain debuginfo data. Most issues with debugging are resolved with current fix. And I do not know if there is any other package except nss_ldap, linking against libldap.a. But I can check. So, what can be done? Jan
(In reply to comment #16) > Linking against static libraries is very unusual, but we need it in this case. > I looked around and it seems that the only way of disabling the stripping of > static libraries by rpmbuild is to override "__os_install_post" macro in the > specfile and remove the execution of > /usr/lib/rpm/redhat/brp-strip-static-archive. And how will get stripped the .so files and binaries? At least `rpm -qi glibc-debuginfo' suggests: To use this debugging information, you need to link binaries with -static -L%{_prefix}/lib/debug%{_prefix}/%{_lib} compiler options. So the stripping of OpenLDAP may be fine and more the applications linking to the static library from it should be fixed.
(In reply to comment #17) > (In reply to comment #16) > > Linking against static libraries is very unusual, but we need it in this case. > > I looked around and it seems that the only way of disabling the stripping of > > static libraries by rpmbuild is to override "__os_install_post" macro in the > > specfile and remove the execution of > > /usr/lib/rpm/redhat/brp-strip-static-archive. > > And how will get stripped the .so files and binaries? Thus, aforementioned solution might bring other problems? Is it sane or not? > To use this debugging information, you need to link binaries > with -static -L%{_prefix}/lib/debug%{_prefix}/%{_lib} compiler options. > > So the stripping of OpenLDAP may be fine and more the applications linking to > the static library from it should be fixed. Does it mean that there is a solution without changing openldap specfile? I would indeed prefer it. But does it really work (even if RPM strips static libs)?
(In reply to comment #17) > And how will get stripped the .so files and binaries? Does brp-strip-STATIC-archive get involved in .so/binaries? If not, what is the concern? > So the stripping of OpenLDAP may be fine and more the applications linking to > the static library from it should be fixed. Maybe you're missing the point that the static openldap libraries are being used for a good reason, and their debuginfo has been irrevocably lost during openldap's build.
(In reply to comment #19) > Does brp-strip-STATIC-archive get involved in .so/binaries? If not, what > is the concern? The concern is they want to override "__os_install_post". There is also a concern whether system .a library should contain debug info or not. If you do not care about debug info it is excessive waste. If you care about debug info you can use openldap-debuginfo.rpm. This is more a rel-eng decision. Maybe it is already decided and written down somewhere. But at least current glibc-debuginfo.rpm follows the model system .a library is stripped and if you want debug info you should use its /usr/lib/debug/.../library.a variant. This also means you must: BuildRequires library-debuginfo.rpm > Maybe you're missing the point that the static openldap libraries are being > used for a good reason, and their debuginfo has been irrevocably lost during > openldap's build. The debug info is not lost, it is still present and ready for linking in openldap-debuginfo.rpm.
> > Maybe you're missing the point that the static openldap libraries are being > > used for a good reason, and their debuginfo has been irrevocably lost during > > openldap's build. > > The debug info is not lost, it is still present and ready for linking in > openldap-debuginfo.rpm. Not so, for static libraries. That's the point. .a/.o files have not received build-id links / .debug files, the last time I checked.
(In reply to comment #21) > > The debug info is not lost, it is still present and ready for linking in > > openldap-debuginfo.rpm. > > Not so, for static libraries. That's the point. .a/.o files have not > received build-id links / .debug files, the last time I checked. OK, I was wrong. Still remains a point the openldap .spec should be changed so that .a with debuginfo is present rather in openldap-debuginfo.rpm. Maybe rather rpmbuild should be changed itself.
> Still remains a point the openldap .spec should be changed so > that .a with debuginfo is present rather in openldap-debuginfo.rpm. I'm not sure that would work. The .a file and its constituent .o files have no run-time meaning to gdb, so even if unstripped copies were kept in the -debuginfo, gdb would never look for them there.
Not directly. Imagine someone does not care about GDB at all. (s)he still needs the -devel package with .a files to build static system/recovery tools. Why (s)he needs to carry the debug info in .a files which (s)he will never use? The distributed .rpm files are there primarily for end-users (end-user developers), not just for building new .rpm files. This is more a topic for FESCo, I can file it. I do not find this case described in http://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries and we see now there exist contradictory opinions on it.
I believe current proposal is: - to change openldap to avoid stripping the .a file - therefore, the FOO-static RPM will contain debuginfo-equipped .a - FOO-debuginfo will contain nothing about the .a To use this with nss or whatnot: - buildrequire FOO-static - link against the .a, which will copy the debuginfo into the nss .so/binaries - the nss .so/binaries may be stripped into separate nss-debuginfo as usual End users do not install FOO-static nor nss-debuginfo, and thus don't pay for debuginfo storage. People whose nss breaks will get nss-debuginfo, which will have within it the relevant parts of FOO libfoo.a's debuginfo. I don't see a problem with this scheme.
(In reply to comment #25) > End users do not install FOO-static <strip> > and thus don't pay for debuginfo storage. We do not agree on this part. I do not know the reasons why exists libldap.a at all but at least I am aware of the reasons for libc.a. This is why /usr/lib64/libc.a should not contain debug info as it may be used to build various recovery tools by end-users.
Just I think we talk about non-sense here. * Tue Jan 19 2010 Jan Zeleny <jzeleny> - 2.4.21-2 - removed some static libraries from openldap-devel (#556090) Fedora openldap no longer contains /usr/lib64/libldap.a at all. Therefore this Bug is probably only valid for RHEL-5 which does not matter much / to FESCo. There is still /usr/lib64/evolution-openldap/lib64/libldap.a but that one seems to be offtopic here.
(In reply to comment #17) > At least `rpm -qi glibc-debuginfo' suggests: > > To use this debugging information, you need to link binaries > with -static -L%{_prefix}/lib/debug%{_prefix}/%{_lib} compiler options. Is there something special which has to be done in the specfile in order to get this working? I do not see anything special there. I suppose it should work the same with openldap (and openldap-debuginfo installed). It does not work for me (check my "reproducer"). Am I doing something wrong? #include <ldap.h> int main(void) { LDAP *ldp; ldap_initialize(&ldp, "ldap://localhost"); return 0; } $ gcc -g -O0 -Wall -o dynamic main.c -lldap $ gcc -g -O0 -Wall -o static main.c -L/usr/lib/debug/usr/lib64 -Wl,-Bstatic -lldap -llber -lsasl2 -lldap -llber -lssl -lcrypto -lgssapi_krb5 -lkrb5 -lk5crypto -lkrb5support -lz -Wl,-Bdynamic -lcom_err -lkeyutils -ldl -lselinux -lresolv -lpthread_nonshared -lc $ ldd static dynamic static: linux-vdso.so.1 => (0x00007fff889fd000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x0000003454000000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x000000345a000000) libdl.so.2 => /lib64/libdl.so.2 (0x000000344ec00000) libselinux.so.1 => /lib64/libselinux.so.1 (0x000000344fc00000) libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003456400000) libc.so.6 => /lib64/libc.so.6 (0x000000344e400000) /lib64/ld-linux-x86-64.so.2 (0x000000344e000000) libsepol.so.1 => /lib64/libsepol.so.1 (0x0000003450000000) dynamic: linux-vdso.so.1 => (0x00007fff56795000) libldap-2.3.so.0 => /usr/lib64/libldap-2.3.so.0 (0x00000030ac200000) libc.so.6 => /lib64/libc.so.6 (0x000000344e400000) liblber-2.3.so.0 => /usr/lib64/liblber-2.3.so.0 (0x00000030ac600000) libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003456400000) libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x0000003464200000) libssl.so.6 => /lib64/libssl.so.6 (0x00000030af200000) libcrypto.so.6 => /lib64/libcrypto.so.6 (0x0000003459000000) /lib64/ld-linux-x86-64.so.2 (0x000000344e000000) libdl.so.2 => /lib64/libdl.so.2 (0x000000344ec00000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000003460e00000) libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00000030ade00000) libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00000030ae200000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x0000003454000000) libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00000030ad200000) libz.so.1 => /lib64/libz.so.1 (0x000000344f400000) libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00000030ada00000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x000000345a000000) libselinux.so.1 => /lib64/libselinux.so.1 (0x000000344fc00000) libsepol.so.1 => /lib64/libsepol.so.1 (0x0000003450000000) $ gdb ./dynamic ... Reading symbols from /root/openldap_static_debug/dynamic...done. (gdb) break ldap_initialize Breakpoint 1 at 0x4004b0 (gdb) r Starting program: /root/openldap_static_debug/dynamic Breakpoint 1, ldap_initialize (ldp=0x7fffffffe7f8, url=0x4006b8 "ldap://localhost") at ../../../libraries/libldap/open.c:220 220 { (gdb) s 224 *ldp = NULL; $ gdb ./static ... Reading symbols from /root/openldap_static_debug/static...done. (gdb) break ldap_initialize Breakpoint 1 at 0x410a90 (gdb) r Starting program: /root/openldap_static_debug/static warning: no loadable sections found in added symbol-file system-supplied DSO at 0x2aaaaaaab000 Breakpoint 1, 0x0000000000410a90 in ldap_initialize () (gdb) s Single stepping until exit from function ldap_initialize, which has no line number information. main () at main.c:8 8 return 0; $ rpm -qa openldap\* --qf="%{name}-%{version}-%{release}.%{arch}\n" openldap-2.3.43-24.el5.x86_64 openldap-2.3.43-24.el5.i386 openldap-devel-2.3.43-24.el5.x86_64 openldap-clients-2.3.43-24.el5.x86_64 openldap-servers-2.3.43-24.el5.x86_64 openldap-debuginfo-2.3.43-24.el5.x86_64
Created attachment 551426 [details] openldap-2.3.43-24.el5 .spec patch (In reply to comment #31) > Is there something special which has to be done in the specfile in order to > get this working? Yes. glibc uses its own debug info handling. Not sure how much it makes sense import into Rawhide rpmbuild as almost all the *.a files have been eliminated and glibc may be one of the last packages but it already handles it on its own. Anyway tried the change for openldap-2.3.43-24.el5 .spec, attached. It will still need the -L modification in the applications linking with it. And I am not completely sure RHEL-5 can BuildRequires: some-debuginfo IIRC one could not in the past, it has been fixed later, not sure when.
Wouldn't it be simpler to suppress the libldap.a stripping during the openldap build process?
I think we should do what is better for the distro, not what is more simple. I really no longer mind anything about this Bug as it does not apply to Rawhide. Here were some suggestions in Comment 16, I did not try them, if they work sure I do not mind if they get used instead.
(In reply to comment #32) > Created attachment 551426 [details] > openldap-2.3.43-24.el5 .spec patch Thanks! I will try to update nss_ldap.spec and check, if it works. (In reply to comment #34) > I think we should do what is better for the distro, not what is more simple. Redefining "__os_install_post" is not conceptual. I like the solution with debuginfo package more. If it works, I would like to use it. If it does not, let's disable the stripping. Ondrej, is this critical from QA point of view? Will be there a possibility to respin the package? Or should I only prepare the patch to be included some other time?
Jan, as far as I can see, all proposed solutions are only specfile changes - could you prepare new specfiles and attach them here or send them directly to me so that I can test them? If it won't work, we should probably postpone this fix later and remove bug from ET, but I definitely prefer to have working solution in 5.8.
(In reply to comment #36) > Jan, as far as I can see, all proposed solutions are only specfile changes - > could you prepare new specfiles and attach them here or send them directly to > me so that I can test them? My proposed .spec solution which works during RHEL-5 test for me I posted in Comment 32. Unless someone decides this way is wrong and we choose some other way I am not going to randomly code more tested solutions.
Your specfile works fine with Jan's reproducer given Comment #31. However I cannot rebuild nss_ldap with export LIBS="-L%{_prefix}/lib/debug%{_prefix}/%{_lib} $LIBS": ... gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fPIC -fno-strict-aliasing -Wall -fPIC -o nss_ldap.so -shared -Wl,-Bdynamic -Wl,--version-script,./exports.linux ldap-nss.o ldap-pwd.o ldap-grp.o ldap-netgrp.o ldap-rpc.o ldap-hosts.o ldap-network.o ldap-proto.o ldap-spwd.o ldap-alias.o ldap-service.o ldap-schema.o ldap-ethers.o ldap-bp.o ldap-automount.o util.o ltf.o snprintf.o resolve.o dnsconfig.o irs-nss.o pagectrl.o ldap-sldap.o depth.o -lldap -llber -lgssapi_krb5 -ldl -lpthread_nonshared -lnsl -lresolv -L/usr/lib/debug/usr/lib64 -L/usr/kerberos/lib64 -Wl,-Bstatic -lldap -llber -lsasl2 -lldap -llber -lssl -lcrypto -lgssapi_krb5 -lkrb5 -lk5crypto -lkrb5support -lz -Wl,-Bdynamic -lcom_err -lkeyutils -ldl -lselinux -lresolv -lpthread_nonshared -lc /usr/bin/ld: /usr/lib/debug/usr/lib64/libresolv.a(res_comp.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib/debug/usr/lib64/libresolv.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[1]: *** [nss_ldap.so] Error 1 Jan, Jakub - am I doing something wrong here?
(In reply to comment #39) > Your specfile works fine with Jan's reproducer given Comment #31. However I > cannot rebuild nss_ldap with export > LIBS="-L%{_prefix}/lib/debug%{_prefix}/%{_lib} $LIBS": Ondrej, I suppose you are trying to build the package locally. I just rechecked, and RHEL-5 repositories in brew does not contain -debuginfo packages. So this will not work in brew anyway.
Ah, bad luck... what was another proposed solution?
Comment on attachment 551426 [details] openldap-2.3.43-24.el5 .spec patch debuginfo rpms are reportedly not available in RHEL-5 Brew.
Comment 16 was suggesting the non-stripped /usr/lib64/libldap.a way.
Created attachment 552128 [details] spec patch: disables stripping of static libs
Works with my reproducer from comment #17. Path to source codes has to be specified manually: # gdb ./static -d /usr/src/debug/openldap-2.3.43/openldap-2.3.43/libraries/libldap ... Reading symbols from /root/openldap_static_debug/static...done. (gdb) break ldap_initialize Breakpoint 1 at 0x410a90: file ../../../libraries/libldap/open.c, line 220. (gdb) r Starting program: /root/openldap_static_debug/static warning: no loadable sections found in added symbol-file system-supplied DSO at 0x2aaaaaaab000 Breakpoint 1, ldap_initialize (ldp=0x7fffffffe7f8, url=0x6105b0 "ldap://localhost") at ../../../libraries/libldap/open.c:220 220 { (gdb) s 224 *ldp = NULL; (gdb)
Fixed in: openldap-2.3.43-25.el5
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0155.html