| 1 |
On 12/23/20 4:51 PM, Mart Raudsepp wrote: |
| 2 |
> Ühel kenal päeval, K, 23.12.2020 kell 07:49, kirjutas Michael Orlitzky: |
| 3 |
>> AC_SEARCH_LIBS([whatever], [lua], [lua_found="yes"]) |
| 4 |
>> |
| 5 |
>> How do I pass the name "lua5.2" to that, without hacking configure.ac |
| 6 |
>> and running autoreconf? The only option that comes to mind is to |
| 7 |
>> build |
| 8 |
>> the entire project with LIBS="-llua5.2", but that's not right if only |
| 9 |
>> some of the executables are supposed to be linked with lua. |
| 10 |
> |
| 11 |
> You either fix upstream to use pkg-config, or you set up the cache |
| 12 |
> variable for your configure call to tell configure what the answer is, |
| 13 |
> without making it do the work wrong. |
| 14 |
|
| 15 |
Using pkg-config has a related problem. If lua-5.1 is eselected and if |
| 16 |
the upstream build system runs $(pkg-config ... lua), it's going to get |
| 17 |
the information for lua-5.1, even if you're trying to build against |
| 18 |
lua-5.2. So, first I have to patch upstream to use pkg-config, and then |
| 19 |
I have to hack it in Gentoo to avoid using pkg-config. |
| 20 |
|
| 21 |
Overriding the cached check variable does work, but you have to override |
| 22 |
every single call to AC_SEARCH_LIBS(function...) with |
| 23 |
ac_cv_search_<function> which depends highly on the implementation |
| 24 |
details of configure.ac. This is roughly as invasive and hard to |
| 25 |
maintain as patching, and should just not be the default way to link |
| 26 |
against a library IMO. |
Archives