On 12/23/20 12:13 PM, Jonathan Callen wrote:
> 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
>
I've recently had the same problem for TACC/Lmod which uses
autotools to get lua versions and lua.cpath and lua.path and did infact manage
to push the horrendously large patch upstream -
https://github.com/TACC/Lmod/commit/0913bf05dd7e8f478f69d5297e26d744ddb5073a
Maybe something similar can work for your use case?
The problem with just using -L/path/to/lua/lib/ -llua would be loading
library at runtime, unless autotools is smart enough to actually change this
CFLAGs into a -Wl,-rpath,/path/to/lua/lib -L/path/to/lua/lib -llua.
I am not sure how intelligent autotools is to be able to do this or not.
Aisha
