14/04/06: has been straightforward so far, Timba code itself needed very minor changes.
Problems encountered
when building shared libraries, the following messages show up at various stages:
/usr/bin/ld: /usr/lib64/libblitz.a(globals.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
According to these discussions... ![[WWW]](/wiki/classic/img/moin-www.png)
http://lists.freebsd.org/pipermail/freebsd-amd64/2005-April/004644.html http://tolstoy.newcastle.edu.au/R/devel/05/10/2956.html
...anything linked into an .so has to be compiled with the -fPIC flag on amd64 (and on other 64-bit platforms)! For Timba libs, I have gotten around this by adding -fPIC to CFLAGS. The same thing apparently needs to be done to blitz++ before we can link against it. However, -fPIC is claimed to be bad for perfomance when NOT linking against an .so. Update 15/04/06: I have investigated this, see ./Timba64BitPerformance, my preliminary conclusion is that the hit is minimal, but in a perfect world I will need to test both versions.
So, what we need to do.
rebuild blitz++ with -fPIC. Unfortunately, this means we can't use the Debian blitz++ package.
Update 15/04/06: done this (./configure with --enable-shared). However autoconf looks for it in e.g. /usr/local/lib64, while "make install" installs it in /usr/local/lib. Made a symlink, that appears to work fine.
To measure overall performance with -fPIC vs. no -fPIC: add targets for building .so versions of relevant Timba libs with -fPIC. Libs needed are those linked to Python, i.e.: TimBase, DMI, OCTOPUSSY, OctoPython, MEQ, PyApps. I'm not sure how to do this easily with automake, so for now I'm building everything with -fPIC.
AIPS++ problems.
I used the linux_gnu_x86_64 libs from John Romein.
had to add -DAIPS_64B to CFLAGS, otherwise the Conversions.h header threw an error.
Bunch of link errors in MeqServer, i.e.
undefined reference to `casa::Array<float>::resize(casa::IPosition const&)'
For some reasons all the array ::resize() symbols in libcasa.a have an extra bool argument at the end, I have no idea why that is (the header files show no bool argument).
15/04/06: Python dl module appears to be MIA on amd64. This caused dmi.py to fail. We only need this module for the flags, which are also available from module DLFCN. Changed dmi.py and octopython.py accordingly, works fine on birch so far.
Browser runs!
14/04/06: And hurrah! we have a running browser on cedar. Now all we need is to resolve the AIPS++ problems and maybe we can build a kernel too...
19/04/06: Kernel runs!
when building shared libraries, the following messages show up at various stages:
/usr/bin/ld: /usr/lib64/libblitz.a(globals.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
According to these discussions...
http://lists.freebsd.org/pipermail/freebsd-amd64/2005-April/004644.html http://tolstoy.newcastle.edu.au/R/devel/05/10/2956.html ...anything linked into an .so has to be compiled with the -fPIC flag on amd64 (and on other 64-bit platforms)! For Timba libs, I have gotten around this by adding -fPIC to CFLAGS. The same thing apparently needs to be done to blitz++ before we can link against it. However, -fPIC is claimed to be bad for perfomance when NOT linking against an .so. Update 15/04/06: I have investigated this, see ./Timba64BitPerformance, my preliminary conclusion is that the hit is minimal, but in a perfect world I will need to test both versions.
So, what we need to do.
rebuild blitz++ with -fPIC. Unfortunately, this means we can't use the Debian blitz++ package.
Update 15/04/06: done this (./configure with --enable-shared). However autoconf looks for it in e.g. /usr/local/lib64, while "make install" installs it in /usr/local/lib. Made a symlink, that appears to work fine.
To measure overall performance with -fPIC vs. no -fPIC: add targets for building .so versions of relevant Timba libs with -fPIC. Libs needed are those linked to Python, i.e.: TimBase, DMI, OCTOPUSSY, OctoPython, MEQ, PyApps. I'm not sure how to do this easily with automake, so for now I'm building everything with -fPIC.
AIPS++ problems.
I used the linux_gnu_x86_64 libs from John Romein.
had to add -DAIPS_64B to CFLAGS, otherwise the Conversions.h header threw an error.
Bunch of link errors in MeqServer, i.e.
undefined reference to `casa::Array<float>::resize(casa::IPosition const&)'
For some reasons all the array ::resize() symbols in libcasa.a have an extra bool argument at the end, I have no idea why that is (the header files show no bool argument).
15/04/06: Python dl module appears to be MIA on amd64. This caused dmi.py to fail. We only need this module for the flags, which are also available from module DLFCN. Changed dmi.py and octopython.py accordingly, works fine on birch so far.
14/04/06: And hurrah! we have a running browser on cedar. Now all we need is to resolve the AIPS++ problems and maybe we can build a kernel too...
19/04/06: Kernel runs!
Compiling AIPS++ has proven to be hell on earth, but I managed to build enough libraries to link a meqserver. And hurrah! everything seems to run.
The rest of AIPS++ is still in a bit of a shambles. This deserves a separate page, ../BuildingAipsppOnDebianAmd64.