On Feb 25, 2011, at 7:20 AM, Brad Cavanagh wrote:
> On Fri, Feb 25, 2011 at 5:36 AM, Dr M J Carter <[log in to unmask]> wrote:
>>> 9784 (timj):
>>> jni: Rebuild the OSX 64-bit libraries so that they use -install_name
>>>
>>> The JNI libraries on OSX were built with the build path burned in as
>>> the install name. This was preventing SPLAT from loading its JNI
>>> library because it depends on libjniast. At build time libsplat was
>>> configured to load libjniast from the jniast build directory and
>>> for all except the person building SPLAT this directory was not
>>> present.
>>>
>>> Now force -install_name of JNI libraries to be the actual
>>> installed name (/star/starjava/lib/$arch/libx.jnilib). SPLAT
>>> now seems to load properly.
>>
>> Rats: Does this mean we have to maintain the otherwise-redundant /star
>> symlink, or roll our own builds? That would be an entire nuisance on
>> setups such as ours, where we've given the users the ability to select
>> which of two or more Starlink builds to use at runtime by (indirectly)
>> setting ${STARLINK_DIR} appropriately.
>
> The behaviour you're describing (being able to set $STARLINK_DIR to
> point to different releases) never worked on OS X because the
> compilation hard-wired the location of e.g. libraries. The patch looks
> like a) it only affects the Java libraries on OS X, and b) fixes a bug
> where the hard-wired location was actually pointing to the wrong place
> instead of /star.
>
Correct. This was OSX only. The problem on OSX is that all our libraries are built knowing where they were installed and the binaries are built to look in an absolute location. It seems that when a full path is given to the linker it never uses DYLD_LIBRARY_PATH to locate the library so we can't relocate on OSX.
I think the real fix is to use @rpath and @loader_path as described in http://www.codeshorts.ca/tag/osx/
Binaries would be created with -rpath @loader_path/../lib or -rpath @loader_path/../../lib for monoliths. Shared libraries would be created with -install_name @rpath/libxxx.dylib
I'm not sure how to modify the autoconf system to make this happen though.
Maybe it will be easier to strip all paths and force DYLD_LIBRARY_PATH to be used.
--
Tim Jenness
Joint Astronomy Centre
