sanity check post pkg upgrade

hello.

Is there a sanity check script that would verify if the currently installed pkgs or ports are properly linked against the system libraries?

in Gentoo there is a 'reverse dependency rebuilder' called
Code:
revdep-rebuild
that catches such linking errors.

I ask because after yesterday's 14.1
Code:
pkg upgrade
I was left with a broken daemon:
Code:
# umurmurd 
ld-elf.so.1: /usr/local/lib/libprotobuf-c.so.1: version LIBPROTOBUF_C_1.0.0 required by /usr/local/bin/umurmurd not defined

ldd does not report any error on this binary,
Code:
# objdump -T umurmurd
0000000000000000      DF *UND*  0000000000000000 (LIBPROTOBUF_C_1.0.0) protobuf_c_message_get_packed_size
0000000000000000      DF *UND*  0000000000000000 (LIBPROTOBUF_C_1.0.0) protobuf_c_message_pack
0000000000000000      DF *UND*  0000000000000000 (LIBPROTOBUF_C_1.0.0) protobuf_c_message_pack_to_buffer
0000000000000000      DF *UND*  0000000000000000 (LIBPROTOBUF_C_1.0.0) protobuf_c_message_unpack
0000000000000000      DF *UND*  0000000000000000 (LIBPROTOBUF_C_1.0.0) protobuf_c_message_free_unpacked

but this information alone is not enough to recognize that the binary will not execute properly.
fixing this particular binary is not what I'm interested in, I'd like a pointer toward how to automatically find all binaries that could be affected by a library update.

thanks!
 
hello, and thank you for the message.

unfortunately I don't have the entire broken pkg, only the binary. and with the broken binary placed in /usr/local/bin/ I get

Code:
sunspire ~ # pkg check -B umurmur
Checking umurmur: 100%

I had a look at the sources of the dynamic linker and ended up writing a shell script that checks all binaries via the LD_DUMP_REL_PRE option provided by ld-elf.so.1 - without actually executing them. it is available here

using my script I get this output - feedback is welcome:
Code:
sunspire ~ # bin/revdep-rebuild.sh
the following binaries have failed the dynamic linker test:
    * /usr/local/bin/umurmurd
        ld-elf.so.1: /usr/local/lib/libprotobuf-c.so.1: version LIBPROTOBUF_C_1.0.0 required by /usr/local/bin/umurmurd not defined
        /usr/local/bin/umurmurd was installed by package umurmur-0.2.20

cheers!
peter
 
Is there a sanity check script that would verify if the currently installed pkgs or ports are properly linked against the system libraries?
This is only necessary on linux where everything is "your opinion".
FreeBSD is a coherent OS - the system libraries in base are fixed for the given version of the OS and don't change. This means: if the pkg/port has been built on the same OS version, they are linked against the same library versions.

pkg checks this at the very beginning of any 'update/upgrade' and warns if the packages in the repository have been built against another ABI version (~ OS version).


However, the library you are getting errors for (protobuf) is from ports. Any port that needs something else from ports (possibly in a given version), should a) build against that version and b) pull in that port (in the required version) as a dependency.
This works reliably as long as you don't mix packages and ports or packages from different repositories.
 
unfortunately I don't have the entire broken pkg, only the binary. and with the broken binary placed in /usr/local/bin/ I get
That's always a bad idea.

Just install the pkg/port (and its dependencies) as intended and it will work.
 
Hi sko,
FreeBSD is a coherent OS - the system libraries in base are fixed for the given version of the OS and don't change. This means: if the pkg/port has been built on the same OS version, they are linked against the same library versions.

Except that sometimes life happens. I'm not into starting a 'which os is better' contest. My timeline was as follows:

last month - install murmur-0.2.20 with all dependecies using pkg (AFAIR no ports involved)
a few days ago upgrade ~100 pkgs related to 14.1 among which protobuf-c
murmur had no new version during this upgrade so it was not re-installed.
I guess umurmur was silently re-compiled by the pkg maintainer but since the version number has not changed I ended up with that broken binary from last month. Which IMHO means I need that script I wrote ^ that will be run after each upgrade to make sure system is sane.

That's always a bad idea.

Just install the pkg/port (and its dependencies) as intended and it will work.

As I said in the OP I'm not interested in fixing that particular package, I can handle that just fine. The broken binary has been placed there just to test out ways to detect linking problems.

cheers,
peter
 
Back
Top