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