Re: [gentoo-dev] Slotted Lua + revdeps to be unmasked on Christmas Eve
On 12/23/20 6:18 PM, Michael Orlitzky wrote: Using pkg-config has a related problem. If lua-5.1 is eselected and if the upstream build system runs $(pkg-config ... lua), it's going to get the information for lua-5.1, even if you're trying to build against lua-5.2. So, first I have to patch upstream to use pkg-config, and then I have to hack it in Gentoo to avoid using pkg-config. Sorry, I was wrong about this. Patching the upstream build system to support pkg-config does work if you use the eclasses.
Re: [gentoo-dev] Slotted Lua + revdeps to be unmasked on Christmas Eve
On 12/23/20 4:51 PM, Mart Raudsepp wrote: Ühel kenal päeval, K, 23.12.2020 kell 07:49, kirjutas Michael Orlitzky: AC_SEARCH_LIBS([whatever], [lua], [lua_found="yes"]) How do I pass the name "lua5.2" to that, without hacking configure.ac and running autoreconf? The only option that comes to mind is to build the entire project with LIBS="-llua5.2", but that's not right if only some of the executables are supposed to be linked with lua. You either fix upstream to use pkg-config, or you set up the cache variable for your configure call to tell configure what the answer is, without making it do the work wrong. Using pkg-config has a related problem. If lua-5.1 is eselected and if the upstream build system runs $(pkg-config ... lua), it's going to get the information for lua-5.1, even if you're trying to build against lua-5.2. So, first I have to patch upstream to use pkg-config, and then I have to hack it in Gentoo to avoid using pkg-config. Overriding the cached check variable does work, but you have to override every single call to AC_SEARCH_LIBS(function...) with ac_cv_search_ which depends highly on the implementation details of configure.ac. This is roughly as invasive and hard to maintain as patching, and should just not be the default way to link against a library IMO.
Re: [gentoo-dev] Slotted Lua + revdeps to be unmasked on Christmas Eve
Ühel kenal päeval, K, 23.12.2020 kell 07:49, kirjutas Michael Orlitzky: > AC_SEARCH_LIBS([whatever], [lua], [lua_found="yes"]) > > How do I pass the name "lua5.2" to that, without hacking configure.ac > and running autoreconf? The only option that comes to mind is to > build > the entire project with LIBS="-llua5.2", but that's not right if only > some of the executables are supposed to be linked with lua. You either fix upstream to use pkg-config, or you set up the cache variable for your configure call to tell configure what the answer is, without making it do the work wrong. Should be ac_cv_search_whatever=something in this case. sys-apps/grep ebuild has an example. I'm not sure what package this is to look or test closer. It doesn't appear to be OpenDKIM which is discussed in this thread elsewhere. Mart signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Slotted Lua + revdeps to be unmasked on Christmas Eve
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.
Re: [gentoo-dev] Slotted Lua + revdeps to be unmasked on Christmas Eve
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. 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 ... Kind Regards, Jaco On 2020/12/23 14:49, Michael Orlitzky wrote: > On 12/23/20 4:09 AM, Marek Szuba wrote: >> >> I think what you are looking for is lua_get_shared_lib() from >> lua-utils.eclass. We have already got ebuilds in the tree which use >> it. >> > > Knowing the library name only helps if I patch the build system; > that's what I'm getting at. The few packages where this works use > CMake, and CMake already tries to guess[0] the name of the lua library > (thanks Debian) and so it has a pre-defined variable to store the result. > > Not all build systems are going to work like that. Suppose I know that > the name of the lua library is "lua5.2". An autotools build system is > going to run something like, > > AC_SEARCH_LIBS([whatever], [lua], [lua_found="yes"]) > > How do I pass the name "lua5.2" to that, without hacking configure.ac > and running autoreconf? The only option that comes to mind is to build > the entire project with LIBS="-llua5.2", but that's not right if only > some of the executables are supposed to be linked with lua. > > For contrast, if the lua library was stored in /usr/lib64/lua5.2, then > I could just set LIBS="-L/usr/lib64/lua5.2" and let ./configure do its > thing. > > > [0] https://github.com/Kitware/CMake/blob/master/Modules/FindLua.cmake >
Re: [gentoo-dev] Slotted Lua + revdeps to be unmasked on Christmas Eve
On 12/23/20 4:09 AM, Marek Szuba wrote: I think what you are looking for is lua_get_shared_lib() from lua-utils.eclass. We have already got ebuilds in the tree which use it. Knowing the library name only helps if I patch the build system; that's what I'm getting at. The few packages where this works use CMake, and CMake already tries to guess[0] the name of the lua library (thanks Debian) and so it has a pre-defined variable to store the result. Not all build systems are going to work like that. Suppose I know that the name of the lua library is "lua5.2". An autotools build system is going to run something like, AC_SEARCH_LIBS([whatever], [lua], [lua_found="yes"]) How do I pass the name "lua5.2" to that, without hacking configure.ac and running autoreconf? The only option that comes to mind is to build the entire project with LIBS="-llua5.2", but that's not right if only some of the executables are supposed to be linked with lua. For contrast, if the lua library was stored in /usr/lib64/lua5.2, then I could just set LIBS="-L/usr/lib64/lua5.2" and let ./configure do its thing. [0] https://github.com/Kitware/CMake/blob/master/Modules/FindLua.cmake
Re: [gentoo-dev] Slotted Lua + revdeps to be unmasked on Christmas Eve
On December 23, 2020 2:56:05 AM UTC, Michael Orlitzky wrote: >One last design issue that I ran into during the migration. > >The slotted lua ebuilds install the headers into subdirectories like >/usr/include/lua5.2, but otherwise with their upstream names. The >libraries, on the other hand, all get installed directly to $libdir.. >but with NON-standard names like liblua5.2.a (as opposed to simply >liblua.a). > >This makes it impossible to build against a specific version of Lua >without using pkg-config. The usual way would be to add >/usr/include/lua5.2 to the compiler's include path, and $libdir/lua5.2 >to its library path (via -I and -L)... but there's no way to tell the >build system to look for a library of an entirely different name. >Things >like AC_SEARCH_LIBS are going to try -llua, and that's it. I think what you are looking for is lua_get_shared_lib() from lua-utils.eclass. We have already got ebuilds in the tree which use it. -- MS
Re: [gentoo-dev] Slotted Lua + revdeps to be unmasked on Christmas Eve
On 12/22/20 6:15 PM, Marek Szuba wrote: > Dear all, > > As of right now, the blocking slotted-lua tracker depends on 5 (FIVE) open > bugs. The still-to-be migrated packages are: > > app-metrics/collectd - ebuild under review of the maintainer > games-strategy/megaglest - no response from maintainers (games@g.o) > mail-filter/opendkim - committed ebuild needs one extra fix > sci-geosciences/osm2pgsql - no response from maintainers (sci-geo@g.o) > www-apps/cgit - to be migrated by bman > > Therefore, the unmasking of slotted Lua + all the ebuilds migrated to Lua > eclasses will take place on Christmas Eve, i.e. this Thursday, around noon > UTC. > > -- > Marecki Congratulations marecki@ ! Thanks for all your work (and also others, conikost, williamh, others who I am forgetting :P). As with any large enough change, lets hope this works in a chirstmas miracle. :D Cheers, Aisha
Re: [gentoo-dev] Slotted Lua + revdeps to be unmasked on Christmas Eve
On 12/22/20 6:15 PM, Marek Szuba wrote: Dear all, mail-filter/opendkim - committed ebuild needs one extra fix One last design issue that I ran into during the migration. The slotted lua ebuilds install the headers into subdirectories like /usr/include/lua5.2, but otherwise with their upstream names. The libraries, on the other hand, all get installed directly to $libdir.. but with NON-standard names like liblua5.2.a (as opposed to simply liblua.a). This makes it impossible to build against a specific version of Lua without using pkg-config. The usual way would be to add /usr/include/lua5.2 to the compiler's include path, and $libdir/lua5.2 to its library path (via -I and -L)... but there's no way to tell the build system to look for a library of an entirely different name. Things like AC_SEARCH_LIBS are going to try -llua, and that's it.
