1 |
On 12/23/20 12:13 PM, Jonathan Callen wrote: |
2 |
> On 12/23/20 9:10 AM, Michael Orlitzky wrote: |
3 |
>> On 12/23/20 8:35 AM, Jaco Kroon wrote: |
4 |
>>> Michael, |
5 |
>>> |
6 |
>>> I'm busy disecting what Marek has done for asterisk as I need to make |
7 |
>>> that work for multiple versions of net-misc/asterisk-16.14.0-r100, not |
8 |
>>> merely the one he did it for - perhaps that would be helpful for you as |
9 |
>>> well? |
10 |
>>> |
11 |
>>> I don't know lua at all. |
12 |
>>> |
13 |
>>> Anyway, I'm on IRC as jkroon if you'd like to exchange notes. I don't |
14 |
>>> particularly like the patch Marek did as I'll NEVER be able to push that |
15 |
>>> upstream. The patch will work for us, but as a policy I highly prefer |
16 |
>>> patches which I can get unstreamed such that we don't need to carry them |
17 |
>>> more than one or two versions. |
18 |
>> |
19 |
>> Agreed. This is more of a system library packaging issue than anything |
20 |
>> to do with Lua specifically. |
21 |
>> |
22 |
>> |
23 |
>>> I'd prefer to patch upstream to keep it's behaviour of detecting a lua |
24 |
>>> version, but have a --with-lua(version)? type argument that can take an |
25 |
>>> optional argument which will then be the version, but --with-* generally |
26 |
>>> takes a prefix where the include and lib folders can be found ... and |
27 |
>>> I'd prefer to depend on pkg-config as primary and fallback to the |
28 |
>>> ./configure mess which tries to guess at things ... |
29 |
>>> |
30 |
>> |
31 |
>> This is exactly what I'm trying to get across. Support for multiple |
32 |
>> versions of libraries in weird locations is not a new thing. Generally, |
33 |
>> you can put CPPFLAGS="-I/foo/bar" and LIBS="-L/baz/quux" before running |
34 |
>> ./configure and everything will just work with your header files and |
35 |
>> libraries in the non-standard paths /foo/bar and /baz/quux, |
36 |
>> respectively. Those paths take precedence over the defaults (if used |
37 |
>> correctly...), so you can use them to override the default version of a |
38 |
>> library and compile/link against a specific copy if you need to do that. |
39 |
>> Likewise, one could prepend a path to PKG_CONFIG_PATH to override the |
40 |
>> version that will be detected via pkg-config. |
41 |
>> |
42 |
>> The problem that we've gotten ourselves into is that we've copied Debian |
43 |
>> by not only relocating the library, but renaming it (and its *.pc file) |
44 |
>> entirely. There is no good way to tell an autotools build system that |
45 |
>> you've renamed a library completely, and that it should prefer the |
46 |
>> renamed version over the standard one if the standard one also exists. |
47 |
>> |
48 |
>> If you want to build against the eselected version of Lua on Gentoo, |
49 |
>> then eselect-lua makes everything OK. It creates symlinks from the |
50 |
>> standard names to the nonstandard ones, and everything just works. But |
51 |
>> if you want to build against a specific, not-eselected version of Lua? |
52 |
>> You have to tell the build system what to do. The eselected version |
53 |
>> lives in the correct locations (via those symlinks), so the build system |
54 |
>> is going to want to find that first. If the eselected version is not the |
55 |
>> one you want to build against,.... oops. Then, since the version you |
56 |
>> *do* want to link against has the wrong name, you have to tell the build |
57 |
>> system to link against it somehow. You can't simply override the |
58 |
>> PKG_CONFIG_PATH, because our *.pc files have the wrong names. You can't |
59 |
>> just override the library search path, because our libraries have the |
60 |
>> wrong names. |
61 |
>> |
62 |
>> The work I've done so far for OpenDKIM does nothing to address these |
63 |
>> larger problems. If lua.pc is on the system, it will get used first, |
64 |
>> regardless of the version you actually want to build against. AFAIK |
65 |
>> there's no good way around this without patching. |
66 |
>> |
67 |
>> If the libraries (and pkg-config files?) were installed to |
68 |
>> subdirectories instead, then the standard method of overrides could be |
69 |
>> used to build against a specific version, rather than requiring every |
70 |
>> upstream build system to support our weird layout. |
71 |
>> |
72 |
>> |
73 |
> |
74 |
> One way this could be done without breaking things might be to create a |
75 |
> subdirectory of /usr/$(get_libdir) for each version of Lua and creating |
76 |
> a liblua.a and/or liblua.so symlink in that directory pointing to the |
77 |
> liblua${VERSION}.* file in /usr/$(get_libdir). Then you could simply |
78 |
> point those build systems at that directory and they would still use the |
79 |
> correct version. As a hack in an ebuild, you probably could just create |
80 |
> such a setup in (subdirectories of) ${T}, pointing liblua.a, liblua.so, |
81 |
> and lua.pc at the appropriately-versioned files. |
82 |
> |
83 |
> Jonathan Callen |
84 |
> |
85 |
|
86 |
I've recently had the same problem for TACC/Lmod which uses |
87 |
autotools to get lua versions and lua.cpath and lua.path and did infact manage |
88 |
to push the horrendously large patch upstream - |
89 |
https://github.com/TACC/Lmod/commit/0913bf05dd7e8f478f69d5297e26d744ddb5073a |
90 |
|
91 |
Maybe something similar can work for your use case? |
92 |
|
93 |
The problem with just using -L/path/to/lua/lib/ -llua would be loading |
94 |
library at runtime, unless autotools is smart enough to actually change this |
95 |
CFLAGs into a -Wl,-rpath,/path/to/lua/lib -L/path/to/lua/lib -llua. |
96 |
I am not sure how intelligent autotools is to be able to do this or not. |
97 |
|
98 |
Aisha |