[Ifeffit] Athena 0.8.014
newville at cars.uchicago.edu
Tue Mar 4 11:05:01 CST 2003
Yes, the problem you're seeing is almost certainly due to the
debian PGPLOT package providing a shared library (libpgplot.so)
which the compiler sees at compile time but the loader cannot
find at run time. An easy way to check this (on linux, darwin,
and a few other unix-like systems) is to do
which will list all shared libraries this exe will try to load.
If the comiler has tried to use a shared library, it will be
listed. If the loader can find it, the actual path to the shared
library will be given. If it can't be found, that will be
stated, and the exe will fail when trying to use anything from
There are a few possible solutions. One option is to not use the
debian PGPLOT package, but use my PGPLOT_INSTALL instead. This
makes sure the shared object is deleted, so that ifeffit will
build with the static library. Another option is to copy the
shared object to somewhere it can be found by the system --
/usr/lib always works, and /usr/local/lib usually works too. A
final option is to tell the loader where to look for shared
objects. On linux, the list is in /etc/ld.so.conf. Edit this
file to include /usr/local/lib, and/or /usr/local/pgplot,
and then run /sbin/ldconfig.
You will probably also need to run ldd on
to make sure that these can see libpgplot.so as well.
It seems strange that Debian would distribute a PGPLOT package
that provides a shared-object in a place that does not work.
What other packages rely on the PGPLOT package? Do those work?
A positive aspect of all of this is that if Debian and Fink are
both distributing binary packages of PGPLOT, then I could
probably distribute my own PGPLOT binaries (say for linux and
darwin) to be used in the Ifeffit build process. That would be a
little bit of work, and there seem to be no volunteers, so it
won't happen immediately. Frankly, I view this as a low priority
compared to fixing the Mac OS X build issues.
More information about the Ifeffit