Red Hat Bugzilla – Bug 586807
no libdwarf-static in fedora 13
Last modified: 2010-07-15 17:08:03 EDT
+++ This bug was initially created as a clone of Bug #540117 +++ Description of problem: no static version of libdwarf is provided in fedora 11 or up. libdwarf is used by perf tool kernel performance analysis utility. Ability to build a static version of this binary is important because developer would often use it to analyse performance for non-fedora or embedded systems, which might not have necessary libraries. Additional info: Fedora guidelines say: In general, packagers are strongly encouraged not to ship static libs unless a compelling reason exists. For me, the ability to create a portable perf binary that I can copy around linux systems qualifies as a compelling reason. --- Additional comment from fedora-triage-list@redhat.com on 2010-04-28 07:25:08 EDT --- This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping --- Additional comment from mst@redhat.com on 2010-04-28 08:08:08 EDT --- Fedora 12 has the same issue
I am going to update this to latest upstream release and have added -static subpackage. SRPM:- http://paragn.fedorapeople.org/libdwarf-0.20100629-1.fc13.src.rpm SPEC:- http://paragn.fedorapeople.org/libdwarf.spec Koji scratch F-13 link=> http://koji.fedoraproject.org/koji/taskinfo?taskID=2289407 Michael, If you can spare some time to look above updated package is ok to include subpackage -static or Do I need to ask FESCo permission for this? Just need to know if I can add -static.
No FESCo permission is needed for creating -static packages: https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries Anything that wanted to link statically with libdwarf would need FESCo's permission. The packaging split-off of the -static package is okay. [...] But there is an odd dependency in the base libdwarf package. Notice the first line here, $ rpm -qpR libdwarf-devel-0.20100629-1.fc13.x86_64.rpm|head -3 ()(64bit) elfutils-libelf libdwarf = 0.20100629-1.fc13 and the corresponding Provides here: $ rpm -qp --provides libdwarf-0.20100629-1.fc13.x86_64.rpm ()(64bit) libdwarf = 0.20100629-1.fc13 libdwarf(x86-64) = 0.20100629-1.fc13 The library has an empty SONAME. That's something you certainly want to fix before publishing this.
Thanks for the reply. I have updated patch which makes rpmlint output silent now. Updated SRPM:- http://paragn.fedorapeople.org/libdwarf-0.20100629-1.fc13.src.rpm SPEC:- http://paragn.fedorapeople.org/libdwarf.spec Koji scratch F-13 link=> http://koji.fedoraproject.org/koji/taskinfo?taskID=2295807
will build this tomorrow.
$ rpm -qp --provides libdwarf-0.20100629-1.fc13.x86_64.rpm libdwarf.so.0.0()(64bit) libdwarf = 0.20100629-1.fc13 libdwarf(x86-64) = 0.20100629-1.fc13 $ rpmlsv -p libdwarf-0.20100629-1.fc13.x86_64.rpm|grep so lrwxrwxrwx root root 15 /usr/lib64/libdwarf.so.0 -rwxr-xr-x root root 222896 /usr/lib64/libdwarf.so.0.0 The SONAME still doesn't look correct. Most likely you wanted it to be libdwarf.so.0 instead. [Currently, the symlink is useless.]
Updated SPEC again. Sorry not bumped the release tag. SRPM:- http://paragn.fedorapeople.org/libdwarf-0.20100629-1.fc13.src.rpm SPEC:- http://paragn.fedorapeople.org/libdwarf.spec Koji scratch F-13 link=> http://koji.fedoraproject.org/koji/taskinfo?taskID=2296130 $ rpmls libdwarf-0.20100629-1.fc13.x86_64.rpm | grep so -rwxr-xr-x /usr/lib64/libdwarf.so.0 lrwxrwxrwx /usr/lib64/libdwarf.so.0.0 $ rpmls libdwarf-devel-0.20100629-1.fc13.x86_64.rpm | grep so lrwxrwxrwx /usr/lib64/libdwarf.so Does this look good?
No, now the symlink is backwards and is useless again. libdwarf.so.0 should be the symlink to libdwarf.so.0.0 The symlink is maintained by ldconfig based on the library SONAME it finds in libdwarf.so.0.0 and -- if multiple libdwarf.so.X.Y were installed in parallel -- points at the latest library with SONAME libdwarf.so.0 (and we package those symlinks only for RPM file ownership).
I am confused here. I took from comment#5 that real file to be produced by Makefile is libdwarf.so.0 and if this is supposed to be real file then symlink file should be libdwarf.so.0.0? In general real file is library.so.X.Y.Z and symlinks are library.so and library.so.X right?
Ok, here is another scratch build http://koji.fedoraproject.org/koji/taskinfo?taskID=2296367 $ rpmls libdwarf-0.20100629-1.fc13.x86_64.rpm | grep so lrwxrwxrwx /usr/lib64/libdwarf.so.0 -rwxr-xr-x /usr/lib64/libdwarf.so.0.0 $ rpmls libdwarf-devel-0.20100629-1.fc13.x86_64.rpm | grep so lrwxrwxrwx /usr/lib64/libdwarf.so
Comment 5 did not refer to any Makefile or the build process. It only examined the RPM packages. In the build process, anything could have happened (such as renaming libs and creating symlinks). I could also have commented on F13: $ rpm -q libdwarf libdwarf-0.20090324-5.fc12.x86_64 $ rpmls libdwarf|grep so lrwxrwxrwx /usr/lib64/libdwarf.so.0 -rwxr-xr-x /usr/lib64/libdwarf.so.0.0 At first sight, the symlink appears to be sane. However, it isn't used: $ ldconfig -p|grep dwarf libdwarf.so.0.0 (libc6,x86-64) => /usr/lib64/libdwarf.so.0.0 $ rpm -q --provides libdwarf|grep so libdwarf.so.0.0()(64bit) Btw, that also implies that an update would be ABI incompatible as it will change the SONAME. Anyway, the build from comment 9 is better. :)
libdwarf-0.20100629-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/libdwarf-0.20100629-1.fc13
libdwarf-0.20100629-1.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update libdwarf'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/libdwarf-0.20100629-1.fc13
libdwarf-0.20100629-1.fc13, CodeAnalyst-gui-2.8.54-23.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update libdwarf CodeAnalyst-gui'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/CodeAnalyst-gui-2.8.54-23.fc13,libdwarf-0.20100629-1.fc13
*** Bug 613956 has been marked as a duplicate of this bug. ***
libdwarf-0.20100629-1.fc13, CodeAnalyst-gui-2.8.54-23.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.