| 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 |
Archives