Changes between Initial Version and Version 1 of Installing_IPP_FAQ

Timestamp:

Feb 24, 2009, 4:23:56 PM (17 years ago)

Author:

trac

Comment:

--

Installing_IPP_FAQ

@@ +1 @@
+See also the list of [wiki:WikiStart Installation-related notes on the Main Page].
+
+== pschecklibs or pscheckperl complain about missing tar files ==
+
+This is the most painless way I found to build all dependencies in Heidelberg:
+
+# Download appropriate extlibs and extperl tarfiles from http://pan-starrs.ifa.hawaii.edu/project/IPP/software/
+# Unpack both in your IPP root directory, i.e. in the same directory where you unpacked the ipp-2.6.1.tgz (or whatever) tarball. In Heidelberg, it's called /IPP
+# Then 
+ cd /IPP/ipp-2.6.1/psconfig
+ pschecklibs -build
+ pscheckperl -build
+
+== The CFITSIO perl module doesn't build ==
+
+I found I needed to set an environment variable CFITSIO to the location of CFITSIO if it's non-standard, e.g.
+
+ # for bash:
+ export CFITSIO=/IPP/ipp-2.6.1.lin64/lib
+ # for csh:
+ setenv CFITSIO /IPP/ipp-2.6.1.lin64/lib
+
+== psbuild complains about fftw3, but it's installed on my system! ==
+
+fftw3 needs to be built with both --enable-float and with -fPIC, but pschecklibs only tests whether fftw3 is present *somewhere* on the system, not whether it's been built correctly.
+
+To be sure you have the proper build of fftw3, and assuming the same directory structure as above, do this:
+
+ cd /IPP/extlibs/fftw-3.1.2/
+ ./configure --enable-float --prefix=/IPP/ipp-2.6.1.lin64/ CFLAGS=-fPIC
+ make && make install
+
+[http://pan-starrs.ifa.hawaii.edu/bugzilla/show_bug.cgi?id=993 Bug 993] asks for a fix inside the build system.
+
+== libtool says some library "was moved", but I didn't move anything! ==
+
+This error message from libtool must be one of the most frequently unanswered, or inaccurately answered, questions on the internet. The error looks like
+
+ libtool: link: warning: library
+ `/kuiyun/ast/ipp-2.5/psconfig/default.lin64/lib/libpslib.la' was moved.
+ libtool: link: cannot find the library `/usr/local/lib/libpslib.la'
+
+I ran into it because I had an environment variable D defined, which was referenced inside libtool, leading to unintended consequences. Thus, make sure you avoid single-letter environment variables in the shell where you're building IPP. Also, variables like F2C and F77 can be set by things like IRAF, sometimes leading to unintended consequences. Hence, to be on the safe side, do
+
+ unset D U F2C F77
+
+etc. before you psbuild.
+
+http://markmail.org/message/sinepfpepgj7tdff seems to have the real solution for the remaining cases:
+The origin of this error is that /usr/local/lib/ (with or without libpslib.la appended) appears in a libslib.la file somewhere, in this case potentially in /kuiyun/ast/ipp-2.5/psconfig/default.lin64/lib/libpslib.la
+
+You can find these occurrences by going to the root directory of your IPP installation, once each for both the source/build tree and for the install tree (the one with .lin64 at the end of the directory name), and saying:
+
+ egrep '/usr/local/lib' `find ./ -name \*.la`
+
+then changing the offending paths by hand (i.e. in this case, change /usr/local/lib to /kuiyun/ast/ipp-2.5/psconfig/default.lin64/lib/ ).
+
+I have had a similar error, and in my case, it found
+
+./lib/libpslib.la:libdir='/usr/local/lib'
+./lib/libpsmodules.la:dependency_libs=' -L/IPP/ipp-2.6.1.lin64/lib -lkapa -ldvo -lFITS -lohana -L/usr/lib64 /usr/lib64/libX11.la /usr/lib64/libXau.la /usr/lib64/libXdmcp.la -ldl /usr/lib64/libpng.la -L/usr/lib64/mysql /usr/local/lib/libpslib.la /usr/lib64/mysql/libmysqlclient.la -L/IPP/ipp-2.6.1.lin64//lib -lmysqlclient -lz -lcrypt -lnsl -lcfitsio /IPP/ipp-2.6.1.lin64/lib/libgsl.la /IPP/ipp-2.6.1.lin64/lib/libgslcblas.la -lm -ljpeg'
+
+in the install tree, and the dependency_libs was the problem.
+
+I have no ideas how where or when these get set wrongly by libtool, but it seems to be a common bug in libtool.
+
+==DBD::mysql build error: "CPU you selected does not support x86-64 instruction set"==
+
+The specific error looks something like:
+<pre>
+Running Mkbootstrap for DBD::mysql ()
+dbdimp.c:1: error: CPU you selected does not support x86-64 instruction set
+dbdimp.c:1: error: CPU you selected does not support x86-64 instruction set
+/usr/bin/perl /usr/lib/perl5/5.8.5/ExtUtils/xsubpp  -typemap /usr/lib/perl5/5.8.5/ExtUtils/typemap  mysql.xs > mysql.xsc && mv mysql.xsc mysql.c
+make: *** [dbdimp.o] Error 1
+</pre>
+
+The problem is that the installed version of MySQL is 32-bit, but the CPU is 64-bit (yeah, the error doesn't reveal that, but see [http://objectmix.com/perl/318993-problem-installing-dbd-mysql.html this]).  You can see this by looking at the MySQL configuration:
+
+<pre>
+% mysql_config
+Usage: /usr/lib/mysql/mysql_config [OPTIONS]
+Options:
+        --cflags         [-I/usr/include/mysql -g -pipe -m32 -march=i386 -mtune=pentium4 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing]
+[...]
+</pre>
+
+The <code>-m32 -march=i386</code> indicate that MySQL was built for 32-bit machines.  Furthermore, the fact that the include files are being sucked in from <code>/usr/include/mysql</code> indicates that it's trying to use the system version, rather than one we've installed ourselves.
+
+The solution is to force MySQL to build:
+<pre>
+% pschecklibs -build -force libmysqlclient
+</pre>
+
+Then you should be able to return and build the Perl modules.
+
+==libjpeg fails make==
+
+libjpeg fails the <code>configure</code> script, or <code>make</code>, and <code>pschecklibs</code> reports:
+<pre>
+problem building libjpeg : failure in make
+</pre>
+
+libjpeg is an old library, and the bundled files for running the <code>configure</code> script pre-date several systems (e.g., Mac OS X, 64-bit Linux machines).  You can get around this by going into the directory containing libjpeg and doing:
+<pre>
+% cp /usr/share/libtool/config.guess .
+% cp /usr/share/libtool/config.sub .
+% psconfigure --enable-shared --enable-static
+% make
+% make install
+</pre>
+
+==Missing shared library when running a binary==
+
+For example:
+<pre>
+% psphot
+gcc: /usr/lib64/libjpeg.so: No such file or directory
+</pre>
+
+If the IPP is built on one system, and the resultant binaries are used on a different system, then shared libraries that existed on the first system ''must'' be present on the second; if they are not, the above error will occur.  Since this isn't always the case, we recommend that when the IPP is built for a system of heterogeneous systems, ''all'' the external libraries are built:
+<pre>
+% pschecklibs -build -force all
+% pscheckperl -build -force all
+% psbuild -clean -rebuild
+</pre>
+
+The above commands force the building of all external libraries (not just those that aren't present), and re-run the IPP build from scratch.