On 12/23/20 8:35 AM, Jaco Kroon wrote:
Michael,
I'm busy disecting what Marek has done for asterisk as I need to make
that work for multiple versions of net-misc/asterisk-16.14.0-r100, not
merely the one he did it for - perhaps that would be helpful for you as
well?
I don't know lua at all.
Anyway, I'm on IRC as jkroon if you'd like to exchange notes. I don't
particularly like the patch Marek did as I'll NEVER be able to push that
upstream. The patch will work for us, but as a policy I highly prefer
patches which I can get unstreamed such that we don't need to carry them
more than one or two versions.
Agreed. This is more of a system library packaging issue than anything
to do with Lua specifically.
I'd prefer to patch upstream to keep it's behaviour of detecting a lua
version, but have a --with-lua(version)? type argument that can take an
optional argument which will then be the version, but --with-* generally
takes a prefix where the include and lib folders can be found ... and
I'd prefer to depend on pkg-config as primary and fallback to the
./configure mess which tries to guess at things ...
This is exactly what I'm trying to get across. Support for multiple
versions of libraries in weird locations is not a new thing. Generally,
you can put CPPFLAGS="-I/foo/bar" and LIBS="-L/baz/quux" before running
./configure and everything will just work with your header files and
libraries in the non-standard paths /foo/bar and /baz/quux,
respectively. Those paths take precedence over the defaults (if used
correctly...), so you can use them to override the default version of a
library and compile/link against a specific copy if you need to do that.
Likewise, one could prepend a path to PKG_CONFIG_PATH to override the
version that will be detected via pkg-config.
The problem that we've gotten ourselves into is that we've copied Debian
by not only relocating the library, but renaming it (and its *.pc file)
entirely. There is no good way to tell an autotools build system that
you've renamed a library completely, and that it should prefer the
renamed version over the standard one if the standard one also exists.
If you want to build against the eselected version of Lua on Gentoo,
then eselect-lua makes everything OK. It creates symlinks from the
standard names to the nonstandard ones, and everything just works. But
if you want to build against a specific, not-eselected version of Lua?
You have to tell the build system what to do. The eselected version
lives in the correct locations (via those symlinks), so the build system
is going to want to find that first. If the eselected version is not the
one you want to build against,.... oops. Then, since the version you
*do* want to link against has the wrong name, you have to tell the build
system to link against it somehow. You can't simply override the
PKG_CONFIG_PATH, because our *.pc files have the wrong names. You can't
just override the library search path, because our libraries have the
wrong names.
The work I've done so far for OpenDKIM does nothing to address these
larger problems. If lua.pc is on the system, it will get used first,
regardless of the version you actually want to build against. AFAIK
there's no good way around this without patching.
If the libraries (and pkg-config files?) were installed to
subdirectories instead, then the standard method of overrides could be
used to build against a specific version, rather than requiring every
upstream build system to support our weird layout.
