On Mon, Jun 30, 2014 at 8:49 PM, Sarah Graves <[log in to unmask]> wrote:

Hi All,

I ran into an error in the JAC Mac OSX mavericks stardev build that I was hoping someone on the list might have some insight into.

In the past, we weren't building and shipping libjpeg on our JAC MacOSX starlink builds, and the OSX build machines here all had that library installed locally as a dependency instead. Changes to the build system this year mean that libjpeg is now correctly built on the OSX builds if it is not already present. I therefore removed the homebrew install of libjpeg from our mavericks build machine, and libjpeg is now being correctly built.

Unfortunately however, it turns out that having libjpeg.dylib in /stardev/lib (which is in our DYLD_LIBRARY_PATH after sourcing starlink) causes java to break.

The error message you get is as follows:

poma:~ jenkins$ topcat
Error occurred during initialization of VM
Unable to load native library: libjava.jnilib

The DYLD_LIBRARY_PATH is set to:
/stardev/lib:/stardev/starjava/lib/i386:/stardev/starjava/lib/x86_64

If I manually remove libjpeg.dylib from /stardev/lib, then java appears to work fine and topcat and splat load up quite happily.

Similarly, if I unset the DYLD_LIBRARY_PATH then java appears to be fine (although we then can't run the starlink commands).

Does anyone on the list have any good ideas on the best way to work around this problem?

See ticket 1: https://github.com/Starlink/starlink/issues/1

Fixing up the binaries so that we do not need to set DYLD_LIBRARY_PATH is by far the best option. I was hoping that the autotools upgrade would make this feasible so that we could use "@rpath" in the -r linker option. This would make Starlink properly relocatable.

Secondly, it's probably true that we should link against the Apple imaging frameworks but I'm not sure how to handle the -framework linker option in autotools.

Tim Jenness