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.
Of course, I haven't been involved with Starlink in a year so I could
be completely off my rocker, but that's my best guess.
If you did manage to get redirection via setting $STARLINK_DIR working
on OS X, I'm sure Tim et al would be really interested to find out how
you did it.
Cheers,
Brad.
|