Solved sanity check post pkg upgrade

freezmi

freezmi

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
 
freezmi said:
Is there a sanity check script that would verify if the currently installed pkgs or ports are properly linked against the system libraries?
Click to expand...
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.
 
freezmi said:
unfortunately I don't have the entire broken pkg, only the binary. and with the broken binary placed in /usr/local/bin/ I get
Click to expand...
That's always a bad idea.

Just install the pkg/port (and its dependencies) as intended and it will work.
 
Hi sko,
sko said:
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.
Click to expand...

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

last month - install umurmur-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
umurmur 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.

sko said:
That's always a bad idea.

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

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
 
I ran into something similar, pkg upgrade picked up a new version of ImageMagick7. I use WindowMaker, which has "libwraster" as a dependency. So starting my graphical environment I got a similar message about libraries and had nothing.
For me, doing a "pkg install -f libwraster" corrected the problem.
 
Yup, while using Gentoo I always run revdep-rebuild to find _any_ binary that might have got affected by a lib update. The script above is a good starting-point equivalent for FreeBSD.
This ensures that there are no surprises outside the maintenance window.

also +1 for wmaker, have been using it since the early 2000s with great success.
 
freezmi said:
# 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
[/code]
Click to expand...
Ups! That one was seen before:


I tried to investigate in that matter, but couldn't reproduce it.

sko said:
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.
Click to expand...

In that case I tried the possible mixes, and they all do work. Something here happens that should not happen.

Trying to do a check on linker dependencies is one thing. But one should figure out what exactly is wrong, and then find the root cause.
 
PMc thanks for the link. Steve is on the money here:

However, on 4 servers (3 amd64, 1 i386) which had pre-existing bind and
bind-tools pkgs already installed, upgrading protobuf[-c] yielded the
lib problem Niall saw, e.g. for both 'dig' and 'named' binaries.
Click to expand...

here you'll find the older umurmurd binary that came with a umurmur-0.2.20 pkg built before 2024-10-09T17:34:12+0000

have a look with objdump -T, compare with the current umurmur package and see the hardcoded libprotobuf_c version in the broken binary.

as a worst-case scenario, incrementing the version of packages when a rebuild is done would fix this issue. the problem in my case is that the umurmur-0.2.20 package was silently recompiled on the 2024-10-09T17:34:12+0000 with no version increment.

later edit:
even better would be to force binaries to not link against a specific version of a library :)

in order to reproduce this, you'll need to first checkout a snapshot of /usr/ports from last month and then compile/install umurmur and it's dependencies, checkout current, compile/install the new protobuf*.

bye,
peter
 
freezmi said:
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.
Click to expand...
Rich (BB code): 
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.

audio/umurmur and audio/murmur are two different items. There is no "murmur-0.2.20"; and in your last message you mix these two again. Could you elaborate?

Focussing on umurmur, these very recent commits may have some relevance: Makefile - umurmur - Q4 & Makefile - umurmur - main (aka "latest")

BTW, port maintainers do not ("silently") (re)build packages; they maintain ports. Packages get build by the FreeBSD build servers. A port/package does not always get a new version/portrevision number when its package is being rebuild. For example, with the transition to 2024Q4 (recently) and with the EoL of 14.0-RELEASE, all packages that are being made available for the 14.x branch are being rebuild against 14.1-RELEASE. I also think that when a dependend port changes, this does not have to result in a version change, that could result in a PORTVERSION change; see for details Chapter 5. Configuring the Makefile.
 
hi.

sorry for the typo. the package I'm referring to in all my messages is

Code: 
# pkg which `which umurmurd`
/usr/local/bin/umurmurd was installed by package umurmur-0.2.20

I fixed the errors so there should be less confusion.
 
You must log in or register to reply here.
Back
Top