1 |
On Feb 10, 2011, at 11:26 AM, Michael Haubenwallner wrote: |
2 |
|
3 |
>>>>> Although runpath search is affected by LIBPATH, I'm just fine with that. |
4 |
>>>>> This is the outcome of using "-L" and "-l" linker flags together. |
5 |
>>>> I thought this was one of your objectives based on the fact that java sets LIBPATH |
6 |
>>>> to something weird and it breaks everything. |
7 |
>>> Nope. The problem with LIBPATH set by java was that there is nothing |
8 |
>>> like "soname". Iff my binary had searched for the /file/ "libiconv.so.2" |
9 |
>>> (either archive or not) instead of "libiconv.a(libiconv.so.2)", even with |
10 |
>>> LIBPATH set to "/usr/lib" it would not have found "/usr/lib/libiconv.a" |
11 |
>>> (without "libiconv.so.2" member), but continued along LIBPATH + runpath |
12 |
>>> until it found the "libiconv.so.2" file in its usual place. |
13 |
>> Hmmm... ok. I had forgotten that detail. |
14 |
> |
15 |
> Yes, a detail - but a really important one for package managers. |
16 |
|
17 |
It occurred to me that this was true in your particular situation but |
18 |
if Java (or a user) removes key paths from LIBPATH, the runtime |
19 |
search will fail. Having 100% hardcoded paths solves that issue. |
20 |
|
21 |
So, the system you have developed solves the particular issue |
22 |
with Java but not the bigger issue of setting LIBPATH to some |
23 |
whacko thing. |
24 |
|
25 |
Perry |