On 01-05-2009, at 02:06, Allin Cottrell wrote:
The script you gave was certainly helpful, thank you. But (just
to indicate the issues involved) it didn't cover use of
libreadline in gretlcli, or the possibility that the default
linkage of some of the libraries in question is to some
third-party location (e.g. /usr/local/lib or /sw/lib).
The script was made with information provided by otool -L on the gretl
I have compiled without fink and with R GTK.
I am linking to the MC OS X editline.dylib which works (I have had all
sorts of weird issues compiling and/or linking to readline caused by
Mac OS X using editline and not GNU readline).
Before I truly and finally get rid of DYLD_LIBRARY_PATH I have to
make sure that all such possibilities are covered.
Indeed. I traced all references manually with the aid of otool.
In trying to get rid of DYLD_LIBRARY_PATH, I encountered something
else which I don't understand.
I have the gfortran compiler from the R MAC OS X project installed.
It installs all its library stuff in /usr/local/lib including a
libgcc_s-1.dylib
The configure process of Gretl seems to include /usr/local/lib at the
head of a library search list.
This led to all libraries and executables using /usr/local/lib/
libgcc_s-1.dylib instead of simply the standard C /usr/lib/
libgcc_s-1.dylib.
I had to use install_name_tool to change the references to the
standard C dylib (dangerous but it works).
It appears that /usr/local/lib is already on the linker search list so
it wouldn't have to be included explicitly.
I haven't got a clue how to avoid that inclusion and would like some
enlightenment.
Berend