Run ldconfig for a library package

Poisson Aerohead · 2023-08-08 00:01:29

Hi, this may be a bit noobish to ask, but I am installing an open source math tool onto my machine. I always install everything that goes somewhere other than my home directory via a pacman package for ease of tracking and removal. I am trying to get the conventions right for shared libraries.

I gave the executable a real name as described here. My understanding is that running ldconfig will add the "soname" as a symlink. I can then add the linker name myself with ln -s.

I have found this example from the Archlinux glibc package. I can see how there is a post_upgrade() function that theoretically is calling ldconfig (I am not quite sure what the "-r ." argument to change the root is for). The file glibc.install is referred to in the PKGBUILD during the package_glibc() function by install=glibc.install, but I do not see any other usage in the file.

I guess my question is how I get the install scripts into the package and get them to run upon installation? In particular, what is best practices for the packaging and installation of a shared library? Lastly, what is the best way to get the linker name set up after installation? I figured out how to parse the Major.Minor from the pkgver variable, but then realized that pkgver is defined for makepkg run time, not pacman run time.

I guess I have experience with using makepkg to make a package for myself, but I have never needed to modify any of the default behavior, so I don't know how to get pacman to do things like run ldconfig or set up certain symlinks.

Thank you for any help.

Trilby · 2023-08-08 00:16:01

I think you're asking all the wrong questions and approaching this completely wrong.

Your makefile (or similar build tools) creates the library and any links to it. That's it. The soname is embeded in the libary by the linker at compile time (well, link time really). This would typically also then be used as the file name for that library.

The major / minor version numbers are determined by the software itself, not the PKGBUILD. These would typically be the first components in the package version, but these come from the upstream source to be used in the package version, not vice versa.

What library are you trying to package?

Last edited by Trilby (2023-08-08 00:19:18)

Poisson Aerohead · 2023-08-08 00:47:35

Trilby wrote:

Your makefile (or similar build tools) creates the library and any links to it. That's it.

OK, I certainly can do that. I know it is a bit dated, but I was referring to the linked description given at TLDP. This seemed to complicate things a bit. Age aside, the fact that the Archlinux glibc package is running ldconfig does support what TLDP says somewhat.

That said, I can certainly have the makefile put all the symlinks in place and skip any post installation hooks (ldconfig or otherwise). I already know how to do that. I was curious whether this was considered bad form or not.

Trilby · 2023-08-08 01:46:56

I can't speak to why that command is used in glibc's post install script, but why are you focused on that singular example? Look at pretty much any other library package and you will not see that. That is not a standard requirement / expectation of packaging libraries.

Allan · 2023-08-08 01:59:08

Glibc is special and needs ldconfig run immediately so that any new processes use the new cache.

For all other libraries, pacman handles this.

Poisson Aerohead · 2023-08-08 17:08:33

I'm not really focusing on it, I was searching for "pacman ldconfig" and that is what I found. Like I said, everything is easier if I can have my Makefile handle generating the symlinks. What is described at TLDP is a bit confusing,

Does pacman always know to run ldconfig, or is there something I have to do during packaging to cause that to happen?

loqs · 2023-08-09 19:04:04

Poisson Aerohead wrote:

Like I said, everything is easier if I can have my Makefile handle generating the symlinks.

There will be no issues with doing that.

Poisson Aerohead wrote:

Does pacman always know to run ldconfig, or is there something I have to do during packaging to cause that to happen?

Nothing needs to be done during packaging and nothing special in the PKGBUILD.

roxdio · 2024-12-07 15:20:29

I'm tagging on to this topic to ask a closely-related point (apologies if this is not appropriate):

I've built a package by writing my own PKGBUILD file and running makepkg -i. It's installed and registered in the pacman database. But when I tried to run it, I got an error relating to a missing library that had to be fixed by manually creating a symlink in /usr/lib/.

If I understand the discussion above correctly, pacman generally takes care of this by running ldconfig.

