Avoid "error while loading shared libraries" after dependency upgrade

exap · 2017-02-20 02:19:45

Hey all,

I run a C++ program on my computer as a systemd service. I wrote it last month and never touched it since.

It depends on boost.system and after boost.system was upgraded, my program didn't start anymore because of this error:

my-program: error while loading shared libraries: libboost_system.so.1.62.0: cannot open shared object file: No such file or directory

The error makes sense. But how is this problem commonly solved? I didn't find anything in the internet. Maybe I searched the wrong phrases.

I don't want to recompile my program every time boost.system gets upgraded.. So how can I automagically recompile my program after boost.system was upgraded? It would be pretty nice if there was a way to write a PKGBUILD that says "recompile, after the dependency was upgraded". If there is no way to say this, any other ideas how to solve this?

I'd appreciate any hints and tips

eschwartz · 2017-02-20 03:47:24

You seem to have discovered the answer. Recompile it... Alternatively, statically link it, the boost package comes with *.a libs for all the libboost_* stuff.

You could use a pacman hook -- see alpm-hooks(5) for details -- to run the recompilation command after every update of the boost-libs package.
PKGBUILDs are useless for you here, well, they certainly help you package the program so it is tracked by pacman, but makepkg/PKGBUILDs have no integration whatsoever with pacman updates.

exap · 2017-02-20 14:26:41

post-transaction hooks are what I searched for, thanks!

But I am curious, how do the Arch maintainers avoids this error? They don't link the libraries static. Also, a package doesn't get upgraded, when it's dependency is. So how do they solve this?

eschwartz · 2017-02-20 14:36:11

Um, packages do get upgraded when their dependencies are. Assuming the package itself has an upgrade...

When a dependency has soname updates, they put the package in the staging repo and rebuild every single package that links against it. For example, boost updates are always accompanied by very large rebuilds of all packages that use boost.

exap · 2017-02-20 14:48:24

When a dependency has soname updates, they put the package in the staging repo and rebuild every single package that links against it. For example, boost updates are always accompanied by very large rebuilds of all packages that use boost.

Ah, cool. So does boost get not upgraded until there isn't any package in the staging repo that depends on boost? Because if boost would get upgraded immediately, that would break all the programs in core and community repo depending on boost that are also in the staging repo, right?

Trilby · 2017-02-20 18:05:22

No, it's the other way around. Boost gets upgraded whenever there is a new version. At that point, if there was a so name bump every package that depends on it is also rebuilt.

exap · 2017-02-20 18:14:28

Trilby wrote:

Boost gets upgraded whenever there is a new version. At that point, if there was a so name bump every package that depends on it is also rebuilt.

I got that. But Eschwartz says that the rebuilt packages are put into the staging repo:

Eschwartz wrote:

they put the package in the staging repo and rebuild every single package that links against it

And then these packages in the staging repo only get into the core and community repo if there is an actuall new version of the program:

Eschwartz wrote:

packages do get upgraded when their dependencies are. Assuming the package itself has an upgrade...

But if that was true and boost was upgraded immediately, there would be broken packages in the core and community repo (as I said).

So, where is my fallacy?

Scimmia · 2017-02-20 18:21:09

exap wrote:

And then these packages in the staging repo only get into the core and community repo if there is an actuall new version of the program:

This is what you're missing. Once the rebuild is done, all of the package involved get moved to testing, and eventually to core/extra/community all at the same time.

Trilby · 2017-02-20 18:25:25

The "assuming the package itself has an upgrade" is incorrect. Just drop that part off. When boost is updated (if there is a so name change) then everything that depends on it *will* be rebuilt whether or not there was an upgrade to those other packages. This is one of the things that release numbers are for.

exap · 2017-02-20 19:27:13

Got it! Thanks very much folks

eschwartz · 2017-02-21 23:09:32

Well, it seems a lot of people have misunderstood the phrase "assuming the package itself has an upgrade".
The "package" (*.pkg.tar.xz files generally synced via repos, and having a form similar to "pacman 5.0.1-4") can be upgraded by either a pkgver update (upstream version release) or by a pkgrel update (distro rebuild). Either one is what pacman considers a "package upgrade".

That statement was my mildly sarcastic way of saying, what is this "a package doesn't get upgraded, when it's dependency is" nonsense -- a package can get upgraded whenever the Arch maintainer feels like uploading an upgrade... for example, when one of its dependencies is upgraded in such a manner that the package needs to be relinked against new shared libraries.

Arch Linux

#1 2017-02-20 02:19:45

Avoid "error while loading shared libraries" after dependency upgrade

#2 2017-02-20 03:47:24

Re: Avoid "error while loading shared libraries" after dependency upgrade

#3 2017-02-20 14:26:41

Re: Avoid "error while loading shared libraries" after dependency upgrade

#4 2017-02-20 14:36:11

Re: Avoid "error while loading shared libraries" after dependency upgrade

#5 2017-02-20 14:48:24

Re: Avoid "error while loading shared libraries" after dependency upgrade

#6 2017-02-20 18:05:22

Re: Avoid "error while loading shared libraries" after dependency upgrade

#7 2017-02-20 18:14:28

Re: Avoid "error while loading shared libraries" after dependency upgrade

#8 2017-02-20 18:21:09

Re: Avoid "error while loading shared libraries" after dependency upgrade

#9 2017-02-20 18:25:25

Re: Avoid "error while loading shared libraries" after dependency upgrade

#10 2017-02-20 19:27:13

Re: Avoid "error while loading shared libraries" after dependency upgrade

#11 2017-02-21 23:09:32

Re: Avoid "error while loading shared libraries" after dependency upgrade

Board footer