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
Re: [sage-devel] Re: Problems building Sage 4.4.1
On 8 June 2010 17:17, Matthew Gwynne 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 wrote: >> On 26 May 2010 11:57, Matthew Gwynne 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
Re: [sage-devel] Re: Problems building Sage 4.4.1
On 26 May 2010 11:57, Matthew Gwynne 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 05/24/10 05:26 PM, leif wrote: On 24 Mai, 14:45, Matthew Gwynne 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 options, visit this group at