But since I used makepkg -i, do I have to manually run ldconfig to correctly make all the necessary symlinks?

seth · 2024-12-07 15:41:55

ldconfig will not generate *random* symlinks. It just sanitizes the geometry
"libfoo.so -> libfoo.so.1 -> libfoo.so.1.12"

Trilby wrote:

Your makefile (or similar build tools) creates the library and any links to it.

What's the ldd output on your executable and what exact symlink do you have to create?
But in doubt you'll have to create that symlink w/ the build/intall instructions of the PKGBUILD to install it with the package.

roxdio · 2024-12-07 16:39:47

Hello again. This is for my build of Emacs, and the issue in particular is the libtree-sitter library.

Emacs looks for a link called libtree-sitter.so.0, but it seems that the libtree-sitter library maintainers only create a link called libtree-sitter.so. This caused Emacs to not run until I manually created the symlink libtree-sitter.so.0 in the /usr/lib directory.

Before I created the symlink, running ldd /usr/bin/emacs | grep 'tree-sitter' gives:

libtree-sitter.so.0 => /usr/lib/libtree-sitter.so.0 (0x00007f7bd0272000)

After I ran #ln -s /usr/lib/libtree-sitter.so.0.24 /usr/lib/libtree-sitter.so.0, running ldd /usr/bin/emacs | grep 'tree-sitter' gives

libtree-sitter.so.0.24 => /usr/lib/libtree-sitter.so.0.24 (0x00007fa877f44000)

Running ldconfig -p | grep 'tree-sitter' gives

libtree-sitter.so.0.24 (libc6,x86-64) => /usr/lib/libtree-sitter.so.0.24
libtree-sitter.so (libc6,x86-64) => /usr/lib/libtree-sitter.so

seth · 2024-12-07 16:59:11

Arguebly a bug in https://archlinux.org/packages/extra/x8 … ee-sitter/ but I don't understand how libtree-sitter.so.0 can be resolved to /usr/lib/libtree-sitter.so.0 *before* you create that symlink and /usr/lib/libtree-sitter.so.0 doesn't even exist? Or why the emacs build links to a non-existing library intea of yelling an error at you.

I assume this is a spolied build environment where you've created that symlink but it's oc not present anywhere else?
Do you have the same problem when https://wiki.archlinux.org/title/Develo … ean_chroot ?

roxdio · 2024-12-07 17:25:02

No I didn't build the package in a clean chroot. ()My machine is also rather old and I am not sure I want to rebuild Emacs again to check ...)

I have also been told by the Emacs maintainers that

Emacs looks for libtree-sitter.so.0 in the system's directory where shared libraries are kept. So when you install a newer version of the library, you need to make sure the symlink by that name points to that newer version.

Actually I have slightly mis-stated the problem in my earlier post, and maybe have realized why the linking didn't happen properly, if you can confirm something for me.

So even *before* I installed my new build of Emacs (v 29.4), the previous version of Emacs (29.1) would not open after libtree-sitter was upgraded from 0.23.0-1 to 0.24.3-1. I got the error

emacs: error while loading shared libraries:
libtree-sitter.so.0: cannot open shared object file: No such file or directory

Now, the older version of Emacs was not installed in the proper Arch way and used a very minimal pseudo-PKGBUILD to register the build in pacman, which did not register the package dependencies. (I have since learned how to do things better.)

So here is my question which *might* resolve this:

If I had properly registered libtree-sitter as a dependency when installing the old version of Emacs, would pacman/ldconfig have automatically created the symlink libtree-sitter.0 -> libtree-sitter.0.24 when tree-sitter was updated?

seth · 2024-12-07 17:37:24

Hold on.
treesitter-0.23.0 did have libtree-sitter.so.0 - did you build emacs against that version, updated, ran into the missing lib and fix that w/ a symlink?

