Changes between Version 1 and Version 2 of Installing_IPP_FAQ
- Timestamp:
- Apr 1, 2009, 9:18:07 AM (17 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Installing_IPP_FAQ
v1 v2 8 8 # 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 9 9 # Then 10 {{{ 10 11 cd /IPP/ipp-2.6.1/psconfig 11 12 pschecklibs -build 12 13 pscheckperl -build 14 }}} 13 15 14 16 == The CFITSIO perl module doesn't build == … … 16 18 I found I needed to set an environment variable CFITSIO to the location of CFITSIO if it's non-standard, e.g. 17 19 20 {{{ 18 21 # for bash: 19 22 export CFITSIO=/IPP/ipp-2.6.1.lin64/lib 20 23 # for csh: 21 24 setenv CFITSIO /IPP/ipp-2.6.1.lin64/lib 25 }}} 22 26 23 27 == psbuild complains about fftw3, but it's installed on my system! == … … 27 31 To be sure you have the proper build of fftw3, and assuming the same directory structure as above, do this: 28 32 33 {{{ 29 34 cd /IPP/extlibs/fftw-3.1.2/ 30 35 ./configure --enable-float --prefix=/IPP/ipp-2.6.1.lin64/ CFLAGS=-fPIC 31 36 make && make install 37 }}} 32 38 33 39 [http://pan-starrs.ifa.hawaii.edu/bugzilla/show_bug.cgi?id=993 Bug 993] asks for a fix inside the build system. … … 37 43 This error message from libtool must be one of the most frequently unanswered, or inaccurately answered, questions on the internet. The error looks like 38 44 45 {{{ 39 46 libtool: link: warning: library 40 47 `/kuiyun/ast/ipp-2.5/psconfig/default.lin64/lib/libpslib.la' was moved. 41 48 libtool: link: cannot find the library `/usr/local/lib/libpslib.la' 49 }}} 42 50 43 51 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 44 52 53 {{{ 45 54 unset D U F2C F77 55 }}} 46 56 47 57 etc. before you psbuild. … … 52 62 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: 53 63 64 {{{ 54 65 egrep '/usr/local/lib' `find ./ -name \*.la` 66 }}} 55 67 56 68 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/ ). … … 58 70 I have had a similar error, and in my case, it found 59 71 72 {{{ 60 73 ./lib/libpslib.la:libdir='/usr/local/lib' 61 74 ./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' 75 }}} 62 76 63 77 in the install tree, and the dependency_libs was the problem. … … 65 79 I have no ideas how where or when these get set wrongly by libtool, but it seems to be a common bug in libtool. 66 80 67 == DBD::mysql build error: "CPU you selected does not support x86-64 instruction set"==81 == DBD::mysql build error: "CPU you selected does not support x86-64 instruction set" == 68 82 69 83 The specific error looks something like: 70 <pre> 84 {{{ 71 85 Running Mkbootstrap for DBD::mysql () 72 86 dbdimp.c:1: error: CPU you selected does not support x86-64 instruction set … … 74 88 /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 75 89 make: *** [dbdimp.o] Error 1 76 </pre> 90 }}} 77 91 78 92 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: 79 93 80 <pre> 94 {{{ 81 95 % mysql_config 82 96 Usage: /usr/lib/mysql/mysql_config [OPTIONS] … … 84 98 --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] 85 99 [...] 86 </pre> 100 }}} 87 101 88 102 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. 89 103 90 104 The solution is to force MySQL to build: 91 <pre> 105 {{{ 92 106 % pschecklibs -build -force libmysqlclient 93 </pre> 107 }}} 94 108 95 109 Then you should be able to return and build the Perl modules. 96 110 97 == libjpeg fails make==111 == libjpeg fails make == 98 112 99 113 libjpeg fails the <code>configure</code> script, or <code>make</code>, and <code>pschecklibs</code> reports: 100 <pre> 114 {{{ 101 115 problem building libjpeg : failure in make 102 </pre> 116 }}} 117 103 118 104 119 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: 105 <pre> 120 {{{ 106 121 % cp /usr/share/libtool/config.guess . 107 122 % cp /usr/share/libtool/config.sub . … … 109 124 % make 110 125 % make install 111 </pre> 126 }}} 112 127 113 ==Missing shared library when running a binary== 128 129 == Missing shared library when running a binary == 114 130 115 131 For example: 116 <pre> 132 {{{ 117 133 % psphot 118 134 gcc: /usr/lib64/libjpeg.so: No such file or directory 119 </pre> 135 }}} 136 120 137 121 138 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: 122 <pre> 139 {{{ 123 140 % pschecklibs -build -force all 124 141 % pscheckperl -build -force all 125 142 % psbuild -clean -rebuild 126 </pre> 143 }}} 127 144 128 145 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.
