Dr. David Kirkby wrote: > 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. >
I now have: j...@opensolaris:~/Downloads/build-gcc-4.4.2$ /usr/local/gcc-4.4.2/bin/gcc -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc-4.4.2/configure --prefix=/usr/local/gcc-4.4.2 --with-gmp=/usr/local --with-mpfr=/usr/local --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++,fortran Thread model: posix gcc version 4.4.2 (GCC) j...@opensolaris:~/Downloads/build-gcc-4.4.2$ which as /usr/ccs/bin/as So as you suggested I'll do it again with an other as from binutls-2.20. >> /usr/ccs/bin:/export/home/jaap/bin:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin > > That should not (will not) work!! > It works because I move make out of the way! mv make sunmake j...@opensolaris:~/Downloads/sage-4.3$ which make /usr/gnu/bin/make j...@opensolaris:~/Downloads/sage-4.3$ which tar /usr/gnu/bin/tar > 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) > I'll look into that. > 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. > There wasn't a make issue. > >>> 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. > I understand. See above. >>> 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. > For the moment this is all I need as I'm building with SAGE64="yes" > >>> 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. > Agreed. >> 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. > +1 >> 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. >>> >> [...] >> 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: > I rebuild all libs involved. > 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. > As you stated before many spkgs are not in a good shape to handle this. I'm surprised I got so far j...@opensolaris:~/Downloads/sage-4.3$ ls spkg/installed bzip2-1.0.5 gnutils-2.2.1.p4 libpng-1.2.35 readline-6.0.p1 termcap-1.3.1.p0 cliquer-1.2.p2 gnutls-2.2.1.p4 opencdk-0.6.6.p2 sage_scripts-4.3 zlib-1.2.3.p4 conway_polynomials-0.2 libgcrypt-1.4.4.p1 prereq-0.5 scons-1.2.0 dir-0.1 libgpg_error-1.6.p2 python-2.6.2.p4 sqlite-3.6.19.p0 All built in 64 bit mode. Cheers, Jaap > 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
