From Bugzilla Helper: User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.2-2 i686) Description of problem: When the SONAME field is missing from the ELF header, and a versioning file was used (i.e. "gcc -shared -olibmylibrary.so -Wl,--version-script,myversionscript mysource.o" --Notice that the optional -h flag is missing) find-provides doesn't recognise the versioning info. RPM builds the package file, but won't install it because find-requires _DOES_ see the versioning info, and expects it to be there. For example: find-provides produces: libmylibrary.so find-requires produces: libmylibrary.so libmylibrary.so(VER2) If executables or other shared libraries within the same RPM package are dependent on libmylibrary.so, RPM will not install the package because "libmylibrary.so(VER2)" can't be found even though it is actually provided within that very same package file. We have seen this problem starting at RPM v3.0.4 How reproducible: Always Steps to Reproduce: 1. Build a library without a SONAME field, but with versioning info 2. Build an executable that depends on that library 3. Package them up using RPM 4. Attempt to install the RPM package Additional info: The following solution is a replacement for the current find-provides. If the SONAME field is absent, it correctly defaults its value to the filename. I also moved the check for the symlink files to improve performance. I am not sure why the original author uses "file -L", since the file will only be thrown away by the later check to filter out symbolic links. Here is the code: #!/bin/bash # This script reads filenames from STDIN and outputs any relevant provides # information that needs to be included in the package. filelist=$(grep "\\.so" | grep -v "^/lib/ld.so" | xargs file -L 2>/dev/null | grep "ELF.*shared object" | cut -d: -f1) for f in $filelist; do if [ ! -L $f ]; then soname=$(objdump -p $f | awk '/SONAME/ {print $2}') if [ -z "$soname" ]; then soname=${f##*/} fi echo $soname objdump -p $f | awk ' BEGIN { START=0 ; } /Version definitions:/ { START=1; } /^[0-9]/ && (START==1) { print $4; } /^$/ { START=0; } ' | \ grep -v $soname | \ while read symbol ; do echo "$soname($symbol)" done fi done | sort -u
Can you provide a detailed example please, including package(s) that exhibit the problem/feature? Since dependencies have a global scope across arch and distro far beyond the find-requires script, I need to see the problem more specifically in order to compute the ramifications of changing the automagic find-requires script.
I will provide a small example ASAP
This problem is not recreatable with RPM v4.0.2 as is, because the find-requires script has been changed to only to require GLIBC_* version labels. This seems more than a bit peculiar. So, the find-provides and find-requires scripts are still not symmetric, but the only way to recreate this particular problem now would be to give a version label with GLIBC_*. While theoretically possible, from a real-world standpoint, it doesn't seem plausible. This is still a problem in RPM v3.0.4 (RH 6.2), and perhaps later RPM's which I don't have access to, nor do I know which ones are still being actively maintained. It appears that I've opened this against RH7.1, but it was probably initially discovered a few months ago on a beta of RH7.0, which I no longer have. I should have double-checked the RH & RPM versions before opening this against RH7.1. In my opinion only, find-provides and find-requires are still both broken but I don't know if this should be pursued under this bug, or pursued at all. Please advise.
Again, I need an expliciit example of a provide/require that is not being generated correctly from some (hopefully rpm-4.0.3) version of rpm to even begin to assess the impact of a change to find-{provides,requires}.
Attached is an example of the original problem, the only difference is that I changed the version labels to GLIBC_666 because of the peculiar way find-requires was changed. Commands to demonstrate: "tar -xvf mypkg.tar; make install"
Created attachment 26418 [details] tar file to demonstrate find-provides/find-requires bug
I'll look at this soon after rpm-4.0.3 is released, as changes to the dependency generation scripts need to be carefully thought about.