cmake PG should ensure correct libdir, otherwise ports are broken on linux

Fred Wright fw at fwright.net
Tue Sep 17 19:20:10 UTC 2024


On Tue, 17 Sep 2024, Ken Cunningham wrote:

> In my PPC Debian world, my 64-bit installation of Debian PPC is quite 
> able to run 32 bit software.
>
> Linux does this by putting the libraries into lib64 or lib32 subfolders, 
> as Linux does not use "Fat binaries".
>
> So if you go down this road with MacPorts, then presumably that ability 
> will be lost as there will be only one library folder.
>
> Whether MacPorts will ever meaningfully support Linux and whether anyone 
> who does will ever care about running 32 bit software on it is another 
> question.

What I think is being missed here is that, on Linux (and maybe BSD as 
well), after installing libraries, one needs to rerun ldconfig to update 
the cache of library locations.  Otherwise the libraries won't be found. 
I believe all Linux package managers do this after installing packages, so 
it's automatic unless you're building your own libraries from source. 
Binary-based package managers probably only do this once per run, but 
source-based pacakge managers would need to do it after each package is 
installed, to ensure that potential dependents in the same run see any new 
libraries.

For consistency, it would make sense for Linux Macports to do something 
similar, in this case following each activation.  Thus, after each 
activation, it should:

1) Check for the existence of ldconfig (out of paranoia).

2a) If it doesn't exist, print a warning to that effect.

2b) If it does exist, print a message that it's running it and do so.

3) If it fails, print an error.

In the meantime, the problem can be worked around by only operating on 
ports one at a time, and manually running ldconfig after each activation.

Fred Wright


More information about the macports-dev mailing list