Jaap Spies wrote: > Hi Dave,
Hi Jaap > I tried to build gcc-4.4.2 from source, but failed. Got gcc-4.3.2 from the > repo. > Put gcc and friends in a directory $HOME/bin, changed my .bashrc so my path is GCC can be difficult to build on Solaris. > /usr/ccs/bin:/export/home/jaap/bin:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin That should not (will not) work!! There is a Sun version of 'make' in /usr/ccs/bin which will be unable to build Sage. Since that is first in your path, that should fail. One of the problems on Solaris is that a couple of the the Sun tools are not suitable. I've tried to make Sage have as little reliance as possible on GNU tools, but 'make' and 'tar' are two that it seems impossible to get around. http://trac.sagemath.org/sage_trac/ticket/7352 (Update prereq to version 0.5) was *supposed* to exit with an error if the versions of 'tar' and 'make' were not GNU ones on Solaris. However, I made a mistake and there was a '1' missing from an exit statement, so this did not throw an error. http://trac.sagemath.org/sage_trac/ticket/7781 ([with patches ; needs review] Update prereq to version 0.6) should fix that, and exit if the version of 'make' is not the GNU one. The updated 'prereq' will also exit if GNU 'tar' or 'make' are not used on AIX, HP-UX, Tru64 or IRIX. I must admit, I approached the port of Sage to Solaris thinking "William intends to support Sage on Solaris, I use Solaris, so I'll only worry about Solaris". I then realised that I was being a short sighted and it was desirable to try to make Sage more portable. Even if a port to HP-UX is never completed, being able to build large parts on HP-UX is useful for test purposes. It's found bugs that were not noticed on Linux or Solaris. Given the issue with 'make' I'm surprised you managed to get as far you di. Hopefully if #7781 gets reviewed and incorporated into Sage, such an error will be caught within the first minute of building Sage. >> Personally I buit gcc from source. >> >> bash-3.2$ /usr/local/gcc-4.3.4/bin/gcc -v >> Reading specs from >> /usr/local/gcc-4.3.4/bin/../lib/gcc/i386-pc-solaris2.11/4.3.4/specs >> Target: i386-pc-solaris2.11 >> Configured with: ../gcc-4.3.4/configure --prefix=/usr/local/gcc-4.3.4/ >> --with-as=/usr/local/binutils-2.20/bin/as --with-ld=/usr/ccs/bin/ld >> --without-gnu-ld --enable-languages=c,c++,fortran >> Thread model: posix >> gcc version 4.3.4 (GCC) >> > > I 'll try again some time with new gcc. I believe you will need to use the GNU version of make to build gcc. I may be wrong on that, but I suspect you will. You will certainly need to in order to build Sage. >> 5) Build OpenSSL - the defaults seem to work well, and produce a 64-bit >> binary. >> It installs in /usr/local/ssl, which is fine, as python, which needs the >> library, looks in. >> >> Again, you can use the package manager to install that for you. >> > > Built openssl-0.9.8l from source. Seems to work. Yes, agreed. Though you might note it configures in a 64-bit mode, and builds only 64-bit libraries. >> 6) Although I've not tried it, I would be tempted to export SAGE64 to 'yes' >> and >> go directly for a 64-bit build. >> >> 7) Type make. You will probably hit this bug. >> >> http://trac.sagemath.org/sage_trac/ticket/7387 >> > > My build stopped at libcrypt: > ld: fatal: file > /export/home/jaap/Downloads/sage-4.3/local/lib/libgpg-error.so: wrong ELF > class: ELFCLASS32 > ld: fatal: file processing errors. No output written to > .libs/libgcrypt.so.11.5.2 > Reinstalling with ./sage -f -m libgpg_error-1.6.p2, ./sage -sh > cd spkg/build/libgpg-1.6.p2 > changint the spkg-install: > CFLAGS="$CFLAGS -fPIC -g -I$SAGE_LOCAL/include" > > if [ `uname` = "Darwin" -a "$SAGE64" = "yes" ]; then > CFLAGS="-m64 -fPIC -g -I$SAGE_LOCAL/include" > LDFLAGS="-m64"; export LDFLAGS > fi > > if [ `uname` = "SunOS" -a "$SAGE64" = "yes" ]; then > CFLAGS="-m64 -fPIC -g -I$SAGE_LOCAL/include" > LDFLAGS="-m64"; export LDFLAGS > fi That will be ok, but much better is if [ `"$SAGE64" = "yes" ]; then CFLAGS="-m64 -fPIC -g -I$SAGE_LOCAL/include" LDFLAGS="-m64"; export LDFLAGS fi If anyone exports SAGE64 to "yes", on any platform - AIX, HP-UX, Solaris, OS X, or even a Nokia mobile phone (thinking of the future), then they want a 64-bit build. We should not try to stop them. > export CFLAGS > > and run ./spkg-install > > exit, run make again (no touch spkg/installed/libgpg_error-1.6.p2 needed, > because > it was already installed) > > libcrypt builds now in 64 bit mode. But next > ld: fatal: file /export/home/jaap/Downloads/sage-4.3/local/lib/libgcrypt.so: > wrong ELF class: ELFCLASS64 > ld: fatal: file processing errors. No output written to > .libs/libopencdk.so.10.0.6 "wrong ELF class" is a common error, and occurs when you try to mix 32 and 64-bit objects. If you decide to start a 32-bit build, then change your mind and want to do 64-bit build, you will have to run 'make distclean' first, to get rid of the 32-bit object. > The story gets long ... I know. Open Solaris is not not without its issues just now. > Same trick as above, this time don't forget to do a touch > spg/installed/opencdk-0.6.6.p2 > or you will have to do it over again. > > libpng -s also built in 32 bit > This brings me to ticket 7387 > ld: fatal: file /export/home/jaap/Downloads/sage-4.3/local/lib/libgcrypt.so: > wrong ELF class: ELFCLASS64 > ld: fatal: file processing errors. No output written to > .libs/libgnutls.so.26.1.2 Not exactly. #7387 shows gnutls will not build, but the reasons have nothing to do with the wrong ELF class. > adding > if [ `uname` = "SunOS" -a "$SAGE64" = "yes" ]; then > echo "64 bit SunOS" > CFLAGS="-O2 -g -m64 "; export CFLAGS > CXXFLAGS="-O2 -g -m64 "; export CXXFLAGS > fi > to the spkg-install did the trick > I'll comment on the ticket. > >> There is a hack listed to get rid of that. >> But that hack is for a different problem, not ELF class mis-matches. > Eventually I have to change a lot os spkg-install files! Yes. What I hope to do very soon, is to produce a new version of sage-env, which will put the -m64 flag in CFLAGS, so it never needs to be set in any spkg-install. All an spkg-install will need to do is use CFLAGS, then append anything it wants. That will add * -m64 -g -Wall for gcc * -m64 for Sun Studio * -q64 for IBM's compiler on AIX * +DA2.0W for HP's compiler on HP-UX That way, the appropriate flag will be added automatically on any half-reasonable platform. If someone wanted to build Sage on the very high spec Cuda processors from NVida, so we would just add the appropiate flags for the compiler there. > libz, termcap, readline and I'm certainly not finished :(! >> 8) Hopefully you wont hit bug >> >> http://trac.sagemath.org/sage_trac/ticket/7761 >> >> as you would have installed OpenSSL libraries. >> > > Building python failed with the same message as on the ticket! > > After running python manually: > sage subshell$ python > Python 2.6.2 (r262:71600, Dec 31 2009, 19:17:59) > [GCC 4.3.2] on sunos5 > Type "help", "copyright", "credits" or "license" for more information. > >>> 1+1 > 2 > >>> > > I declared it ok for the moment, so touch spkg/installed/python-2.6.2.p4 Yes, that will get you a lot further, since without python, not much will work. However, ultimitely the build will fail, as python does not have the needed cryptographic support it needed. >> At that point, you will be up with me really. I've not got much further than >> that. I posted a list the other day of packages which do and do not build. I >> used >> > > I got stuck at mpir: > checking whether to enable maintainer-specific portions of Makefiles... no > configure: error: ABI=64 is not among the following valid choices: 32 > Failed to configure. It seems you have a bit of a mix of 32 and 64-bit objects, which is doomed. But we have not before tried I just tried a 64-bit build myself, and it failed with "wrong ELF class: ELFCLASS32" in libgcrypt-1.4.4.p1. Clearly something is wrong. A look in $SAGE_LOCAL/lib shows how mixed up the packages things are: These are built 32-bit: bash-3.2$ file * | grep 32 libgpg-error.so: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped libgpg-error.so.0: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped libgpg-error.so.0.4.0: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped libz.so: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped libz.so.1: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped libz.so.1.2.3: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped bash-3.2$ file * | grep 32 libgpg-error.so: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped libgpg-error.so.0: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped libgpg-error.so.0.4.0: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped libz.so: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped libz.so.1: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped libz.so.1.2.3: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped And these are built 64-bit. libhistory.so: ELF 64-bit LSB dynamic lib AMD64 Version 1 [CMOV], dynamically linked, not stripped libhistory.so.6: ELF 64-bit LSB dynamic lib AMD64 Version 1 [CMOV], dynamically linked, not stripped libreadline.so: ELF 64-bit LSB dynamic lib AMD64 Version 1 [SSE CMOV], dynamically linked, not stripped libreadline.so.6: ELF 64-bit LSB dynamic lib AMD64 Version 1 [SSE CMOV], dynamically linked, not stripped libsqlite3.so: ELF 64-bit LSB dynamic lib AMD64 Version 1 [SSE2 SSE CMOV FPU], dynamically linked, not stripped libsqlite3.so.0: ELF 64-bit LSB dynamic lib AMD64 Version 1 [SSE2 SSE CMOV FPU], dynamically linked, not stripped libsqlite3.so.0.8.6: ELF 64-bit LSB dynamic lib AMD64 Version 1 [SSE2 SSE CMOV FPU], dynamically linked, not stripped As you can see, there are many packages which need changing. But really this 64-bit stuff should be done more globally. Not only would it be easier to maintain, but it would with minor changes worth with any compiler. It seems to be quite inevitable that someone will at some point be building Sage on mobile phones and similar devices (some have tried already). It also seems inevitable that someone will try on high performance systems like Cuda. It's quite likely different compilers may be used, needing different options. As much as possible needs to be in one place, not in 100 different .spkg files. 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
