OK, I think its a problem finding lapack
checking for package LAPACK... no CLAPACK not found, trying standard LAPACK. checking for package LAPACK... no
What is it looking for... -lclapack or -llapack
becker427:locate libclap becker428:locate liblap /usr/lib64/liblapack.so.3 /usr/lib64/liblapack.so.3.0.3 /usr/lib64/liblapack.a /usr/lib64/liblapack.so /usr/lib64/liblapack.so.3.0
so it should be finding -llapack...
becker429:more /etc/ld.so.conf include ld.so.conf.d/*.conf /usr/X11R6/lib /usr/X11R6/lib64 /usr/local/lib /usr/lib64
Eh, why is it not finding this!?
./configure --with-paths=$LSST_HOME/external/boost/1.33.1/ --libdir=/usr/lib64
Still no success... Man, go in and edit configure by hand, sigh... The offending lines look like
ax_pkg_libs=`echo -llapack -lblas | sed 's/-l([^[:space:]]*)/lib/lib1.*/g'`
which if I run this on the command line, I get
becker33:echo -llapack -lblas | sed 's/-l([^[:space:]]*)/lib/lib1.*/g' lib/liblapack.* lib/libblas.*
So just hack it by hand. MORE HACKS !!!
ax_pkg_libs=`echo -llapack -lblas | sed 's/-l([^[:space:]]*)/lib64/lib1.*/g'`
This works!
checking for package LAPACK... yes
But it dies somewhere else...
checking for package M... no
What the heck is M!? Ah, libm. So, same hack in configure. And it works! I will mail VW mailing list for this.
becker69: ./configure --prefix=$LSST_ROOT/Linux/external/visionWorkbench/1.0.1 --with-paths=$LSST_HOME/external/boost/1.33.1/
becker70: make
becker71: make install
becker75: eups declare -c visionWorkbench 1.0.1 -M - -r /lsst/lsst_root/Linux/external/visionWorkbench/1.0.1 #HANGS; NEED TO ECHO SOMETHING HERE
becker76: echo 'pathAppend(LD_LIBRARY_PATH, ${PRODUCT_DIR}/lib)' | eups declare -c visionWorkbench 1.0.1 -M - -r /lsst/lsst_root/Linux/external/visionWorkbench/1.0.1
becker78: setup visionWorkbench -v
Setting up: visionWorkbench Flavor: Linux Version: 1.0.1
Sent the following email to vision-workbench@…
Hi -
I am trying to install VW on a 64 bit machine, and the ./configure script is having problems with this.
By editing the ./configure script by hand, I have gotten it to recognize that liblapack and libblas, as well as
libm, all reside in /usr/lib64/ here instead of /usr/lib/. I made the changes below; note that these will fail
on a non-64 bit machine, but I would recommend enabling the script to look in /lib64/ as well as /lib/ for 64 bit
machines
Regards,
Andy
##### FOR LAPACK
# Test for and configure flags for header and library files
if test "$HAVE_PKG_LAPACK" = "yes" ; then
unset ax_pkg_headers ax_pkg_libs
if test ! -z "-llapack -lblas"; then
# ax_pkg_libs=`echo -llapack -lblas | sed 's/-l([^[:space:]]*)/lib/lib1.*/g'`
ax_pkg_libs=`echo -llapack -lblas | sed 's/-l([^[:space:]]*)/lib64/lib1.*/g'`
fi
##### FOR M
# Test for and configure flags for header and library files
if test "$HAVE_PKG_M" = "yes" ; then
unset ax_pkg_headers ax_pkg_libs
if test ! -z "-lm"; then
# ax_pkg_libs=`echo -lm | sed 's/-l([^[:space:]]*)/lib/lib1.*/g'`
ax_pkg_libs=`echo -lm | sed 's/-l([^[:space:]]*)/lib64/lib1.*/g'`
fi
So, so close...
becker97: setup cfitsio -v
Setting up: cfitsio Flavor: Linux Version: 3006
becker99: pwd
/lsst/becker/lsst_devel/DC2/scons
becker100: scons
scons: Reading SConscript files ...
Checking if CC is really gcc...yes
Checking for C++ header file Python.h... yes
Checking for C++ header file boost/version.hpp... yes
Checking for C++ library boost_filesystem... yes
Checking for C++ header file vw/Core.h... yes
Checking for C++ library vw... yes
Checking for C++ header file fitsio.h... yes
Checking for ffopen() in C library cfitsio... no
Checking for C++ header file wcs.h... yes
Checking for wcscat() in C library wcs... yes
Checking for C++ header file xpa.h... yes
Checking for XPAPuts() in C library xpa... yes
Error: Failed to find cfitsio in /lsst/lsst_root/Linux/external/cfitsio/3006/lib
Failed to find cfitsio -- do you need to setup cfitsio or specify cfitsio=DIR?
becker101: ls /lsst/lsst_root/Linux/external/cfitsio/3006/lib
libcfitsio.a
becker477: cd /lsst/lsst_root/Linux/external/cfitsio/3006/lib
/lsst/lsst_root/Linux/external/cfitsio/3006/lib
becker478: nm libcfitsio.a | grep ffopen
0000000000005d50 T ffopen
00000000000096d0 T ffopentest
U ffopen
U ffopentest
0000000000000f90 T Cffopen
U ffopen
Grrr.....
Ah, useful!
becker12:readelf -h libcfitsio.a | more File: libcfitsio.a(buffers.o) ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: REL (Relocatable file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x0 Start of program headers: 0 (bytes into file) Start of section headers: 10424 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 0 (bytes) Number of program headers: 0 Size of section headers: 64 (bytes) Number of section headers: 13 Section header string table index: 10
Also, there is Ess-cons output in config.log. I notice a clear error
... scons: Configure: Checking for ffopen() in C library m cfitsio... ... gcc -o .sconf_temp/conftest_7 .sconf_temp/conftest_7.o -L/lsst/lsst_root/Linux/external/boost/1.33.1/lib -L/lsst/lsst_root/Linux/external/visionWorkbench/1.0.1/lib -L/lsst/lsst_root/Linux/external/Python/2.4.2/lib/python2.4/site-packages -L/lsst/lsst_root/Linux/external/cfitsio/3006/lib "-lm cfitsio" # NOTE THIS PROBLEM # "-lm cfitsio"
Have a look at the SConstruct file:
env = scons.makeEnv("fw",
r"$HeadURL: svn+ssh://svn.lsstcorp.org/DC2/fw/branches/scons/SConstruct $",
[["boost", "boost/version.hpp", "boost_filesystem:C++"],
["visionWorkbench", "vw/Core.h", "vw:C++"],
["python", "Python.h"],
["cfitsio", "fitsio.h", "m cfitsio", "ffopen"],
["wcstools", "wcs.h", "wcs", "wcscat"],
["xpa", "xpa.h", "xpa", "XPAPuts"],
])
I got this after an svn update so its up-to-date. Clearly a problem here, parsing the "m cfitsio" into -lm -lcfitsio. I'll fix it and check it in!
["cfitsio", "fitsio.h", "cfitsio", "ffopen"], # nope, needs -lm also for "pow" ["cfitsio", "fitsio.h", "m, cfitsio", "ffopen"], # nope, says "-lm, cfitsio" ... # hmm, nothing stands out yet
Look at the actual Ess-sons code at Linux/sconsUtils/v1.9/python/lsst/SConsUtils.py.
Line 205 : (product, incfiles, libs, symbol) = productProps[0:4] # we want libs
Line 243 : if libs:
Line 250 : if conf.CheckLib(libs, symbol, language=lang) # next up, need to check conf
Line 172 : conf = Configure(env, custom_tests = {'IsGcc' : IsGcc}) # Configure is
On to SCons at /lsst/lsst_root/Linux/external/scons/0.96.94/lib/scons/SCons
becker21: grep Configure *py | grep def
Environment.py: def Configure(self, *args, **kw):
becker24: grep CheckLib *py | grep def
Conftest.py:def CheckLib(context, libs, func_name = None, header = None,
SConf.py:def CheckLib(context, library = None, symbol = "main",
SConf.py:def CheckLibWithHeader(context, libs, header, language,
# inside SConf.py
Line 839 : if not SCons.Util.is_List(library):
library = [library]
# try
library = library.split() # this yields ['m', 'cfitsio']; but then only checks for -lm and then in a separate test -lcfitsio
Just got an email from Tim
My SConstruct file is identical, and scons works fine. This is ringing a vague bell...I think Robert said something about python needing an upgrade. I suspect the python version - mops2 is at 2.4.3, you are at 2.4.2.
so try upgrading python? Nah, the problem really seems in the Esscons code to me... Start with SConsUtils - I see that we are up to v1.12. So
becker42: cd $LSST_HOME/
becker44: svn co svn+ssh://dev.lsstcorp.org/DC2/SConsUtils/tags/v1.12 SConsUtils
becker45: cd SConsUtils
becker46: scons install current
scons: Reading SConscript files ...
Checking if CC is really gcc...yes
KeyError: 'DYLD_LIBRARY_PATH':
File "/lsst/lsst_root/Linux/SConsUtils/SConstruct", line 12:
r"$HeadURL: svn+ssh://dev.lsstcorp.org/DC2/SConsUtils/tags/v1.12/SConstruct $")
File "python/lsst/SConsUtils.py", line 196:
env.Append(LINKFLAGS = "-Wl,-rpath-link -Wl,%s" %
File "/lsst/lsst_root/Linux/external/Python/2.4.2/lib/python2.4/UserDict.py", line 17:
def __getitem__(self, key): return self.data[key]
More pain...
becker47: setenv DYLD_LIBRARY_PATH becker48: scons install current
works. Let RHL know.
becker49: setup scons -v Setting up: scons Flavor: Linux Version: v1.12 Setting up: sconsUtils Flavor: Linux Version: v1.12 Setting up: sconsDistrib Flavor: Linux Version: v0.96.94
Will this finally work!??!?!!?!?!
becker51: cd $LSST_DEVEL/DC2/scons/ becker53: scons
YES, IT IS BUILDING !!!
Success is very short lived in this game, isn't it? So, sigh, as I was typing in my triumphant header font in my browser, the code was building. I presumed I would come back to a successfully terminated job, when instead...
/usr/bin/ld: /usr/local/lib/libwcs.a(ty2read.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/libwcs.a: could not read symbols: Bad value collect2: ld returned 1 exit status scons: *** [python/lsst/fw/Catalog/_ctgread.so] Error 1
Strangely, I don't have wcstools installed here at all..? setup wcstools doesn't recognize anything. Oops, its called WCSTools tools here, version 3.6.2.
BTW
This is useful : setup -l gives you all the setup stuff.
Anyways, the installation of WCSTools requires that we put -fPIC on the command line. But I see
http://dev.lsstcorp.org/pkgs/external/WCSTools/3.6.2/WCSTools-3.6.2.pacman.m4
#
shell('make CFLAGS="-g -O2 -fPIC"')
So this should have happenend..?
OK, I am getting tired. Have a look; its using "/usr/local/lib/libwcs.a". This should not happen! Why not? Because I don't have WCSTools setup!
# Note there is no WCSTools here gcc -o python/lsst/fw/Catalog/_ctgread.so -Wl,-rpath-link -Wl, -shared python/lsst/fw/Catalog/ctgread_wrap.os -L/lsst/lsst_root/Linux/external/boost/1.33.1/lib -L/lsst/lsst_root/Linux/external/visionWorkbench/1.0.1/lib -L/lsst/lsst_root/Linux/external/Python/2.4.2/lib/python2.4/site-packages -L/lsst/lsst_root/Linux/external/cfitsio/3006/lib -L/lsst/lsst_root/Linux/external/xpa/2.1.7b2/lib -Llib -lwcs # setup WCSTools # Gets the new path, but /usr/local/lib is still first; my own problem with my own installation. Duh... gcc -o python/lsst/fw/Catalog/_ctgread.so -Wl,-rpath-link -Wl, -shared python/lsst/fw/Catalog/ctgread_wrap.os -L/lsst/lsst_root/Linux/external/boost/1.33.1/lib -L/lsst/lsst_root/Linux/external/visionWorkbench/1.0.1/lib -L/lsst/lsst_root/Linux/external/Python/2.4.2/lib/python2.4/site-packages -L/lsst/lsst_root/Linux/external/cfitsio/3006/lib -L/lsst/lsst_root/Linux/external/WCSTools/3.6.2/lib -L/lsst/lsst_root/Linux/external/xpa/2.1.7b2/lib -Llib -lwcs
I remade my own libwcs.a and that worked, but now
swig -c++ -python -I/lsst/lsst_root/Linux/external/boost/1.33.1/include -I/lsst/lsst_root/Linux/external/visionWorkbench/1.0.1/include -I/lsst/lsst_root/Linux/external/Python/2.4.2/include/python2.4 -I/lsst/lsst_root/Linux/external/Python/2.4.2/include -I/lsst/lsst_root/Linux/external/cfitsio/3006/include -I/lsst/lsst_root/Linux/external/WCSTools/3.6.2/include -I/lsst/lsst_root/Linux/external/xpa/2.1.7b2/include -I/lsst/becker/lsst_devel/DC2/scons/include -I/lsst/becker/lsst_devel/DC2/scons/src -o python/lsst/fw/Display/fwLib_wrap.cc python/lsst/fw/Display/fwLib.i python/lsst/fw/Display/p_lsstSwig.i:8: Syntax error in input.
EH!?
becker118:head -8 python/lsst/fw/Display/p_lsstSwig.i | tail -1 %pythonnondynamic;
Well what the heck does that mean? Maybe thats a python issue?
