Re: [gentoo-alt] AIX linking adventure

[Michael Haubenwallner]

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

Well, having LIBPATH _set_ at all is calling for troubles anyway,
and is highly discouraged - not only within Gentoo Prefix.

But as Java is an IBM binary package I can't patch, and they add
/usr/lib:/lib only, this is no longer a problem for me now.

OTOH, when "libNAME.so.1" would be found somewhere else due to
LIBPATH being set, one should assume that this should be sufficient
too. This also allows for developers to try out a fix for libNAME.so.1
before needing to replace it at the final location.

But still, LIBPATH (as LD_LIBRARY_PATH in ELF) is for exceptional
circumstances only.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level