The proper response would have been to rebuild emacs.
I cannot say why the so.0 was removed, but the current https://archlinux.org/packages/extra/x86_64/emacs/ explicitly depend on libtree-sitter.so=0.24-64

You want to file a bug against tree-sitter. Maybe this is just an oversight, but the so.0 could also have been removed for ABI incompatibility and in that case you need to rebuild emacs to not run into weird errors/crashes.

roxdio · 2024-12-07 18:13:54

treesitter-0.23.0 did have libtree-sitter.so.0 - did you build emacs against that version, updated, ran into the missing lib and fix that w/ a symlink?

Yes -- or at least, an earlier version of tree-sitter.

The proper response would have been to rebuild emacs.

The upgrade to tree-sitter happened before I updated Emacs. So after making the symlink I did rebuild the new version of Emacs (29.4) against the newer version of libtree-sitter (0.24.3-1) and everything seems to work now.

In fact, what prompted me to look at ldconfig was that someone raised it in a post I made about whether I had to rebuild Emacs every time tree-sitter upgraded, or if I could just change the symlink. I guess you are suggesting the former which others have also mentioned -- it was just one response I got that said that ldconfig would handle this sort of thing.

You want to file a bug against tree-sitter. Maybe this is just an oversight, but the so.0 could also have been removed for ABI incompatibility and in that case you need to rebuild emacs to not run into weird errors/crashes.

My general sense is that the Emacs community have not had the best of experiences dealing with the tree-sitter devs. I did find a comment that said I should rebuild because

yes, it's Treesitter upstream policy.
they don't want a stable api or abi, and so here we are.

and someone else added

Every dynamic libraries ideally. It just happens average c programmers are very competent and keep the compatibility but not the treeshitter devs. It's safer to do so with libgccjit as well. I use neither of them. It's just awful.

Last edited by roxdio (2024-12-07 18:16:48)

seth · 2024-12-07 21:17:04

competent and keep the compatibility but not the treeshitter devs

Allthough he's probably an emacs user, I kinda like that guy

Under these circumstances the tight version bound of the repo build is probably not an accident and you certainly should rebuild emacs against treeshitter 0.24 (w/o the so.0 symlink) - ldconfig does not "fix" library version incompatibilities.

Fwwi, the normal procedure is to increment the first number when breaking API/ABI, ie. it should™ be libtreeshitter.so.24 - not libtreeshitter.so.0.24

roxdio · 2024-12-08 00:45:19

Yep, it does not seem like there is much love lost between these two groups ...

Thanks for your help. It will be slightly annoying to re-build so often, but it looks as though Emacs is the only package I use that requires it, so perhaps I can just add it to the ignore list and drag the upgrade cycle to more than a couple of months.

Arch Linux

#1 2023-08-08 00:01:29

Run ldconfig for a library package

#2 2023-08-08 00:16:01

Re: Run ldconfig for a library package

#3 2023-08-08 00:47:35

Re: Run ldconfig for a library package

#4 2023-08-08 01:46:56

Re: Run ldconfig for a library package

#5 2023-08-08 01:59:08

Re: Run ldconfig for a library package

#6 2023-08-08 17:08:33

Re: Run ldconfig for a library package

#7 2023-08-09 19:04:04

Re: Run ldconfig for a library package

#8 2024-12-07 15:20:29

Re: Run ldconfig for a library package

#9 2024-12-07 15:41:55

Re: Run ldconfig for a library package

#10 2024-12-07 16:39:47

Re: Run ldconfig for a library package

#11 2024-12-07 16:59:11

Re: Run ldconfig for a library package

#12 2024-12-07 17:25:02

Re: Run ldconfig for a library package

#13 2024-12-07 17:37:24

Re: Run ldconfig for a library package

#14 2024-12-07 18:13:54

Re: Run ldconfig for a library package

#15 2024-12-07 21:17:04

Re: Run ldconfig for a library package

#16 2024-12-08 00:45:19

Re: Run ldconfig for a library package

Board footer