[Ifeffit] Athena 0.8.014

[Carlo U. Segre]

Matt:

I bit the bullet last night and made a stab at an IFEFFIT Debian package.
By the end of the evening (or beginning of the morning if you will) I had
two functioning, but certainly not complete packages of ifeffit for the
woody (stable) and sarge (testing) Debian distributions.  They do not, at
this point in time, include any of the wrappers (I have yet to figure out
how to do this) and are compile only for i386 architecture.  According to
Debian policy, they install in /usr rather than /usr/local.  They seem to
work with the latest installation of Athena and Artemis but I am still in
the process of testing them.

It should be possible to use the Debian alien program to comvert them to
RPMs as well.

I will keep you updated on my progress and when I am sure that they aren't
incredibly broken, I will be happy to make them available.

Carlo

On Tue, 4 Mar 2003, Matt Newville wrote:

> Hi Carlo,
>
> 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
>   ldd /usr/local/bin/ifeffit
>
> 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
> that library.
>
> 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
>
>   /usr/lib/perl5.6/..../auto/Ifeffit/Ifeffit.so
>   /usr/lib/python.../site-packages/Ifeffit/_ifeffit.so
>
> 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.
>
> --Matt
>
>

-- 
Carlo U. Segre -- Professor of Physics
Associate Dean for Research, Armour College
Illinois Institute of Technology
Voice: 312.567.3498            Fax: 312.567.3494
Carlo.Segre at iit.edu    http://www.iit.edu/~segre