Updating a SO library from source that was originally installed by a package manager

Issues related to applications and software problems
Post Reply
sawozny
Posts: 48
Joined: 2019/07/13 22:19:14

Updating a SO library from source that was originally installed by a package manager

Post by sawozny » 2020/07/04 23:52:55

Dear CentOS Gurus,

OK, so the situation is that I need to update gpgme on my CentOS 7 minimal install to 1.4.3 or higher (project is currently at 1.13). If you’re curious why, see here: https://community.greenbone.net/t/probl ... mal/5854/3 The most advanced CentOS 7 repo verison of this is 1.3.2-5 which is what’s on the system I’m working with.

So my main question is, how do I update this application / library “properly” from source (or, in the absence of a “proper” answer, in the way that does the least long-term damage)? Keep in mind it’s not just the so I need. Since I’m compiling against it I need the “devel” version with the .h file in the include directory. This new version of gpgme also has a further dependencies of libassuan 2.5.3 (2.1.0-3 current) which has dependency on libgpg-error 1.38 (1.12-3 current), so whatever the answer is to this, it needs to be recursive.

If this was packaged (it is for CentOS 8, just not CentOS 7) I would simply add the repo and update, but I can’t find one (atomic offers their version of gpgme 1.12.0, but then I’d have 2 versions of libgpgme and I don’t know enough about how shared objects work under the hood to figure out how I would untangle that mess, let alone teach the compiler how to choose the correct header file and library).

If this was originally installed from source, then I would simply follow the same process and rely on the installer to keep things straight and overwrite as needed. However with libgpgme installed in the base install (the repo for the package is @anaconda) when I try to remove it (to install from source), it shows eventual dependencies back to yum which I cannot remove so it’s stuck as-is on any CentOS 7 install. Or is it? Could the source installer be smart enough to properly upgrade the SOs and the headers and I’m just SUPER over-thinking this? If I “break” the RPM / Yum package so I can’t upgrade it again, but the library (and headers) work for my compilation and build I would probably be OK with that.

So, any suggestions on the least disruptive way to install more up to date so libraries from source over a yum / RPM installed package? If I just barrel ahead with the install from source, is there some “cleanup” effort I need to do afterwards? In other words, how can I make sure the so and .h files from the updated version are the ones the compiler and linker will refer to?

Apologies if my questions are sort of noob-ish but I don’t have a very solid understanding of how SOs work under the hood. If anyone has any good links on resources to better understand how these components (SOs, header files, compilers / builders / linkers and package managers) interrelate so I can figure this out on my own I would love to see those, too, but I haven’t been able to find anything particularly illuminating in my googling.

Any suggestions or assistance would be appreciated.

Thanks,

Scott

P.S. Why do the library version numbers on the SO files seem to have nothing to do with the package numbering? Gpgme.x86_64 v1.3.2-5.el7 provides libgpgme.so.11.8.1. Anyone have a link to a good article on SO versioning as it relates to package number versioning (or is there absolutely no correlation and I just need to come to peace with this)?

P.P.S. Those links to from ldNAME.so to ldNAME.so.X and ldNAME.so.X.Y. When / how / who generates those? Will this impact my update process in any way or is that all handled by the installer? Anyone have a good article?

chemal
Posts: 776
Joined: 2013/12/08 19:44:49

Re: Updating a SO library from source that was originally installed by a package manager

Post by chemal » 2020/07/05 04:05:35

You cannot update system libraries. Especially not those that are already present in a minimal install. Period.

Shared libraries have an SONAME compiled into the library, something like libfoo.so.5. The SONAME reflects the available functionality and the ABI, not the software version.

Installing this library might give you:

/usr/lib64/libfoo.so -> libfoo.so.5.8
/usr/lib64/libfoo.so.5 -> libfoo.so.5.8
/usr/lib64/libfoo.so.5.8

The first link is picked up by the linker if you compile something from source. The SONAME is what your executable will depend on. The dynamic linker will look for it if you run your program and follow the second link.

If you want to build something from source that requires a more recent version of a library than what the system provides, you can try to first build a static version of this library and then compile your code against that. Of course, you don't install the static version of the library and the headers into the system but somewhere close to your build directory.

Post Reply