[sage-devel] Re: Problems building Sage 4.4.1
Thanks for the response! We'll try to disable it for now, and investigate some of the other things mentioned in this thread. The problem we have is that we need to provide something like CC/CXX flags, as the only compiler we can guarantee is the one which we install, which is installed in a specific location, not globally. Is there some way we can do something similar to this in Sage? You said that CC/CXX do not work very well, why is this :(? Thanks! Matthew On Jun 8, 6:21 pm, David Kirkby david.kir...@onetel.net wrote: On 8 June 2010 17:17, Matthew Gwynne mathew.gwy...@gmail.com wrote: Hi, As some additional points of interest/questions for this problem: 1. Version 2.7.2 was the lastSageversion which could be installed. We tried most versions since then (latest 4.4.2), and they all failed with the same error. Looking at the error message: - /usr/local/lib/../lib/libstdc++.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status make[4]: *** [libfplll.la] Error 1 - it rather suggests the compiler is complaining about a file in /usr/local, rather than one in theSagedirectory. It's quite possible that libfplll is the first package to link to the C++ library, which is what that file is. I would consider downloading gcc 4.4.4 (not 4.5, as that is quite new, and probably more buggy than the 4.4 series), and compiling that. You would also need to download mpfr and gmp, and build those. It's difficult to suggest much more. I'm not a linux guru, but had I hit the same message on the Solaris operating system, I would suspect the compiler. (Not that I claim to be a Solaris guru!) It's clear different parts of your compiler were built at different times, as your C and C++ compilers were built without Fortran support, and the Fortran compiler was built with C, C++ and Fortran support. That in itself should not stop the combination working, but I'd certainly look at trying another compiler. 2. It is always the same package which fails. We don't have any other installation problems in our system, so we wonder if that package might be faulty in some way? Is there some difference with that package compared to other packages (in theSage-build)? To be honest, few packages are configured identically. 3. Is that package needed? Is there some way we can prevent it from being used/built? You can stop pacakge 'foobar' building by foolingSageinto believing the package is already installed. The way to do that is touch spkg/installed/foobar In the case of some packages, that will still allowSageto build, but certainly not all packages. I don't know for sure whether this would be essential or not to get some sort of workingSage. It would be useful to try this. You might find other packages fail with a similar error, which would make me even more suspicious it is a compiler problem. Thanks again! Matthew Sorry I can't be of much more help. Dave On May 26, 2:54 pm, David Kirkby david.kir...@onetel.net wrote: On 26 May 2010 11:57, Matthew Gwynne mathew.gwy...@gmail.com wrote: Hi, The system information is given below - Host system uname -a: Linux cs-wsok 2.6.13-15.8-smp #1 SMP Tue Feb 7 11:07:24 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux CC Version gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ./configure --enable-languages=c,c++ --enable- threads=posix --enable-shared Thread model: posix Something is odd here. You need to have a compiler supporting Fortran, yet yours was compiled without Fortran support. I'm very surprised the 'prereq' script does not detect this, as it should check for a fortran compiler and confirm its the same version as the C and C++ compilers. So unless you have two installations of gcc, both of the same version, I don't know how you got this far. can you give me the outputs of $ command -v gcc $ command -v g++ $ command -v gfortran $ gcc -v $ g++ -v $ gfortran -v $ echo $LD_LIBRARY_PATH $ echo $CC $ echo $CXX $ echo SAGE_FORTRAN $ echo SAGE_FORTRAN_LIB Specifying the compiler locations with CC and CXX does not work too well Dave -- To post to this group, send an email tosage-de...@googlegroups.com To unsubscribe from this group, send an email tosage-devel+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/sage-devel URL:http://www.sagemath.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at
Re: [sage-devel] Re: Problems building Sage 4.4.1
On 06/11/10 06:34 PM, Matthew Gwynne wrote: Thanks for the response! We'll try to disable it for now, and investigate some of the other things mentioned in this thread. The problem we have is that we need to provide something like CC/CXX flags, as the only compiler we can guarantee is the one which we install, which is installed in a specific location, not globally. Is there some way we can do something similar to this in Sage? You said that CC/CXX do not work very well, why is this :(? Thanks! Matthew CC, CXX, CFLAGS and similar should be considered broken. If CC is undefined, Sage environment script sets CC to gcc. If CXX is not defined, Sage environment script sets CXX to g++, That seems logical. However, if CC is defined, the Sage environment script does not change it. Again this seems logical. When the individual components of Sage are built, some well behaved packages respect these, and use the respective compiles. A large number do not, and use gcc or g++ So if you set $ CC=/path/to/my/favorite/gcc some programs will use the first gcc in the path and others will use /path/to/my/favorite/gcc. It is hit-and-miss Over the course of time, I've filed loads of bug reports for these, and fixed some of them. The easiest way to find them, is to install the Sun compiler, then let type make, and detect what packages build with gcc. Many do unfortunately. These are all outstanding. http://trac.sagemath.org/sage_trac/ticket/7071 http://trac.sagemath.org/sage_trac/ticket/7069 http://trac.sagemath.org/sage_trac/ticket/7066 http://trac.sagemath.org/sage_trac/ticket/7027 http://trac.sagemath.org/sage_trac/ticket/7024 I've fixed a few http://trac.sagemath.org/sage_trac/ticket/7036 http://trac.sagemath.org/sage_trac/ticket/7032 but there are many more. Fixing them is not always easy. Your best course of action is to make sure your path is set correctly and perhaps LD_LIBRARY_PATH are set correctly to find the right compiler, so when you type just gcc you get a workable compiler. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Problems building Sage 4.4.1
Hi, As some additional points of interest/questions for this problem: 1. Version 2.7.2 was the last Sage version which could be installed. We tried most versions since then (latest 4.4.2), and they all failed with the same error. 2. It is always the same package which fails. We don't have any other installation problems in our system, so we wonder if that package might be faulty in some way? Is there some difference with that package compared to other packages (in the Sage-build)? 3. Is that package needed? Is there some way we can prevent it from being used/built? Thanks again! Matthew On May 26, 2:54 pm, David Kirkby david.kir...@onetel.net wrote: On 26 May 2010 11:57, Matthew Gwynne mathew.gwy...@gmail.com wrote: Hi, The system information is given below - Host system uname -a: Linux cs-wsok 2.6.13-15.8-smp #1 SMP Tue Feb 7 11:07:24 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux CC Version gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ./configure --enable-languages=c,c++ --enable- threads=posix --enable-shared Thread model: posix Something is odd here. You need to have a compiler supporting Fortran, yet yours was compiled without Fortran support. I'm very surprised the 'prereq' script does not detect this, as it should check for a fortran compiler and confirm its the same version as the C and C++ compilers. So unless you have two installations of gcc, both of the same version, I don't know how you got this far. can you give me the outputs of $ command -v gcc $ command -v g++ $ command -v gfortran $ gcc -v $ g++ -v $ gfortran -v $ echo $LD_LIBRARY_PATH $ echo $CC $ echo $CXX $ echo SAGE_FORTRAN $ echo SAGE_FORTRAN_LIB Specifying the compiler locations with CC and CXX does not work too well Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Problems building Sage 4.4.1
On 8 June 2010 17:17, Matthew Gwynne mathew.gwy...@gmail.com wrote: Hi, As some additional points of interest/questions for this problem: 1. Version 2.7.2 was the last Sage version which could be installed. We tried most versions since then (latest 4.4.2), and they all failed with the same error. Looking at the error message: - /usr/local/lib/../lib/libstdc++.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status make[4]: *** [libfplll.la] Error 1 - it rather suggests the compiler is complaining about a file in /usr/local, rather than one in the Sage directory. It's quite possible that libfplll is the first package to link to the C++ library, which is what that file is. I would consider downloading gcc 4.4.4 (not 4.5, as that is quite new, and probably more buggy than the 4.4 series), and compiling that. You would also need to download mpfr and gmp, and build those. It's difficult to suggest much more. I'm not a linux guru, but had I hit the same message on the Solaris operating system, I would suspect the compiler. (Not that I claim to be a Solaris guru!) It's clear different parts of your compiler were built at different times, as your C and C++ compilers were built without Fortran support, and the Fortran compiler was built with C, C++ and Fortran support. That in itself should not stop the combination working, but I'd certainly look at trying another compiler. 2. It is always the same package which fails. We don't have any other installation problems in our system, so we wonder if that package might be faulty in some way? Is there some difference with that package compared to other packages (in the Sage-build)? To be honest, few packages are configured identically. 3. Is that package needed? Is there some way we can prevent it from being used/built? You can stop pacakge 'foobar' building by fooling Sage into believing the package is already installed. The way to do that is touch spkg/installed/foobar In the case of some packages, that will still allow Sage to build, but certainly not all packages. I don't know for sure whether this would be essential or not to get some sort of working Sage. It would be useful to try this. You might find other packages fail with a similar error, which would make me even more suspicious it is a compiler problem. Thanks again! Matthew Sorry I can't be of much more help. Dave On May 26, 2:54 pm, David Kirkby david.kir...@onetel.net wrote: On 26 May 2010 11:57, Matthew Gwynne mathew.gwy...@gmail.com wrote: Hi, The system information is given below - Host system uname -a: Linux cs-wsok 2.6.13-15.8-smp #1 SMP Tue Feb 7 11:07:24 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux CC Version gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ./configure --enable-languages=c,c++ --enable- threads=posix --enable-shared Thread model: posix Something is odd here. You need to have a compiler supporting Fortran, yet yours was compiled without Fortran support. I'm very surprised the 'prereq' script does not detect this, as it should check for a fortran compiler and confirm its the same version as the C and C++ compilers. So unless you have two installations of gcc, both of the same version, I don't know how you got this far. can you give me the outputs of $ command -v gcc $ command -v g++ $ command -v gfortran $ gcc -v $ g++ -v $ gfortran -v $ echo $LD_LIBRARY_PATH $ echo $CC $ echo $CXX $ echo SAGE_FORTRAN $ echo SAGE_FORTRAN_LIB Specifying the compiler locations with CC and CXX does not work too well Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Problems building Sage 4.4.1
Here is the output: ~ command -v gcc /usr/local/bin/gcc ~ command -v g++ /usr/local/bin/g++ ~ command -v gfortran /usr/local/bin/gfortran ~ gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ./configure --enable-languages=c,c++ --enable- threads=posix --enable-shared Thread model: posix gcc version 4.1.2 ~ g++ -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ./configure --enable-languages=c,c++ --enable- threads=posix --enable-shared Thread model: posix gcc version 4.1.2 ~ gfortran -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ./configure --enable-languages=c,c++,fortran --enable- threads=posix --enable-shared Thread model: posix gcc version 4.1.2 ~ echo $LD_LIBRARY_PATH ~ echo $CC ~ echo $CXX ~ echo SAGE_FORTRAN SAGE_FORTRAN ~ echo $SAGE_FORTRAN ~ echo $SAGE_FORTRAN_LIB Thanks! Matthew On May 26, 2:54 pm, David Kirkby david.kir...@onetel.net wrote: On 26 May 2010 11:57, Matthew Gwynne mathew.gwy...@gmail.com wrote: Hi, The system information is given below - Host system uname -a: Linux cs-wsok 2.6.13-15.8-smp #1 SMP Tue Feb 7 11:07:24 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux CC Version gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ./configure --enable-languages=c,c++ --enable- threads=posix --enable-shared Thread model: posix Something is odd here. You need to have a compiler supporting Fortran, yet yours was compiled without Fortran support. I'm very surprised the 'prereq' script does not detect this, as it should check for a fortran compiler and confirm its the same version as the C and C++ compilers. So unless you have two installations of gcc, both of the same version, I don't know how you got this far. can you give me the outputs of $ command -v gcc $ command -v g++ $ command -v gfortran $ gcc -v $ g++ -v $ gfortran -v $ echo $LD_LIBRARY_PATH $ echo $CC $ echo $CXX $ echo SAGE_FORTRAN $ echo SAGE_FORTRAN_LIB Specifying the compiler locations with CC and CXX does not work too well Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Problems building Sage 4.4.1
Hi, The system information is given below - Host system uname -a: Linux cs-wsok 2.6.13-15.8-smp #1 SMP Tue Feb 7 11:07:24 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux CC Version gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ./configure --enable-languages=c,c++ --enable- threads=posix --enable-shared Thread model: posix gcc version 4.1.2 My colleague suggest that typically these errors are caused by missing -fPIC options when building (or something else must have gone wrong when building the libfpplll library). Thanks! Matthew On May 24, 2:14 pm, kcrisman kcris...@gmail.com wrote: On May 24, 9:11 am, kcrisman kcris...@gmail.com wrote: Dear Matthew, Thanks for your report. I know I can't answer your question fully :) but I can say that the most likely way to receive more specific info is to also post your OS, chip type if known, and any other info. One reason I say this might be relevant is the following I found doing a quick Google search for your error message, athttp://ugweb.cs.ualberta.ca/~rod/tutorials/error_messagesC.html: If you compile part of a project on one type of architecture and then try to compile the rest of the project on another type of architecture, when you go to make the final executable the linker/loader will NOT be able to read one of the parts of the project .o files to create an executable, thus the could not read symbols: File in wrong format error message. I'm not saying that's what the problem is, but information about your physical computer and its system will help enormously in tracking this down, especially if others have also experienced it. One more possible piece of useful info - any 32 versus 64 bit info you may have. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/sage-devel URL:http://www.sagemath.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Problems building Sage 4.4.1
On 26 May 2010 11:57, Matthew Gwynne mathew.gwy...@gmail.com wrote: Hi, The system information is given below - Host system uname -a: Linux cs-wsok 2.6.13-15.8-smp #1 SMP Tue Feb 7 11:07:24 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux CC Version gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ./configure --enable-languages=c,c++ --enable- threads=posix --enable-shared Thread model: posix Something is odd here. You need to have a compiler supporting Fortran, yet yours was compiled without Fortran support. I'm very surprised the 'prereq' script does not detect this, as it should check for a fortran compiler and confirm its the same version as the C and C++ compilers. So unless you have two installations of gcc, both of the same version, I don't know how you got this far. can you give me the outputs of $ command -v gcc $ command -v g++ $ command -v gfortran $ gcc -v $ g++ -v $ gfortran -v $ echo $LD_LIBRARY_PATH $ echo $CC $ echo $CXX $ echo SAGE_FORTRAN $ echo SAGE_FORTRAN_LIB Specifying the compiler locations with CC and CXX does not work too well Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Problems building Sage 4.4.1
On 25 Mai, 02:13, Dr. David Kirkby david.kir...@onetel.net wrote: On 05/24/10 05:26 PM, leif wrote: Looks like the (fairly old) gcc/g++ in /usr/local is misconfigured; it definitely tries to link a 64-bit (x86_64) C++ program against the 32- bit libstdc++.so (in /usr/local/lib) instead of the 64-bit version in / usr/local/lib64. (Actually it is forced to do so by libtool.) I'm not so convinced this failure with 'libfplll' is a gcc problem, but rather it is a 'libfplll' problem. I'm seeing the exact same issue with 'libfplll' on OpenSolaris. http://trac.sagemath.org/sage_trac/ticket/7864 The fact the original poster, his colleague and myself are all seeing this, suggests to me that perhaps libfplll may be at fault in trying to link 64-bit objects to 32-bit libstdc++ Other parts of the Sage build process are correctly using the 64-bit version of libstdc++.so on my OpenSolaris box - see for example this line. What I wanted to say is that installing another version of gcc in /usr/ local on systems (like Linux distros) where there already is a native one (gcc) in /usr is non-trivial, i.e. this doesn't work out of the box. With the native gcc, -lstdc++ is passed to the linker (which would have worked in Matthew's installation, too), while with gcc in /usr/ local its absolute filename is passed. These are snippets from install.log, the first is from Sage 4.4.2 on Ubuntu 9.04 x86_64 with native gcc (4.3.3), the second is from Sage 4.4.2.rc0 on Ubuntu 9.04 x86_64 with gcc 4.5.0 in /usr/local: * native gcc in /usr: -8--8--8--8--8--8-- g++ -DPACKAGE_NAME=\libfplll\ -DPACKAGE_TARNAME=\libfplll\ - DPACKAGE_VERSION=\3.0.12\ -DPACKAGE_STRING=\libfplll 3.0.12\ - DPACKAGE_BUGREPORT=\\ -DPACKAGE=\libfplll\ -DVERSION=\3.0.12\ - DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 - DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 - DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 - DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBGMP=1 -DHAVE_LIBMPFR=1 - DSTDC_HEADERS=1 -DHAVE_FLOAT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_STDLIB_H=1 - DHAVE_SYS_TIME_H=1 -DHAVE_UNISTD_H=1 -DHAVE_STDBOOL_H=1 -DHAVE_FLOOR=1 -DHAVE_POW=1 -DHAVE_RINT=1 -DHAVE_SQRT=1 -DHAVE_STRTOL=1 - DHAVE_LIBGMP=1 -DHAVE_LIBMPFR=1 -I. -I. -I/home/leif64/Sage/sage-4.4.2- too/local/include/ -fPIC -I/home/leif64/Sage/sage-4.4.2-too/local/ include/ -L/home/leif64/Sage/sage-4.4.2-too/local/lib -MT dummy.lo -MD -MP -MF .deps/dummy.Tpo -c dummy.cpp -fPIC -DPIC -o .libs/dummy.o g++ -DPACKAGE_NAME=\libfplll\ -DPACKAGE_TARNAME=\libfplll\ - DPACKAGE_VERSION=\3.0.12\ -DPACKAGE_STRING=\libfplll 3.0.12\ - DPACKAGE_BUGREPORT=\\ -DPACKAGE=\libfplll\ -DVERSION=\3.0.12\ - DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 - DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 - DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 - DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_LIBGMP=1 -DHAVE_LIBMPFR=1 - DSTDC_HEADERS=1 -DHAVE_FLOAT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_STDLIB_H=1 - DHAVE_SYS_TIME_H=1 -DHAVE_UNISTD_H=1 -DHAVE_STDBOOL_H=1 -DHAVE_FLOOR=1 -DHAVE_POW=1 -DHAVE_RINT=1 -DHAVE_SQRT=1 -DHAVE_STRTOL=1 - DHAVE_LIBGMP=1 -DHAVE_LIBMPFR=1 -I. -I. -I/home/leif64/Sage/sage-4.4.2- too/local/include/ -fPIC -I/home/leif64/Sage/sage-4.4.2-too/local/ include/ -L/home/leif64/Sage/sage-4.4.2-too/local/lib -MT dummy.lo -MD -MP -MF .deps/dummy.Tpo -c dummy.cpp -o dummy.o /dev/null 21 /bin/bash ./libtool --tag=CXX --mode=link g++ -fPIC -I/home/leif64/ Sage/sage-4.4.2-too/local/include/ -L/home/leif64/Sage/sage-4.4.2-too/ local/lib -o libfplll.la -rpath /home/leif64/Sage/sage-4.4.2-too/ local/lib -version-info 1:0:1 dummy.lo -lgmp -lmpfr -lmpfr -lgmp - lmpfr -lgmp g++ -shared -nostdlib /usr/lib/gcc/x86_64-linux-gnu/4.3.3/../../../../ lib/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.3.3/crtbeginS.o .libs/ dummy.o -Wl,--rpath -Wl,/home/leif64/Sage/sage-4.4.2-too/local/lib - Wl,--rpath -Wl,/home/leif64/Sage/sage-4.4.2-too/local/lib -L/home/ leif64/Sage/sage-4.4.2-too/local/lib /home/leif64/Sage/sage-4.4.2-too/ local/lib/libmpfr.so /home/leif64/Sage/sage-4.4.2-too/local/lib/ libgmp.so -L/home/leif64/Sage/sage-4.4.2-too/local/lib/../lib -L/usr/ lib/gcc/x86_64-linux-gnu/4.3.3 -L/usr/lib/gcc/x86_64-linux-gnu/ 4.3.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/ x86_64-linux-gnu/4.3.3/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/ x86_64-linux-gnu/4.3.3/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/ 4.3.3/../../../../lib/crtn.o -Wl,-soname -Wl,libfplll.so.0 -o .libs/ libfplll.so.0.1.0 (cd .libs rm -f libfplll.so.0 ln -s libfplll.so.0.1.0 libfplll.so.0) (cd .libs rm -f libfplll.so ln -s libfplll.so.0.1.0 libfplll.so) ar cru .libs/libfplll.a dummy.o ranlib .libs/libfplll.a creating libfplll.la (cd .libs rm -f libfplll.la ln -s ../libfplll.la libfplll.la) make[3]: Verlasse Verzeichnis '/home/leif64/Sage/sage-4.4.2-too/spkg/ build/libfplll-3.0.12.p0/src'
[sage-devel] Re: Problems building Sage 4.4.1
On 25 Mai, 11:18, leif not.rea...@online.de wrote: What I wanted to say is that installing another version of gcc in /usr/ local on systems (like Linux distros) where there already is a native one (gcc) in /usr is non-trivial, i.e. this doesn't work out of the box. With the native gcc, -lstdc++ is passed to the linker (which would have worked in Matthew's installation, too), while with gcc in /usr/ local its absolute filename is passed. Oops, the custom gcc is actually installed in /usr, not /usr/local, but this shouldn't matter... ;-) (It is configured with --enable-version-specific-runtime-libs and -- program-suffix=) -Leif -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Problems building Sage 4.4.1
Dear Matthew, Thanks for your report. I know I can't answer your question fully :) but I can say that the most likely way to receive more specific info is to also post your OS, chip type if known, and any other info. One reason I say this might be relevant is the following I found doing a quick Google search for your error message, at http://ugweb.cs.ualberta.ca/~rod/tutorials/error_messagesC.html : If you compile part of a project on one type of architecture and then try to compile the rest of the project on another type of architecture, when you go to make the final executable the linker/loader will NOT be able to read one of the parts of the project .o files to create an executable, thus the could not read symbols: File in wrong format error message. I'm not saying that's what the problem is, but information about your physical computer and its system will help enormously in tracking this down, especially if others have also experienced it. Best, - kcrisman On May 24, 8:45 am, Matthew Gwynne mathew.gwy...@gmail.com wrote: Hi, When building Sage 4.4.1, I (and also my colleague) get the following errors during the build process - /bin/sh ./libtool --tag=CXX --mode=link g++ -fPIC -I/home/csoliver/ SAT-Algorithmen/OKplatform/ExternalSources/Installations/Sage/ sage-4.4.1/local/include/ -L/home/csoliver/SAT-Algorithmen/OKplatform/ ExternalSources/Installations/Sage/sage-4.4.1/local/lib -o libfplll.la -rpath /home/csoliver/SAT-Algorithmen/OKplatform/ ExternalSources/Installations/Sage/sage-4.4.1/local/lib -version-info 1:0:1 dummy.lo -lgmp -lmpfr -lmpfr -lgmp -lmpfr -lgmp g++ -shared -nostdlib /usr/lib/../lib64/crti.o /usr/local/lib/gcc/ x86_64-unknown-linux-gnu/4.1.2/crtbeginS.o .libs/dummy.o -Wl,--rpath -Wl,/home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/ Installations/Sage/sage-4.4.1/local/lib -Wl,--rpath -Wl,/usr/local/ lib/../lib -Wl,--rpath -Wl,/home/csoliver/SAT-Algorithmen/OKplatform/ ExternalSources/Installations/Sage/sage-4.4.1/local/lib -Wl,--rpath - Wl,/usr/local/lib/../lib -L/home/csoliver/SAT-Algorithmen/OKplatform/ ExternalSources/Installations/Sage/sage-4.4.1/local/lib /home/csoliver/ SAT-Algorithmen/OKplatform/ExternalSources/Installations/Sage/ sage-4.4.1/local/lib/libmpfr.so /home/csoliver/SAT-Algorithmen/ OKplatform/ExternalSources/Installations/Sage/sage-4.4.1/local/lib/ libgmp.so -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.1.2 -L/usr/ local/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/../../../../x86_64- unknown-linux-gnu/lib -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/ 4.1.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 /usr/local/ lib/../lib/libstdc++.so -lm -lc -lgcc_s /usr/local/lib/gcc/x86_64- unknown-linux-gnu/4.1.2/crtendS.o /usr/lib/../lib64/crtn.o -Wl,- soname -Wl,libfplll.so.0 -o .libs/libfplll.so.0.1.0 /usr/local/lib/../lib/libstdc++.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status make[4]: *** [libfplll.la] Error 1 make[4]: Leaving directory `/home/csoliver/SAT-Algorithmen/OKplatform/ ExternalSources/Installations/Sage/sage-4.4.1/spkg/build/ libfplll-3.0.12.p0/src' Does anyone have any idea if I am doing something wrong, or whether this is a possible problem with Sage itself? Thanks! Matthew -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group athttp://groups.google.com/group/sage-devel URL:http://www.sagemath.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Problems building Sage 4.4.1
On May 24, 9:11 am, kcrisman kcris...@gmail.com wrote: Dear Matthew, Thanks for your report. I know I can't answer your question fully :) but I can say that the most likely way to receive more specific info is to also post your OS, chip type if known, and any other info. One reason I say this might be relevant is the following I found doing a quick Google search for your error message, athttp://ugweb.cs.ualberta.ca/~rod/tutorials/error_messagesC.html: If you compile part of a project on one type of architecture and then try to compile the rest of the project on another type of architecture, when you go to make the final executable the linker/loader will NOT be able to read one of the parts of the project .o files to create an executable, thus the could not read symbols: File in wrong format error message. I'm not saying that's what the problem is, but information about your physical computer and its system will help enormously in tracking this down, especially if others have also experienced it. One more possible piece of useful info - any 32 versus 64 bit info you may have. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Problems building Sage 4.4.1
On 24 Mai, 14:45, Matthew Gwynne mathew.gwy...@gmail.com wrote: When building Sage 4.4.1, I (and also my colleague) get the following errors during the build process - /bin/sh ./libtool --tag=CXX --mode=link g++ -fPIC -I/home/csoliver/ SAT-Algorithmen/OKplatform/ExternalSources/Installations/Sage/ sage-4.4.1/local/include/ -L/home/csoliver/SAT-Algorithmen/OKplatform/ ExternalSources/Installations/Sage/sage-4.4.1/local/lib -o libfplll.la -rpath /home/csoliver/SAT-Algorithmen/OKplatform/ ExternalSources/Installations/Sage/sage-4.4.1/local/lib -version-info 1:0:1 dummy.lo -lgmp -lmpfr -lmpfr -lgmp -lmpfr -lgmp g++ -shared -nostdlib /usr/lib/../lib64/crti.o /usr/local/lib/gcc/ x86_64-unknown-linux-gnu/4.1.2/crtbeginS.o .libs/dummy.o -Wl,--rpath -Wl,/home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/ Installations/Sage/sage-4.4.1/local/lib -Wl,--rpath -Wl,/usr/local/ lib/../lib -Wl,--rpath -Wl,/home/csoliver/SAT-Algorithmen/OKplatform/ ExternalSources/Installations/Sage/sage-4.4.1/local/lib -Wl,--rpath - Wl,/usr/local/lib/../lib -L/home/csoliver/SAT-Algorithmen/OKplatform/ ExternalSources/Installations/Sage/sage-4.4.1/local/lib /home/csoliver/ SAT-Algorithmen/OKplatform/ExternalSources/Installations/Sage/ sage-4.4.1/local/lib/libmpfr.so /home/csoliver/SAT-Algorithmen/ OKplatform/ExternalSources/Installations/Sage/sage-4.4.1/local/lib/ libgmp.so -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.1.2 -L/usr/ local/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/../../../../x86_64- unknown-linux-gnu/lib -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/ 4.1.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 /usr/local/ lib/../lib/libstdc++.so -lm -lc -lgcc_s /usr/local/lib/gcc/x86_64- unknown-linux-gnu/4.1.2/crtendS.o /usr/lib/../lib64/crtn.o -Wl,- soname -Wl,libfplll.so.0 -o .libs/libfplll.so.0.1.0 /usr/local/lib/../lib/libstdc++.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status make[4]: *** [libfplll.la] Error 1 make[4]: Leaving directory `/home/csoliver/SAT-Algorithmen/OKplatform/ ExternalSources/Installations/Sage/sage-4.4.1/spkg/build/ libfplll-3.0.12.p0/src' Does anyone have any idea if I am doing something wrong, or whether this is a possible problem with Sage itself? Looks like the (fairly old) gcc/g++ in /usr/local is misconfigured; it definitely tries to link a 64-bit (x86_64) C++ program against the 32- bit libstdc++.so (in /usr/local/lib) instead of the 64-bit version in / usr/local/lib64. (Actually it is forced to do so by libtool.) -Leif -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Problems building Sage 4.4.1
On 05/24/10 05:26 PM, leif wrote: On 24 Mai, 14:45, Matthew Gwynnemathew.gwy...@gmail.com wrote: When building Sage 4.4.1, I (and also my colleague) get the following errors during the build process - /bin/sh ./libtool --tag=CXX --mode=link g++ -fPIC -I/home/csoliver/ SAT-Algorithmen/OKplatform/ExternalSources/Installations/Sage/ sage-4.4.1/local/include/ -L/home/csoliver/SAT-Algorithmen/OKplatform/ ExternalSources/Installations/Sage/sage-4.4.1/local/lib -o libfplll.la -rpath /home/csoliver/SAT-Algorithmen/OKplatform/ ExternalSources/Installations/Sage/sage-4.4.1/local/lib -version-info 1:0:1 dummy.lo -lgmp -lmpfr -lmpfr -lgmp -lmpfr -lgmp g++ -shared -nostdlib /usr/lib/../lib64/crti.o /usr/local/lib/gcc/ x86_64-unknown-linux-gnu/4.1.2/crtbeginS.o .libs/dummy.o -Wl,--rpath -Wl,/home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/ Installations/Sage/sage-4.4.1/local/lib -Wl,--rpath -Wl,/usr/local/ lib/../lib -Wl,--rpath -Wl,/home/csoliver/SAT-Algorithmen/OKplatform/ ExternalSources/Installations/Sage/sage-4.4.1/local/lib -Wl,--rpath - Wl,/usr/local/lib/../lib -L/home/csoliver/SAT-Algorithmen/OKplatform/ ExternalSources/Installations/Sage/sage-4.4.1/local/lib /home/csoliver/ SAT-Algorithmen/OKplatform/ExternalSources/Installations/Sage/ sage-4.4.1/local/lib/libmpfr.so /home/csoliver/SAT-Algorithmen/ OKplatform/ExternalSources/Installations/Sage/sage-4.4.1/local/lib/ libgmp.so -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.1.2 -L/usr/ local/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/../../../../x86_64- unknown-linux-gnu/lib -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/ 4.1.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 /usr/local/ lib/../lib/libstdc++.so -lm -lc -lgcc_s /usr/local/lib/gcc/x86_64- unknown-linux-gnu/4.1.2/crtendS.o /usr/lib/../lib64/crtn.o -Wl,- soname -Wl,libfplll.so.0 -o .libs/libfplll.so.0.1.0 /usr/local/lib/../lib/libstdc++.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status make[4]: *** [libfplll.la] Error 1 make[4]: Leaving directory `/home/csoliver/SAT-Algorithmen/OKplatform/ ExternalSources/Installations/Sage/sage-4.4.1/spkg/build/ libfplll-3.0.12.p0/src' Does anyone have any idea if I am doing something wrong, or whether this is a possible problem with Sage itself? Looks like the (fairly old) gcc/g++ in /usr/local is misconfigured; it definitely tries to link a 64-bit (x86_64) C++ program against the 32- bit libstdc++.so (in /usr/local/lib) instead of the 64-bit version in / usr/local/lib64. (Actually it is forced to do so by libtool.) -Leif I'm not so convinced this failure with 'libfplll' is a gcc problem, but rather it is a 'libfplll' problem. I'm seeing the exact same issue with 'libfplll' on OpenSolaris. http://trac.sagemath.org/sage_trac/ticket/7864 The fact the original poster, his colleague and myself are all seeing this, suggests to me that perhaps libfplll may be at fault in trying to link 64-bit objects to 32-bit libstdc++ Other parts of the Sage build process are correctly using the 64-bit version of libstdc++.so on my OpenSolaris box - see for example this line. g++ -shared -nostdlib /usr/lib/amd64/crti.o /usr/lib/amd64/values-Xa.o /usr/local/gcc-4.4.4/lib/gcc/i386-pc-solaris2.11/4.4.4/amd64/crtbegin.o .libs/dummy.o cxx/.libs/isfuns.o cxx/.libs/ismpf.o cxx/.libs/ismpq.o cxx/.libs/ismpz.o cxx/.libs/ismpznw.o cxx/.libs/osdoprnti.o cxx/.libs/osfuns.o cxx/.libs/osmpf.o cxx/.libs/osmpq.o cxx/.libs/osmpz.o -Wl,-R -Wl,/export/home/drkirkby/sage-4.4.2/spkg/build/mpir-1.2.2.p1/src/.libs -Wl,-R -Wl,/usr/local/gcc-4.4.4/lib/amd64 -Wl,-R -Wl,/export/home/drkirkby/sage-4.4.2/local/lib -Wl,-R -Wl,/usr/local/gcc-4.4.4/lib/amd64 ./.libs/libgmp.so -L/usr/local/gcc-4.4.4/lib/gcc/i386-pc-solaris2.11/4.4.4/amd64 -L/usr/local/gcc-4.4.4/lib/gcc/i386-pc-solaris2.11/4.4.4/../../../amd64 -L/lib/amd64 -L/usr/lib/amd64 -L/export/home/drkirkby/sage-4.4.2/local/lib -L/usr/local/gcc-4.4.4/lib/gcc/i386-pc-solaris2.11/4.4.4 -L/usr/local/gcc-4.4.4/lib/gcc/i386-pc-solaris2.11/4.4.4/../../.. /usr/local/gcc-4.4.4/lib/amd64/libstdc++.so -lm -lgcc_s /usr/local/gcc-4.4.4/lib/gcc/i386-pc-solaris2.11/4.4.4/amd64/crtend.o /usr/lib/amd64/crtn.o -m64 -march=core2 -mtune=core2 -Wl,-h -Wl,libgmpxx.so.3 -o .libs/libgmpxx.so.3.1.6 where you can see that the 64-bit /usr/local/gcc-4.4.4/lib/amd64/libstdc++.so library is used, not the 32-bit library at /usr/local/gcc-4.4.4/lib/libstdc++.so So some parts of the Sage build process manage to work out that the 64-bit library should be used, but libfplll does not. I've found a similar issue with pynac. It would be intersting what the original poster gets if he runs: $ ./sage -f pynac-0.1.12 (or it might need to be) $ ./sage -f pynac-0.1.11 I would not be surprised if he sees the same problem. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more
