[gentoo-dev] Re: Slotted Lua + revdeps to be unmasked on Christmas Eve

[Jonathan Callen]

On 12/23/20 9:10 AM, Michael Orlitzky wrote:
> 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.
>
>

One way this could be done without breaking things might be to create a
subdirectory of /usr/$(get_libdir) for each version of Lua and creating
a liblua.a and/or liblua.so symlink in that directory pointing to the
liblua${VERSION}.* file in /usr/$(get_libdir).  Then you could simply
point those build systems at that directory and they would still use the
correct version.  As a hack in an ebuild, you probably could just create
such a setup in (subdirectories of) ${T}, pointing liblua.a, liblua.so,
and lua.pc at the appropriately-versioned files.

Jonathan Callen