psconfig needs to make sure all dependent libraries are found with exactly the required versions, even if multiple versions are floating around on the system

[jester@…]

Gautham Narayan reported this bug on ps-ipp users before at ​http://pan-starrs.ifa.hawaii.edu/mailman/private/ps-ipp-users/msg00495.html but the fix he got from Paul and forwarded me isn't working for me.

The real underlying bug is that psconfig doesn't seem to have a mechanism for making sure that only and exactly the required version of a required library is used for compilation and at runtime.

The problem is this: I am trying to compile with psbuild -dev -extbuild on a tree that I 'cvs export'ed from cvs head.

This has built cfitsio from the tarball I unpacked into psconfig/../../extlibs

It generates the following configure command for psLib:

./configure --prefix=/IPP/bleed.lin64 --bindir=/IPP/bleed.lin64/bin --libdir=/IPP/bleed.lin64/lib --mandir=/IPP/bleed.lin64/man --includedir=/IPP/bleed.lin64/include --sysconfdir=/IPP/bleed.lin64/etc --datadir=/IPP/bleed.lin64/share

However, configure for psLib doesn't find cfitsio, even though libcfitsio.a is exactly where psconfig put it, and contains the symbol that configure complains it can't find:

checking fitsio.h usability... no
checking fitsio.h presence... no
checking for fitsio.h... no
configure: error: CFITSIO headers not found. Obtain CFITSIO at ​http://heasarc.gsfc.nasa.gov/docs/software/fitsio or use --with-cfitsio to specify location.

# Suggested fix was to set LDFLAGS and point to the library location in there,
# which I had done:

jester@aida77 psLib$ echo $LDFLAGS
-L/IPP/bleed.lin64/lib/

# The library is there:
jester@aida77 psLib$ ls /IPP/bleed.lin64/lib/*fits*
/IPP/bleed.lin64/lib/libcfitsio.a

# it contains ffopen:
jester@aida77 psLib$ nm !! |grep ffopen
nm ls /IPP/bleed.lin64/lib/*fits* |grep ffopen
0000000000008780 T ffopen
000000000000a4d0 T ffopentest

U ffopen
U ffopen

0000000000002e60 T Cffopen

U ffopen

# Moreover, the include directory from the configure command does contain
# fitsio.h but configure hadn't found that, eiher:
jester@aida77 psLib$ ls /IPP/bleed.lin64/include/*fits*
/IPP/bleed.lin64/include/fitsio2.h /IPP/bleed.lin64/include/fitsio.h /IPP/bleed.lin64/include/gfitsio.h

Looking at the config.log from psLib, it turns out that the problem wasn't anything to do with ffopen itself, but there were many other undefined symbols pointing to an earlier version of cfitsio compiled for an earlier version of IPP in a different subdirectory of psconfig/../../ -- somehow that confused the linker and/or psconfig. Having deleted that other cfitsio directory, psLib now compiles.

Long story short: far too many people have been having far too many problems like this one with library dependencies, so I don't think the current way psconfig does it is good enough.

Everyone at IfA and elsewhere could be more productive if these library version dependencies were done by a system that is set up to be guaranteed to get it right.

In addition, over the next ~4 years of Linux evolution during ORR preparation and the scheduled PS1SC mission, this is bound to cause some problem at some point also at IfA, not just in the zoo of Linuxes out there in the collaboration.

So I strongly believe that we need to change the config system to something that is guaranteed to compile IPP correctly whatever else is going on on the target system. In my opinion, this can wait until after ORR, but not much longer.

[Sebastian Jester]

Just to ping again on this issue - I am running into comparable problems on a Mac build again, where pschecklibs "finds" versions of fftw3f and gsl in /usr/local/... and doesn't compile them, but psLib's configure fails saying fftw3f and then gsl are not installed.

The work around is of course to pschecklib -force building those libraries, but that defies the purpose of pschecklibs, doesn't it?

Can't pschecklibs do the same tests as the respective 'configure' scripts to determine whether a library is installed or not?