SAGE is a Python based computer algebra system. Reproducible: Always
Created attachment 137773 [details] sage-2.8.15.ebuild
You should indicate that your ebuild is for the binary version. I took an interest in sage recently looking at building from sources (for arches other than x86 you know). The main problem is that it come with the sources for stuff that is already in portage and has a very bad building system in that you cannot use stuff that you already have installed at _all_. It is fully "integrated" with its own internal packaging system.
This is the source version. I'm compiling it on a ppc machine right now. I agree with you that the SAGE build system is very poorly designed. I have to admit, it seems like it would be a huge pain to do security fixes.
My apologies, I misread the ebuild - it looked so short. Not only security but space. I haven't installed it on my ppc machine because I was lacking space-that I probably wouldn't if it was using the system maxima, mpfr and so on. I may give your ebuild a go later next week then.
SAGE finished compiling on my laptop but it doesn't seem to work. The interactive python shell starts up but the SAGE modules are failing to load. I'm not really sure why it works on my workstation but not on my laptop, but I'll try to figure it out.
I just install and I have the following error /usr/bin/env: sage.bin: No existe el fichero o el directorio /opt/sage/local/bin/sage-sage: /opt/sage/local/bin/sage-ipython: sage.bin: All links in /opt/sage/local/bin/sage-sage are broken. Where it is supposed have to link sage.bin?
I am not sure about the sed line in the ebuild. If we follow the install instructions we want to change SAGE_ROOT="....." (and the dots are really in that file) by SAGE_ROOT="/opt/sage/" And that's it. What do you have in /opt/sage/sage? The more I look at the sage script the more I think it doesn't do the right thing.
cruzki: I just want to make sure, you are running either /opt/bin/sage or /opt/sage/sage, correct? On my computer, I don't get that error because /opt/sage/local/bin is being added to PATH, but I haven't figured out where this happens yet. Francois Bissey: /opt/sage/sage is one of the files that sed is acting on. SAGE_ROOT is being set to /opt/sage.
It seems that the reason SAGE isn't working on my laptop is that the install script is running gfortran from a symlink, which gfortran doesn't like. I'm not sure why it worked on my workstation.
Created attachment 138064 [details, diff] sage-2.8.15-fortran-symlink.patch This should fix the problem with the fortran symlinks.
Created attachment 138066 [details] sage-2.8.15.ebuild
@Daniel Gulotta With both options I have the same error. Even if I add /opt/sage/local/bin to PATH I still have the same error.
cruzki: Could you check if there are any error messages at the end of /opt/sage/install.log?
Current ebuild fails to compile for me, with the following error: configure: error: ABI=amd64 is not among the following valid choices: 64 32 Failed to configure. I'm using an amd64-based system (nocona, to be specific), so that's probably why.
It seems that gmp handles the ABI variable in a nonstandard way. There is a workaround for it in the gmp ebuild. Things like this lead me to believe that the only way to write an ebuild for SAGE that anyone is going to want to maintain is to make it use packages that are already in Portage as much as possible. There is a similar effort going on right now for Debian (http://groups.google.com/group/debian-sage/). I'm not sure that I have the time or the patience to attempt this, but I am considering it. Of course, any help would be greatly appreciated.
I have the same problem as Randall Wald.
Created attachment 141407 [details] ebuild for sage-2.10 This is an ebuild for the latest version of sage, sage moves very fast so it will be superceded in about 2 weeks. This ebuild start using basic stuff provided by portage rather than internally. It's baby steps - but people who don't want to rebuild atlas because they already have it on their system and it takes forever to tune will be happy. Note that sage-2.10.1 will provide a way to do that out of the box. I savaged their fortran package to impose gfortran everywhere. It needs the following files in the "files" folder: which_fortran sage_fortran prereq.patch deps.patch scipy.patch scipy_sandbox.patch cvxopt.patch Pulling other things out will require attention and probably the set up of an overlay. gmp for example needs a patch. sage is picky about versions: maxima-5.13 is required, 5.14 cause 4 tests (sage -testall) to fail. This version fails on one test called qqbar.py, don't know why yet (gsl1.10 instead of 1.9, dodgy atlas/lapack? -if you test with gsl-1.9 and it pass the test let me know.)
Created attachment 141408 [details] needed for sage-fortran setup.
Created attachment 141410 [details] needed for sage-fortran setup (as well).
Created attachment 141412 [details, diff] patch the sage dependency tree to remove packages provided by portage
Created attachment 141414 [details, diff] patch the prereq file.
Created attachment 141416 [details, diff] patch sage internal scipy to find portage installed atlas/lapack
Created attachment 141417 [details, diff] patch sage internal scipy_sandbox to find portage installed atlas/lapack
Created attachment 141418 [details, diff] patch cvxopt internal package to remove dependency on libf77blas.
Created attachment 142615 [details] update ebuild to sage-2.10.1 Sage-2.10.1 has been released and here is an updated/cleaned ebuild. I bumped a number of requirements to match (gnutls and gsl) versions included in sage. I updated the maxima warning with more info, added an einfo section about licences. I bumped some patches, I cannot unfortunately reduce the number any further. The cvxopt patch is still valid but the file should be renamed cvxopt-0.9.p5.patch. It also still needs attachments 141408 and 14110. This is raw and not tested apart from the fact that the patches apply correctly. The test failure of 2.10 has been taken care of upstream. Also I didn't mention it for 2.10 but it should take care of all the problems mentioned in earlier post. If it doesn't I can take it upstream. A method for using atlas from the system has landed but it is not usable by Gentoo in its current state. I have been working on replacing sage python components by Gentoo provided ones but progress is slow. Also I'd really like feedback, even if it is to tell me you are using it successfully (you can send a private email for that) so I now I really can continue working on this. Progress will be further slowed down by my impeding fatherhood so I may miss a few releases.
Created attachment 142616 [details, diff] patch to deps and prereq-0.3-install for sage-2.10.1
Created attachment 142618 [details, diff] updated patch to the internal copy of scipy
Created attachment 142619 [details, diff] updated patch to the internal copy of scipy_sandbox
Created attachment 143099 [details] 2.10.1 ebuild revision to include gmp patch OK new ebuild for 2.10.1. It should solve the ABI issue on amd64. Thanks for serial_penguin on the forum for testing. However serial_penguin had a lot of failures in the test suite. So it needs wider testing preferably under both x86 and amd64 (ppc and ppc64 welcome as well). More discussions over at: http://forums.gentoo.org/viewtopic-p-4840637.html
Created attachment 143100 [details, diff] combined gmp patches from the forum
Hi, still fails to build on my machine (x86). Here is the error and emerge --info. Thanks for your effort: building 'numpy.linalg.lapack_lite' extension compiling C sources C compiler: gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC creating build/temp.linux-i686-2.5/numpy/linalg compile options: '-DNO_ATLAS_INFO=1 -Inumpy/core/include -Ibuild/src.linux-i686-2.5/numpy/core -Inumpy/core/src -Inumpy/core/include -I/var/tmp/portage/sci-mathematics/sage-2.10.1-r1/work/sage-2.10.1/local/include/python2.5 -c' gcc: numpy/linalg/lapack_litemodule.c /usr/bin/gfortran -Wall -Wl,-O1 build/temp.linux-i686-2.5/numpy/linalg/lapack_litemodule.o -L/usr/lib -llapack -lblas -lgfortran -o build/lib.linux-i686-2.5/numpy/linalg/lapack_lite.so build/temp.linux-i686-2.5/numpy/linalg/lapack_litemodule.o: In function `initlapack_lite': /var/tmp/portage/sci-mathematics/sage-2.10.1-r1/work/sage-2.10.1/spkg/build/numpy-20080104-1.0.4.p2/src/numpy/linalg/lapack_litemodule.c:827: undefined reference to `Py_InitModule4' build/temp.linux-i686-2.5/numpy/linalg/lapack_litemodule.o: In function `_import_array': /var/tmp/portage/sci-mathematics/sage-2.10.1-r1/work/sage-2.10.1/spkg/build/numpy-20080104-1.0.4.p2/src/build/src.linux-i686-2.5/numpy/core/__multiarray_api.h:945: undefined reference to `PyImport_ImportModule' /var/tmp/portage/sci-mathematics/sage-2.10.1-r1/work/sage-2.10.1/spkg/build/numpy-20080104-1.0.4.p2/src/build/src.linux-i686-2.5/numpy/core/__multiarray_api.h:948: undefined reference to `PyObject_GetAttrString' /var/tmp/portage/sci-mathematics/sage-2.10.1-r1/work/sage-2.10.1/spkg/build/numpy-20080104-1.0.4.p2/src/build/src.linux-i686-2.5/numpy/core/__multiarray_api.h:950: undefined reference to `PyCObject_Type' /var/tmp/portage/sci-mathematics/sage-2.10.1-r1/work/sage-2.10.1/spkg/build/numpy-20080104-1.0.4.p2/src/build/src.linux-i686-2.5/numpy/core/__multiarray_api.h:958: undefined reference to `PyExc_RuntimeError' . . . build/temp.linux-i686-2.5/numpy/linalg/lapack_litemodule.o: In function `lapack_lite_dgeev': /var/tmp/portage/sci-mathematics/sage-2.10.1-r1/work/sage-2.10.1/spkg/build/numpy-20080104-1.0.4.p2/src/numpy/linalg/lapack_litemodule.c:165: undefined reference to `Py_BuildValue' /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgfortranbegin.a(fmain.o): In function `main': (.text+0x23): undefined reference to `MAIN__' collect2: ld returned 1 exit status error: Command "/usr/bin/gfortran -Wall -Wl,-O1 build/temp.linux-i686-2.5/numpy/linalg/lapack_litemodule.o -L/usr/lib -llapack-lblas -lgfortran -o build/lib.linux-i686-2.5/numpy/linalg/lapack_lite.so" failed with exit status 1 Error building numpy. real 2m29.308s user 1m52.603s sys 0m5.537s sage: An error occurred while installing numpy-20080104-1.0.4.p2 Please email sage-devel http://groups.google.com/group/sage-devel explaining the problem and send the relevant part of of /var/tmp/portage/sci-mathematics/sage-2.10.1-r1/work/sage-2.10.1/install.log. Describe your computer, operating system, etc. If you want to try to fix the problem, yourself *don't* just cd to /var/tmp/portage/sci-mathematics/sage-2.10.1-r1/work/sage-2.10.1/spkg/build/numpy-20080104-1.0.4.p2 and type 'make'. Instead type "/var/tmp/portage/sci-mathematics/sage-2.10.1-r1/work/sage-2.10.1/sage -sh" in order to set all environment variables correctly, then cd to /var/tmp/portage/sci-mathematics/sage-2.10.1-r1/work/sage-2.10.1/spkg/build/numpy-20080104-1.0.4.p2 (When you are done debugging, you can type "exit" to leave the subshell.) make[1]: *** [installed/numpy-20080104-1.0.4.p2] Error 1 make[1]: Leaving directory `/var/tmp/portage/sci-mathematics/sage-2.10.1-r1/work/sage-2.10.1/spkg' ------------------- denkmatte tom # emerge --info Portage 2.1.3.19 (default-linux/x86/2007.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.23-gentoo-r3 i686) ================================================================= System uname: 2.6.23-gentoo-r3 i686 Mobile Intel(R) Pentium(R) III CPU - M 1200MHz Timestamp of tree: Wed, 13 Feb 2008 07:16:01 +0000 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.4 [enabled] app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.1.4 dev-lang/python: 2.4.4-r6 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 1.12.10-r5 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium3m -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/4.0/env /usr/kde/4.0/share/config /usr/kde/4.0/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=pentium3m -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://pandemonium.tiscali.de/pub/gentoo/ " LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="en de ja es fr it" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/sunrise /usr/portage/local/layman/science /usr/portage/local/layman/kde /usr/portage/local/layman/tom-overlay" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi alsa anthy apache2 arts avahi bash-completion berkdb bitmap-fonts bluetooth bzip2 cairo canna cddb cdparanoia cdr cjk cli cracklib crypt ctype cups curl daap dbus dri dvd dvdr dvdread eds emacs encode esd evo expat fam fbcon ffmpeg firefox flac fortran freewnn ftp gd gdbm gif glut gmp gphoto2 gpm graphviz gstreamer gtk guile hal iconv ieee1394 imagemagick imap imlib ipod ipv6 isdnlog java javascript jpeg kde kerberos ldap leim libnotify lm_sensors m17n-lib mad midi migemo mikmodmime mmx mp3 mp4 mpeg mplayer mudflap mule musicbrainz mysql mysqli ncurses networkmanager nls nptl nptlonly nsplugin obex ocaml ogg oggvorbis openal opengl openmp oss pam pcmcia pcre pdf perl php plotutils png pppd python qt3 qt3support qt4 quicktime readline real reflection samba sasl sdl session slang spell spl sqlite3 sse ssl svg tcpd tetex theora tiff tk truetype truetype-fonts type1-fonts unicode usb vhosts vim vim-syntax visualization vorbis wifi win32codecs wxwindows x86 xine xml xorg xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" FRITZCAPI_CARDS="fcpcmcia" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en de ja es fr it" USERLAND="GNU" VIDEO_CARDS="i810 vesa" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Someone actually reported a similar error in the forum thread I mention in comment #29. It turns out that you have to make sure that the files: which_fortran and sage_fortran that you got from this bug are executable. (chmod 0755). That should solve this problem. Post here or in the forum if you have another problem.
I'm not allowed to do that, but someone should now remove the version number from the summary field. I'm looking forward to seeing this ebuild in the official tree. ++
I am not sure the title can be changed. May be the original poster can. Anyway I am not sure sage will make it to the official tree any time soon, and if it does it will be outdated as sage has a release every 2 to 3 weeks currently. Anyway if you want to test I have now a mini overlay as a tarball on demand, I may find some web space to post it properly. But there are a lot of problems with the ebuild of the latest releases. Tests are failing and no clue where to look. On amd64 python shipped with sage seem to have the dreaded double free bug when built in portage. So if you want it you will have to be ready to step up for testing and reporting at least.
*** Bug 220039 has been marked as a duplicate of this bug. ***
Folks, Thanks much for the great work! I've been keeping an eye on sage but haven't had much time to look at it in any depth. Maybe we can get an ebuild into the science overlay for a bit more testing. best, Markus
(In reply to comment #36) > Folks, > > Thanks much for the great work! I've been keeping an eye > on sage but haven't had much time to look at it in any > depth. Maybe we can get an ebuild into the science overlay > for a bit more testing. > Hi Markus, I guess being in the official science overlay would be nice. I am currently making progress splitting sage into its components. A number of packages currently in the portage tree should be updated (pari, ntl, singular and may be a few other - I can provide ebuilds for a few of them). Then there is a few ugly cases that I am not sure how to handle like gmp. Sage use an experimental upstream patch deemed stable but not officially included. I have a patched ebuild of gmp and it works for me and a few other - but as it is not fixing anything broken I don't know it would become an official part of Gentoo. Also sage uses sympy which is currently in the sunrise overlay if we bring a split sage in the science overlay it would be nice to have it moved in the science overlay. I guess I could become a proxy maintainer for sage once we get something usable again. I am thinking of Gentoo dev-hood, in the science herd even, but I don't think my 3 month old will let me have enough time for that. Nice to have some dev listening.
(In reply to comment #37) > A number of packages currently in the portage > tree should be updated (pari, ntl, singular and may be a few > other - I can provide ebuilds for a few of them). Please just file bugs for them if you are aware of any version bumps. If you can provide ebuilds or a simple "old ebuild works by just renaming" that would be even better :) > Then there is a few ugly cases that I am not sure how to handle > like gmp. Sage use an experimental upstream patch deemed stable > but not officially included. I have a patched ebuild of gmp > and it works for me and a few other - but as it is not fixing > anything broken I don't know it would become an official part > of Gentoo. If the patch looks reasonable and doesn't break anything I don't see why we couldn't add it to support other packages (such as sage) in the tree. > I am thinking of Gentoo dev-hood, in the > science herd even, but I don't think my 3 month old will let me > have enough time for that. :) > > Nice to have some dev listening. > We do listen, but due to missing manpower it is (very unfortunately) simply impossible to follow up and comment on everything. cheers, Markus
Has someone already created patches and ebuild for the current sage-3.0.2?
(In reply to comment #39) > Has someone already created patches and ebuild for the current sage-3.0.2? > I have made some progress and will start to put more stuff on Bugzilla. I hope to have a whole split sage in the 3.0.4 time frame. Otherwise aiming for 3.1 .
Can someone with enough power make bug #49282 block this one? Neither the sage bug or the gap belongs to me so I can't. Francois
(In reply to comment #41) > Can someone with enough power make bug #49282 block this one? > Neither the sage bug or the gap belongs to me so I can't. > Hi Francois, It looks like this bug already depends on #49282 or did I misunderstand your request? Best, Markus
> Hi Francois, > > It looks like this bug already depends on #49282 or did I > misunderstand your request? I just made the dependency today. sage and deps would greatly benefit from a science overlay testing bed. We should start review all these ebuilds. Thanks for your work.
(In reply to comment #43) > > Hi Francois, > > > > It looks like this bug already depends on #49282 or did I > > misunderstand your request? > > I just made the dependency today. > sage and deps would greatly benefit from a science overlay testing bed. We > should start review all these ebuilds. > Thanks for your work. > Thanks guys. I actually would like to get stuff into bugzilla for the upcoming 3.0.4 release and there are a number of issues including gap (bug #49282) to discuss. *In my own overlay I created a category called dev-sage for stuff that solely belongs to sage or is in a special "sage" state (sage ship a snapshot of ipython1 for example). *Sage releases have somewhat slowed downed since 3.0 but it still moving fast and individual spkg (sage tar.bz2 tarball) are removed from their server to be replaced by the new ones. The only way to get old spkg is to download a full release containing it - that will create trouble unless we decide to get stuff from the release tarball. This would negate some benefits of split ebuild. *I have a simple eclass that has evolved from the time I was trying monolithic build it has some cruft not used anymore unless someone wants to make a new monolithic ebuild. That's it for now. I am hanging in irc (kiwi_fb is my current nick for a bit).
I have a _binary_ package ebuild for Sage 3.1.2 in the science overlay. See http://bugs.gentoo.org/show_bug.cgi?id=240622
Created attachment 208108 [details] sage-4.1.2.ebuild This ebuild builds sage the monolithic, everything plus the kitchen sink way that the Sage developers want you to build it. Every single Sage dependency is included within Sage's own packaging system which probably duplicates many packages already installed. Sage does keep track of it's packages within it's own directory so it isn't a question of conflicting with installed Gentoo packages, but still not the Gentoo way at all.
Thanks for supplying the ebuild - compiled fine on my i686 machine but install fails with an access violation: ... Sage build/upgrade complete! >>> Source compiled. --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE "/var/log/sandbox/sandbox-8418.log" VERSION 1.0 FORMAT: F - Function called FORMAT: S - Access Status FORMAT: P - Path as passed to function FORMAT: A - Absolute Path (not canonical) FORMAT: R - Canonical Path FORMAT: C - Command Line F: open_wr S: deny P: /etc/ld.so.cache~ A: /etc/ld.so.cache~ R: /etc/ld.so.cache~ C: ldconfig F: unlinkat S: deny P: /lib/libecm.* A: /lib/libecm.* R: /lib/libecm.* C: rm -f /lib/libecm.* -------------------------------------------------------------------------------- Do you know how to fix this ?
No. I don't know how to fix, yet. Will do some research. Is the pasted in portion the contents of /var/log/sandbox/sandbox-8418.log? If not, could you post? How long did it take to compile? Kindest regards, Tim
(In reply to comment #48) > No. I don't know how to fix, yet. Will do some research. Is the pasted in > portion the contents of /var/log/sandbox/sandbox-8418.log? If not, could you > post? How long did it take to compile? > Hi guys, it looks like to losely based that ebuild on some of my earlier work. I may be able to help. In fact I may be able to have another shot at packaging sage in the next few weeks. Hopefully it won't be shot of course at the last minute like last time. I very much would like to see the complete sandbox violation file as well. gzip it and attach it to the bug, it would also be interesting to have the build log as well, sometime build can continue while a component has failed (especially true of the optional ones). I have some idea of what is wrong from the 2 lines posted but I will have to see the latest iteration of the sage build system.
Tim Cera: Yes, the sandbox file does not contain more infomation as pasted. Francois Bissey: The build took about 208 minutes (see also at the end of the build log)
If you would like to see my complete build log, download from: http://www.students.uni-mainz.de/cschwan/sage-build.log.tar.bz2 (File is too big for bugzilla).
(In reply to comment #51) > If you would like to see my complete build log, download from: > > http://www.students.uni-mainz.de/cschwan/sage-build.log.tar.bz2 > > (File is too big for bugzilla). > Thank you so much! One of the violation occurred much earlier during the building process and points to an error in the coding of ecm spkg (I think): ecm-6.2.1.p0/.hg/00changelog.i ecm-6.2.1.p0/spkg-check Finished extraction **************************************************** Host system uname -a: Linux gnuke-notebook 2.6.31-gentoo-r3 #1 PREEMPT Wed Oct 14 21:01:01 CEST 2009 i686 Intel(R) Pentium(R) M processor 1.73GHz GenuineIntel GNU/Linux **************************************************** **************************************************** CC Version gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.3.4/work/gcc-4.3.4/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.3.4 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.4 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.4/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.4/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --disable-fixed-point --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --disable-libgomp --disable-libgcj --with-arch=i686 --enable-languages=c,c++,treelang,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.4 p1.0, pie-10.1.5' Thread model: posix gcc version 4.3.4 (Gentoo 4.3.4 p1.0, pie-10.1.5) **************************************************** Removing old binary, headers and static library [31;01mACCESS DENIED[0m unlinkat: /lib/libecm.* rm: cannot remove `/lib/libecm.*': Permission denied rm: cannot remove `/var/tmp/portage/sci-mathematics/sage-4.1.2/work/sage-4.1.2/local/include/ecm.h': No such file or directory checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes I will look for the other one. I probably can do something about those. Sage-4.2 is out by the way....
OK found the error in ecm and filled a bug upstream in sage as it is a typo in the spkg-install file. The ldconfig call is more tricky - it looks like a change of the way sage is build that may need to be addressed.
If this helps I didn't have a sandbox violation on AMD64. I do use paludis, but usually that means a stricter interpretation of the ebuild, rules, environement, ...etc. Trying 4.2 right now. Kindest regards, Tim
(In reply to comment #54) > If this helps I didn't have a sandbox violation on AMD64. I do use paludis, > but usually that means a stricter interpretation of the ebuild, rules, > environement, ...etc. > > Trying 4.2 right now. > Hi, not sure about paludis configuration but I have the following features enabled in /etc/make.conf I wonder if you have the paludis equivalent: FEATURES="parallel-fetch userfetch sandbox collision-protect ccache" I definitely recommend having sandbox and collision-protect if you develop ebuilds as it catch some QA (quality assurance) issue as reported by Christopher. Those 2 issues are not solved in 4.2. I think I found the origin of the ldconfig issue. Since there seems to be interest for a monolithic ebuild at this time I may post a patched ebuild later today to try to solve those issues. Testers are welcome as I lack the building power at the moment (which is one the reason split sage has stopped).
I can confirm this - 4.2 also failed to install, though i managed to write a patched ebuild which solves the first issue. If you post a new ebuild i am definitely willing to test it - we need sage in portage or at least an ebuild.
(In reply to comment #56) > I can confirm this - 4.2 also failed to install, though i managed to write a > patched ebuild which solves the first issue. If you post a new ebuild i am > definitely willing to test it - we need sage in portage or at least an ebuild. > My experience is that Gentoo sage testers experience fatigue :( Now which issue did you solve? ldconfig or ecm? And how, I think I have tracked down ldconfig to something not done right in pari and that's non-trivial if you fixed that somehow I want to see it.
Created attachment 208276 [details] revised ebuild for 4.2 with patch Resurrected a few functions that I had buried when moving to a split sage to make it easier to patch spkg. I am posting 2 patches to go with it. They are in the format requested by upstream if there is a problem I'll amend them. Happy testing.
Created attachment 208278 [details, diff] spkg patch to get rid of sandbox violiation from ecm
Created attachment 208279 [details, diff] tentative patch for the ldconfig sandbox violation. It should take care of some ldconfig error in the sage build but I am not 100% it will take care of the sandbox violation.
I fixed the ecm issue (found your bugreport on sagemath.org) in a similar way you did - I am currently compiling your new ebuild and i will report back if the patch works.
Ok tested your ebuild but unfortunately the pari patch did not fix the last sandbox violation issue. Your ebuild also contained a function src_prepare which does not get called (at least on my system). Also the patches you provided did not work since they were generated with mercurial - i have fixed this so that others can try to find the violation error. I also did some minor changes that were reported by repoman.
Created attachment 208383 [details] new ebuild still failing because of sandbox violation error
Created attachment 208385 [details, diff] fixes a typo in ecm spkg
Created attachment 208386 [details, diff] fix for pari spkg
Created attachment 208391 [details] Silly me forgot to make it EAPI=2 src_prepare didn't get called because I forgot to set EAPI=2 in the ebuild.
(In reply to comment #62) > Ok tested your ebuild but unfortunately the pari patch did not fix the last > sandbox violation issue. Your ebuild also contained a function src_prepare > which does not get called (at least on my system). Also the patches you > provided did not work since they were generated with mercurial - i have fixed > this so that others can try to find the violation error. I also did some minor > changes that were reported by repoman. > OK I am revising the patches it is almost certainly because of the folder "a" and "b" provided in the headers so patch doesn't know to apply them. Easily fixed with a minor edit. Could you provide your new build log somewhere for me to examine.
Created attachment 208393 [details, diff] revised ecm patch
Created attachment 208394 [details, diff] revised pari patch
Created attachment 208405 [details, diff] revision to pari-2.3.3.p5.patch I was unable to get the pari-2.3.3.p5 patch to take relative to the sage-4.2 ebuild. I've attached what I used. The patch file was renamed to that used by Francois (pari-2.3.3.p5.patch) so the sage-4.2 ebuild could be used.
I accidentally destroyed my build log :-/ - rebuilding will take its time. Francois, are you available on irc ? My nick is gnuke.
I uploaded my build.log to http://www.students.uni-mainz.de/cschwan/sage-build2.log.tar.bz2 - build fails because of the known ldconfig violation error.
Created attachment 208471 [details] sage startup log On an amd64 machine I was able to build and install sage using the sage-4.2 ebuild with the exception that the documentation could not be built ('sage -docbuild all html' failed). However, there are serious compilation issues since sage will not startup cleanly. I've attached a log of what happens when sage is started from the shell prompt.
(In reply to comment #73) > Created an attachment (id=208471) [details] > sage startup log > > On an amd64 machine I was able to build and install sage using the sage-4.2 > ebuild with the exception that the documentation could not be built > ('sage -docbuild all html' failed). However, there are serious compilation > issues since sage will not startup cleanly. I've attached a log of what happens > when sage is started from the shell prompt. > It looks to me as if the doc is not the only thing that failed - but the rest must have failed silently. Can you find a file called: ipy_profile_sage anywhere and post it for my post mortem?
(In reply to comment #72) > I uploaded my build.log to > http://www.students.uni-mainz.de/cschwan/sage-build2.log.tar.bz2 - build fails > because of the known ldconfig violation error. > could you go in: /var/tmp/portage/sci-mathematics/sage-4.2-r1/work/sage-4.2/local/lib/ and report the result of "ls -la libpari*" please.
Created attachment 208475 [details] ipy_profile_sage (In reply to comment #74) > (In reply to comment #73) > > Created an attachment (id=208471) [details] [details] > > sage startup log > > > > On an amd64 machine I was able to build and install sage using the sage-4.2 > > ebuild with the exception that the documentation could not be built > > ('sage -docbuild all html' failed). However, there are serious compilation > > issues since sage will not startup cleanly. I've attached a log of what happens > > when sage is started from the shell prompt. > > > It looks to me as if the doc is not the only thing that failed - but > the rest must have failed silently. Can you find a file called: > ipy_profile_sage anywhere and post it for my post mortem? > I've attached the file. I assume it's ipy_profile_sage.py
Francois: Here is a list of the libraries: -rwxr-xr-x 1 root root 3085961 Oct 27 09:35 libpari-gmp.so.2 -rwxr-xr-x 1 root root 3085961 Oct 27 09:35 libpari-gmp.so.2.3.3 -rw-r--r-- 1 root root 3234730 Oct 27 09:35 libpari.a -rwxr-xr-x 1 root root 3085961 Oct 27 09:35 libpari.so
After days of testing i am sure zlib is causing the last sandbox violation error. I rewrote the makefile to use the portage version of it and now sage compiles and installs fine. I also set up an repository on github (http://github.com/cschwan/sage-on-gentoo) which already contains patches needed to remove some internal dependencies of sage and thus making the installation more "gentoo-ish" (and noticably faster). Try it!
(In reply to comment #78) > After days of testing i am sure zlib is causing the last sandbox violation > error. I rewrote the makefile to use the portage version of it and now sage > compiles and installs fine. > > I also set up an repository on github > (http://github.com/cschwan/sage-on-gentoo) which already contains patches > needed to remove some internal dependencies of sage and thus making the > installation more "gentoo-ish" (and noticably faster). Try it! > zlib I will look into that. That reminds me of my early efforts! pari needs the data or at least part of it. I opened the bug to include data specially for sage. numpy is python so it will cause you pain at the moment (scons is OK on the other hand). maxima won't work is compiled against sbcl lisp, it works with ecls - now the default in sage - and worked with clisp. So you can remove ecls from the deps list. If you look at my previous work I was providing a replacement of the deps file rather than patching it. Which should switch to gfortran by setting the SAGE_FORTRAN variable before making sage. sage g95 package is causing me pain with R and gcc-4.4. rpy is nested in R (at least it was), we need rpy so careful with that one.
(In reply to comment #78) > After days of testing i am sure zlib is causing the last sandbox violation > error. I rewrote the makefile to use the portage version of it and now sage > compiles and installs fine. > > I also set up an repository on github > (http://github.com/cschwan/sage-on-gentoo) which already contains patches > needed to remove some internal dependencies of sage and thus making the > installation more "gentoo-ish" (and noticably faster). Try it! > I gave this a try on my amd64 desktop. I was unable to get sage to compile flint unless I added the gmp use flag to dev-libs/ntl. The package use flags I have enabled from previous testing of sage are: sci-mathematics/maxima clisp sci-mathematics/pari gmp cremona galois static doc dev-lang/R lapack dev-python/numpy lapack sci-libs/scipy fftw sandbox with dev-libs/ntl gmp now added. As mentioned in comment #73, installing the documentation still fails. This is in spite of the fact that the doc use flag was NOT enabled. There must be somewhere else that the sage install script is being overwritten. Even though sage seemed to compile and install I still got the same sage start-up errors as mentioned in comment #73. So, on my desktop, compilation fails somewhere. It would seem that some of the "system default" packages are still being built by sage. On my machine I get that the following are still being built by sage: cython-0.11.2.1 matplotlib-0.99.1.p2 numpy-1.3.0.p2 scipy-0.7.p2
(In reply to comment #80) > (In reply to comment #78) > > > I gave this a try on my amd64 desktop. I was unable to get sage to compile > flint unless I added the gmp use flag to dev-libs/ntl. The package use flags I > have enabled from previous testing of sage are: > > sci-mathematics/maxima clisp > sci-mathematics/pari gmp cremona galois static doc > dev-lang/R lapack > dev-python/numpy lapack > sci-libs/scipy fftw sandbox > > with dev-libs/ntl gmp now added. As mentioned in comment #73, installing the > documentation still fails. This is in spite of the fact that the doc use flag > was NOT enabled. There must be somewhere else that the sage install script is > being overwritten. Even though sage seemed to compile and install I still got > the same sage start-up errors as mentioned in comment #73. So, on my desktop, > compilation fails somewhere. > > It would seem that some of the "system default" packages are still being built > by sage. On my machine I get that the following are still being built by sage: > > cython-0.11.2.1 > matplotlib-0.99.1.p2 > numpy-1.3.0.p2 > scipy-0.7.p2 > The pari flags cremona and galois have been replaced by data. ntl should be built with gmp yes. The last four you mentioned are python dependent, it is hard work to drop the internal python from sage. So first stop is too remove anything non-python. I haven't looked at the doc problem do you have tex4html? It may need that. Last round we were doing seriously doing stuff around sage there was trouble with amd64 and supporting /usr/lib64 correctly. I am not sure that short of a completely split ebuild we will sole that problem. I have a few ebuilds that should be updated in the science overlay and on my hard drive which would enable us to pull more stuff out of sage.
(In reply to comment #80) > As mentioned in comment #73, installing the > documentation still fails. This is in spite of the fact that the doc use flag > was NOT enabled. There must be somewhere else that the sage install script is > being overwritten. The "spkg/install" script gets overwritten by sage_scripts-4.2.spkg which contains a copy of that file, but I am patching both install-files to not build the documentation - you think there is a third overwrite ? On my system documentation is not generated. > Even though sage seemed to compile and install I still got > the same sage start-up errors as mentioned in comment #73. So, on my desktop, > compilation fails somewhere. I your log file there is the following error message: "NotImplementedError: <type 'sage.rings.real_mpfr.int_toRR'>". I think this a sage bug on amd64, you should file a bug on their trac-site. I also found (http://www.mailinglistarchive.com/sage-support@googlegroups.com/msg02438.html) a user having a similar issue. (In reply to comment #81) > I have a few ebuilds that should be updated in the science overlay and > on my hard drive which would enable us to pull more stuff out of sage. That would be fine!
(In reply to comment #82) > The "spkg/install" script gets overwritten by sage_scripts-4.2.spkg which > contains a copy of that file, but I am patching both install-files to not build > the documentation - you think there is a third overwrite ? On my system > documentation is not generated. > You're correct. The documentation isn't installed. The errors I see are the result of the "/opt/sage/sage -c quit" from the ebuild since sage will not start cleanly. However, the documentation still won't install if I try to do so with 'sage -docbuild all html'. > > I your log file there is the following error message: "NotImplementedError: > <type 'sage.rings.real_mpfr.int_toRR'>". I think this a sage bug on amd64, you > should file a bug on their trac-site. I also found > (http://www.mailinglistarchive.com/sage-support@googlegroups.com/msg02438.html) > a user having a similar issue. > Perhaps so. However, when I build sage the "usual" sage way, not using portage, I get no errors and all tests pass. The above seems to refer to building sage in the "usual" way, but maybe there is a connection.
*** Bug 293235 has been marked as a duplicate of this bug. ***
Seeing the previous comment I thought that it would be a good idea to report our (currently me and Francois Bissey, reports from Steven Trogdon) progress in making split sage ebuilds: http://github.com/cschwan/sage-on-gentoo Francois already sent a message to the science mailing list, but I think most people interested in sage have CC'ed to this bug. As written in the README on the project page, Sage ships all of its dependencies (about 90 packages!) and we managed to remove about 30 of these. Currently I am trying to remove Singular from Sage - if this is done, all bigger non-Python packages are removed. The Python packages will take a bit more investigation since Sage ships (again ...) its own version of the Python interpreter. Testers welcome!
*** Bug 295201 has been marked as a duplicate of this bug. ***
It has been a while since my last comment about splitting, so here are some updates: - Sage is now available via layman (make sure you have updated your list with "layman -L" and add the repository with "layman -a sage-on-gentoo", for general info about layman see http://www.gentoo.org/proj/en/overlays/userguide.xml) - Only a handful of packages are to split out - the remaining will need more time - I have tested Sage on x86 and had mail from people which ran it successfully on amd64 - reports from other architectures would be fine
I'm having 2 problems when trying to install from overlay: 1º maxima didn't install if I have as-needed in my LDFLAGS. 2º ghmm have a linker problem: readed-atlas libtool: link: x86_64-pc-linux-gnu-gcc -march=core2 -O2 -pipe -ftracer -msse4 -mcx16 -msahf -msse4.1 -msse4.2 -floop-interchange -floop-strip-mine -floop-block -I/usr/include/libxml2 -Wl,-O1 -Wl,--as-needed -Wl,-znow -Wl,--hash-style=gnu -Wl,--sort-common -o scluster scluster.o ../ghmm/.libs/libghmm.a -L/usr/lib64/blas/threaded-atlas -llapack /usr/lib64/blas/threaded-atlas/libblas.so -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2 /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/libgfortran.so /usr/lib64/libatlas.so -lpthread /usr/lib64/libxml2.so -ldl -lz -lm -Wl,-rpath -Wl,/usr/lib64/blas/threaded-atlas -Wl,-rpath -Wl,/usr/lib64/blas/threaded-atlas ../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_cholesky_decomposition': matrixop.c:(.text+0x3a): undefined reference to `clapack_dpotrf' ../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_invert_det': matrixop.c:(.text+0x482): undefined reference to `clapack_dgetrf' matrixop.c:(.text+0x502): undefined reference to `clapack_dgetri' collect2: ld returned 1 exit status distcc[7219] ERROR: compile (null) on localhost failed make[4]: *** [smo2xml] Error 1 make[4]: *** Se espera a que terminen otras tareas.... libtool: link: x86_64-pc-linux-gnu-gcc -march=core2 -O2 -pipe -ftracer -msse4 -mcx16 -msahf -msse4.1 -msse4.2 -floop-interchange -floop-strip-mine -floop-block -I/usr/include/libxml2 -Wl,-O1 -Wl,--as-needed -Wl,-znow -Wl,--hash-style=gnu -Wl,--sort-common -o smix_hmm smix_hmm.o ../ghmm/.libs/libghmm.a -L/usr/lib64/blas/threaded-atlas -llapack /usr/lib64/blas/threaded-atlas/libblas.so -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2 /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/libgfortran.so /usr/lib64/libatlas.so -lpthread /usr/lib64/libxml2.so -ldl -lz -lm -Wl,-rpath -Wl,/usr/lib64/blas/threaded-atlas -Wl,-rpath -Wl,/usr/lib64/blas/threaded-atlas ../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_cholesky_decomposition': matrixop.c:(.text+0x3a): undefined reference to `clapack_dpotrf' ../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_invert_det': matrixop.c:(.text+0x482): undefined reference to `clapack_dgetrf' matrixop.c:(.text+0x502): undefined reference to `clapack_dgetri' collect2: ld returned 1 exit status distcc[7303] ERROR: compile (null) on localhost failed make[4]: *** [probdist] Error 1 ../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_cholesky_decomposition': matrixop.c:(.text+0x3a): undefined reference to `clapack_dpotrf' ../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_invert_det': matrixop.c:(.text+0x482): undefined reference to `clapack_dgetrf' matrixop.c:(.text+0x502): undefined reference to `clapack_dgetri' collect2: ld returned 1 exit status distcc[7339] ERROR: compile (null) on localhost failed make[4]: *** [cluster] Error 1 ../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_cholesky_decomposition': matrixop.c:(.text+0x3a): undefined reference to `clapack_dpotrf' ../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_invert_det': matrixop.c:(.text+0x482): undefined reference to `clapack_dgetrf' matrixop.c:(.text+0x502): undefined reference to `clapack_dgetri' collect2: ld returned 1 exit status distcc[7364] ERROR: compile (null) on localhost failed make[4]: *** [scluster] Error 1 ../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_cholesky_decomposition': matrixop.c:(.text+0x3a): undefined reference to `clapack_dpotrf' ../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_invert_det': matrixop.c:(.text+0x482): undefined reference to `clapack_dgetrf' matrixop.c:(.text+0x502): undefined reference to `clapack_dgetri' collect2: ld returned 1 exit status distcc[7399] ERROR: compile (null) on localhost failed make[4]: *** [smix_hmm] Error 1 make[4]: se sale del directorio `/home/portage/portage/sci-libs/ghmm-0.9_rc1/work/ghmm-0.9-rc1/tools' make[3]: *** [all-recursive] Error 1 make[3]: se sale del directorio `/home/portage/portage/sci-libs/ghmm-0.9_rc1/work/ghmm-0.9-rc1/tools' make[2]: *** [all] Error 2 make[2]: se sale del directorio `/home/portage/portage/sci-libs/ghmm-0.9_rc1/work/ghmm-0.9-rc1/tools' make[1]: *** [all-recursive] Error 1 make[1]: se sale del directorio `/home/portage/portage/sci-libs/ghmm-0.9_rc1/work/ghmm-0.9-rc1' make: *** [all] Error 2 * ERROR: sci-libs/ghmm-0.9_rc1 failed: any idea about the last one? PS: in a pure 64 bit machine another package didn't install because missing 32 bits headers. I try to pass -m64 bit but it is filtering the CFLAGS, when I come back to house I search for the specific package.
What version of - sci-libs/blas-atlas - sci-libs/lapack-atlas do you have (should be 3.9.3) ?
The problem was with 3.9.3 for sure but i'm not sure if it is presented with 3.9.21 as well. PS: the packages that I said before was tachyon: n el fichero inclu�do de /usr/include/features.h:371En el fichero inclu�do de /usr/include/features.h:371, de /usr/include/stdio.h:28, de ../src/machine.h:7, de /usr/include/stdio.h:28, de ../src/apigeom.c:8, de ../src/machine.h:7, de ../src/api.c:8: /usr/include/gnu/stubs.h:7:27:: /usr/include/gnu/stubs.h:7:27: error: error: gnu/stubs-32.h:
I dont know whats the reason for ghmm compilation problem; could you please try to compile (lapack-blas, blas-lapack and ghmm in this order) once more with more conservative CFLAGS ("-march=core2 -O2 -pipe") ? If emerge still fails we can be sure ghmm is not confused with custom compilation flags. Also make sure youre reporting logs with english error messages (prepending LC_ALL=C to "emerge" should do it).
I suppose you was saying that I make this: LC_ALL=C emerge -qa1 lapack-atlas blas-atlas ghmm as lapack-blas, blas-lapack does not exist. mv -f .deps/smo2xml.Tpo .deps/smo2xml.Po /bin/sh ../libtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -march=core2 -O2 -pipe -I/usr/include/libxml2 -Wl,-O1 -Wl,--as-needed -Wl,-znow -Wl,--hash-style=gnu -Wl,--sort-common -o smo2xml smo2xml.o ../ghmm/.libs/libghmm.a -lm -lm -lm -lpthread -L/usr/lib64/blas/threaded-atlas -llapack -lblas -latlas -lpthread -lxml2 mv -f .deps/probdist.Tpo .deps/probdist.Po /bin/sh ../libtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -march=core2 -O2 -pipe -I/usr/include/libxml2 -Wl,-O1 -Wl,--as-needed -Wl,-znow -Wl,--hash-style=gnu -Wl,--sort-common -o probdist probdist.o ../ghmm/.libs/libghmm.a -lm -lm -lm -lpthread -L/usr/lib64/blas/threaded-atlas -llapack -lblas -latlas -lpthread -lxml2 mv -f .deps/cluster.Tpo .deps/cluster.Po mv -f .deps/scluster.Tpo .deps/scluster.Po /bin/sh ../libtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -march=core2 -O2 -pipe -I/usr/include/libxml2 -Wl,-O1 -Wl,--as-needed -Wl,-znow -Wl,--hash-style=gnu -Wl,--sort-common -o cluster cluster.o ../ghmm/.libs/libghmm.a -lm -lm -lm -lpthread -L/usr/lib64/blas/threaded-atlas -llapack -lblas -latlas -lpthread -lxml2 /bin/sh ../libtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -march=core2 -O2 -pipe -I/usr/include/libxml2 -Wl,-O1 -Wl,--as-needed -Wl,-znow -Wl,--hash-style=gnu -Wl,--sort-common -o scluster scluster.o ../ghmm/.libs/libghmm.a -lm -lm -lm -lpthread -L/usr/lib64/blas/threaded-atlas -llapack -lblas -latlas -lpthread -lxml2 mv -f .deps/smix_hmm.Tpo .deps/smix_hmm.Po /bin/sh ../libtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -march=core2 -O2 -pipe -I/usr/include/libxml2 -Wl,-O1 -Wl,--as-needed -Wl,-znow -Wl,--hash-style=gnu -Wl,--sort-common -o smix_hmm smix_hmm.o ../ghmm/.libs/libghmm.a -lm -lm -lm -lpthread -L/usr/lib64/blas/threaded-atlas -llapack -lblas -latlas -lpthread -lxml2 libtool: link: x86_64-pc-linux-gnu-gcc -march=core2 -O2 -pipe -I/usr/include/libxml2 -Wl,-O1 -Wl,--as-needed -Wl,-znow -Wl,--hash-style=gnu -Wl,--sort-common -o smo2xml smo2xml.o ../ghmm/.libs/libghmm.a -L/usr/lib64/blas/threaded-atlas -llapack /usr/lib64/blas/threaded-atlas/libblas.so -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2 /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/libgfortran.so /usr/lib64/libatlas.so -lpthread /usr/lib64/libxml2.so -ldl -lz -lm -Wl,-rpath -Wl,/usr/lib64/blas/threaded-atlas -Wl,-rpath -Wl,/usr/lib64/blas/threaded-atlas libtool: link: x86_64-pc-linux-gnu-gcc -march=core2 -O2 -pipe -I/usr/include/libxml2 -Wl,-O1 -Wl,--as-needed -Wl,-znow -Wl,--hash-style=gnu -Wl,--sort-common -o probdist probdist.o ../ghmm/.libs/libghmm.a -L/usr/lib64/blas/threaded-atlas -llapack /usr/lib64/blas/threaded-atlas/libblas.so -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2 /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/libgfortran.so /usr/lib64/libatlas.so -lpthread /usr/lib64/libxml2.so -ldl -lz -lm -Wl,-rpath -Wl,/usr/lib64/blas/threaded-atlas -Wl,-rpath -Wl,/usr/lib64/blas/threaded-atlas libtool: link: x86_64-pc-linux-gnu-gcc -march=core2 -O2 -pipe -I/usr/include/libxml2 -Wl,-O1 -Wl,--as-needed -Wl,-znow -Wl,--hash-style=gnu -Wl,--sort-common -o scluster scluster.o ../ghmm/.libs/libghmm.a -L/usr/lib64/blas/threaded-atlas -llapack /usr/lib64/blas/threaded-atlas/libblas.so -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2 /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/libgfortran.so /usr/lib64/libatlas.so -lpthread /usr/lib64/libxml2.so -ldl -lz -lm -Wl,-rpath -Wl,/usr/lib64/blas/threaded-atlas -Wl,-rpath -Wl,/usr/lib64/blas/threaded-atlas libtool: link: x86_64-pc-linux-gnu-gcc -march=core2 -O2 -pipe -I/usr/include/libxml2 -Wl,-O1 -Wl,--as-needed -Wl,-znow -Wl,--hash-style=gnu -Wl,--sort-common -o cluster cluster.o ../ghmm/.libs/libghmm.a -L/usr/lib64/blas/threaded-atlas -llapack /usr/lib64/blas/threaded-atlas/libblas.so -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2 /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/libgfortran.so /usr/lib64/libatlas.so -lpthread /usr/lib64/libxml2.so -ldl -lz -lm -Wl,-rpath -Wl,/usr/lib64/blas/threaded-atlas -Wl,-rpath -Wl,/usr/lib64/blas/threaded-atlas ../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_cholesky_decomposition': matrixop.c:(.text+0x3a): undefined reference to `clapack_dpotrf' ../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_invert_det': matrixop.c:(.text+0x432): undefined reference to `clapack_dgetrf' matrixop.c:(.text+0x4b2): undefined reference to `clapack_dgetri' collect2: ld returned 1 exit status distcc[16638] ERROR: compile (null) on localhost failed make[4]: *** [smo2xml] Error 1 make[4]: *** Waiting for unfinished jobs.... libtool: link: x86_64-pc-linux-gnu-gcc -march=core2 -O2 -pipe -I/usr/include/libxml2 -Wl,-O1 -Wl,--as-needed -Wl,-znow -Wl,--hash-style=gnu -Wl,--sort-common -o smix_hmm smix_hmm.o ../ghmm/.libs/libghmm.a -L/usr/lib64/blas/threaded-atlas -llapack /usr/lib64/blas/threaded-atlas/libblas.so -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2 /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/libgfortran.so /usr/lib64/libatlas.so -lpthread /usr/lib64/libxml2.so -ldl -lz -lm -Wl,-rpath -Wl,/usr/lib64/blas/threaded-atlas -Wl,-rpath -Wl,/usr/lib64/blas/threaded-atlas ../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_cholesky_decomposition': matrixop.c:(.text+0x3a): undefined reference to `clapack_dpotrf' ../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_invert_det': matrixop.c:(.text+0x432): undefined reference to `clapack_dgetrf' matrixop.c:(.text+0x4b2): undefined reference to `clapack_dgetri' collect2: ld returned 1 exit status distcc[16733] ERROR: compile (null) on localhost failed make[4]: *** [probdist] Error 1 ../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_cholesky_decomposition': matrixop.c:(.text+0x3a): undefined reference to `clapack_dpotrf' ../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_invert_det': matrixop.c:(.text+0x432): undefined reference to `clapack_dgetrf' matrixop.c:(.text+0x4b2): undefined reference to `clapack_dgetri' collect2: ld returned 1 exit status distcc[16764] ERROR: compile (null) on localhost failed make[4]: *** [scluster] Error 1 ../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_cholesky_decomposition': matrixop.c:(.text+0x3a): undefined reference to `clapack_dpotrf' ../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_invert_det': matrixop.c:(.text+0x432): undefined reference to `clapack_dgetrf' matrixop.c:(.text+0x4b2): undefined reference to `clapack_dgetri' collect2: ld returned 1 exit status distcc[16792] ERROR: compile (null) on localhost failed make[4]: *** [cluster] Error 1 ../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_cholesky_decomposition': matrixop.c:(.text+0x3a): undefined reference to `clapack_dpotrf' ../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_invert_det': matrixop.c:(.text+0x432): undefined reference to `clapack_dgetrf' matrixop.c:(.text+0x4b2): undefined reference to `clapack_dgetri' collect2: ld returned 1 exit status distcc[16821] ERROR: compile (null) on localhost failed make[4]: *** [smix_hmm] Error 1 make[4]: Leaving directory `/home/portage/portage/sci-libs/ghmm-0.9_rc1/work/ghmm-0.9-rc1/tools' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/portage/portage/sci-libs/ghmm-0.9_rc1/work/ghmm-0.9-rc1/tools' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/portage/portage/sci-libs/ghmm-0.9_rc1/work/ghmm-0.9-rc1/tools' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/portage/portage/sci-libs/ghmm-0.9_rc1/work/ghmm-0.9-rc1' make: *** [all] Error 2 I have noticed that the error depend on the blas and cblas implementation that have been selected with eselect.
(In reply to comment #92) > I suppose you was saying that I make this: > > LC_ALL=C emerge -qa1 lapack-atlas blas-atlas ghmm > > as lapack-blas, blas-lapack does not exist. > Yes! > [..] Ok, so changing CFLAGS does not solve the problem. Please try again with more conservative LDFLAGS: LDFLAGS="-Wl,-O1" > > I have noticed that the error depend on the blas and cblas implementation that > have been selected with eselect. > What do you exactly mean with "depends" ?
(In reply to comment #93) > (In reply to comment #92) > > I suppose you was saying that I make this: > > > > LC_ALL=C emerge -qa1 lapack-atlas blas-atlas ghmm > > > > as lapack-blas, blas-lapack does not exist. > > > > Yes! > > > [..] > > Ok, so changing CFLAGS does not solve the problem. Please try again with more > conservative LDFLAGS: > > LDFLAGS="-Wl,-O1" > A more conservative set is LDFLAGS="" as far as I know -Wl,-O1 is useless as the linker doesn't do optimization. > > > > I have noticed that the error depend on the blas and cblas implementation that > > have been selected with eselect. > > > > What do you exactly mean with "depends" ? > I guess he means this: ../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_cholesky_decomposition': matrixop.c:(.text+0x3a): undefined reference to `clapack_dpotrf' ../ghmm/.libs/libghmm.a(matrixop.o): In function `ighmm_invert_det': matrixop.c:(.text+0x432): undefined reference to `clapack_dgetrf' matrixop.c:(.text+0x4b2): undefined reference to `clapack_dgetri' collect2: ld returned 1 exit status -------------- Are you sure lapack-atlas is properly selected? This is the only supported clapack implementation as far as I can tell. Can you give us the output of: ls -la /usr/lib64/liblapack* After looking carefully, I don't think the path to liblapack.so is properly set. We have -L/usr/lib64/blas/threaded-atlas but nothing similar for lapack. If I am not mistaken lapack should live in /usr/lib64/lapack/(maybe threaded-atlas). I will inspect the ebuild but I am almost sure that the proper path for lapack is not passed to it.
Do you have several lapack installed? Can you give us the config.log?
I can't prove anythings until monday (the computer is on my office, not at home :( )
(In reply to comment #96) > I can't prove anythings until monday (the computer is on my office, not at home > :( ) > That's all right. It gives me more time to give you a list of stuff to check. So I will want the following: Output of "equery f lapack-atlas" Output of "pkg-config --libs lapack" Output of "pkg-config --cflags lapack" All I can think of right now. And thank you for reminding me about the maxima problem since I am having a look at maxima these days. Although it should be a separate bug really.
Well, my homework :) Seems like the links to lapack are set properly. $ ls -la /usr/lib64/liblapack* lrwxrwxrwx 1 root root 28 oct 19 17:28 /usr/lib64/liblapack.a -> lapack/reference/liblapack.a lrwxrwxrwx 1 root root 29 oct 19 17:28 /usr/lib64/liblapack.so -> lapack/reference/liblapack.so lrwxrwxrwx 1 root root 31 oct 19 17:28 /usr/lib64/liblapack.so.0 -> lapack/reference/liblapack.so.0 I only have the lapack that was instaled by sage. $ eselect blas list Installed BLAS for library directory lib64 [1] atlas [2] atlas-threads [3] reference * $ eselect cblas list Installed CBLAS for library directory lib64 [1] atlas [2] atlas-threads [3] gsl * The config.log of the last try of building ghmm is in http://personales.unican.es/borgesce/config.txt My emerge --info emerge --info Portage 2.2_rc62 (default/linux/amd64/10.0, gcc-4.4.2, glibc-2.11-r1, 2.6.32-gentoo-r3 x86_64) ================================================================= System uname: Linux-2.6.32-gentoo-r3-x86_64-Intel-R-_Xeon-R-_CPU_E5520_@_2.27GHz-with-gentoo-2.0.1 Timestamp of tree: Mon, 08 Feb 2010 09:45:03 +0000 distcc 3.1 x86_64-pc-linux-gnu [enabled] app-shells/bash: 4.0_p37 dev-java/java-config: 2.1.10 dev-lang/python: 2.6.4-r99 dev-python/pycrypto: 2.1.0 dev-util/cmake: 2.8.0-r2 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.0-r1 sys-apps/sandbox: 2.2 sys-devel/autoconf: 2.13, 2.65 sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20 sys-devel/gcc: 4.4.2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=core2 -O2 -pipe -ftracer -msse4 -mcx16 -msahf -msse4.1 -msse4.2 -floop-interchange -floop-strip-mine -floop-block" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/config /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=core2 -O2 -pipe -ftracer -msse4 -mcx16 -msahf -msse4.1 -msse4.2 -floop-interchange -floop-strip-mine -floop-block" DISTDIR="/home/portage/distfiles/" EMERGE_DEFAULT_OPTS="--jobs 6 --keep-going --load-average 8" FEATURES="assume-digests distcc distlocks fixpackages news parallel-fetch sandbox sfperms strict unmerge-logs unmerge-orphans userfetch usersandbox" GENTOO_MIRRORS="http://sunsite.rediris.es/mirror/gentoo/" LANG="es_ES" LC_ALL="es_ES@euro" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-znow -Wl,--hash-style=gnu -Wl,--sort-common" LINGUAS="es es_ES" MAKEOPTS="-j11" PKGDIR="/home/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/home/portage" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/layman/kde /usr/local/portage/layman/java-overlay /usr/local/portage/layman/sage-on-gentoo /usr/local/portage/layman/toolchain /usr/local/portage/overlay" SYNC="rsync://kassandra/gentoo-portage" USE="X a52 aac acpi alsa amd64 avi branding bzip2 cdr cleartype cli cracklib crypt cups cxx dbus djvu dri dvd ffmpeg gif gmp gpm hal iconv jpeg kde lame latex lm_sensors lzma matroska mmx mmxext modules mp3 mp4 mpeg mudflap multilib ncurses nls nptl nptlonly nsl ntpl ogg oggvorbis opengl openmp pam pcre pdf pic pie png pppd qt3support qt4 readline reflection samba semantic-desktop session smp spell spl sse sse2 ssl ssse3 svg symlink sysfs tcpd theora threads tiff truetype type1 unicode usb vdpau vorbis x264 xcb xcomposite xinerama xml xorg xvid zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm asym copy dmix dsnoop empty file ioplug null plug rate shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" FOO2ZJS_DEVICES="hp1020" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="es es_ES" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, FFLAGS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS Note that i have a core i7 and this are the "safe cflags" recomended (exept ftracer, but i have tryed it before). Next $equery f lapack-atlas * Searching for lapack-atlas ... * Contents of sci-libs/lapack-atlas-3.9.3: /etc /etc/env.d /etc/env.d/lapack /etc/env.d/lapack/lib64 /etc/env.d/lapack/lib64/atlas /usr /usr/include /usr/include/atlas /usr/include/atlas/clapack.h /usr/include/clapack.h -> atlas/clapack.h /usr/lib64 /usr/lib64/lapack /usr/lib64/lapack/atlas /usr/lib64/lapack/atlas/lapack.pc /usr/lib64/lapack/atlas/liblapack.a /usr/lib64/lapack/atlas/liblapack.la /usr/lib64/lapack/atlas/liblapack.so -> liblapack.so.0.0.0 /usr/lib64/lapack/atlas/liblapack.so.0 -> liblapack.so.0.0.0 /usr/lib64/lapack/atlas/liblapack.so.0.0.0 /usr/share /usr/share/doc /usr/share/doc/lapack-atlas-3.9.3 /usr/share/doc/lapack-atlas-3.9.3/AtlasCredits.txt.bz2 /usr/share/doc/lapack-atlas-3.9.3/ChangeLog.bz2 /usr/share/doc/lapack-atlas-3.9.3/README.bz2 $ pkg-config --libs lapack -llapack -lblas $ pkg-config --cflags lapack (empty) I'am trying with CFLAGS="-O2 -march=native -pipe" LDFLAGS="" LC_ALL=C emerge -qa1 lapack-atlas blas-atlas ghmm I will post the result. Note that it was updating blas-atlas and lapack atlas to 3.9.21-r1
The result of the emerge: mv -f .deps/sdmodel.Tpo .deps/sdmodel.Plo libtool: compile: x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DDTD_LOC=\"/usr/share/ghmm/ghmm.dtd.1.0\" -O2 -march=native -pipe -I/usr/include/libxml2 -MT pviterbi.lo -MD -MP -MF .deps/pviterbi.Tpo -c pviterbi.c -o pviterbi.o >/dev/null 2>&1 libtool: compile: x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DDTD_LOC=\"/usr/share/ghmm/ghmm.dtd.1.0\" -O2 -march=native -pipe -I/usr/include/libxml2 -MT pviterbi_propagate.lo -MD -MP -MF .deps/pviterbi_propagate.Tpo -c pviterbi_propagate.c -o pviterbi_propagate.o >/dev/null 2>&1 mv -f .deps/pviterbi.Tpo .deps/pviterbi.Plo libtool: compile: x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DDTD_LOC=\"/usr/share/ghmm/ghmm.dtd.1.0\" -O2 -march=native -pipe -I/usr/include/libxml2 -MT mes.lo -MD -MP -MF .deps/mes.Tpo -c mes.c -o mes.o >/dev/null 2>&1 libtool: compile: x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DDTD_LOC=\"/usr/share/ghmm/ghmm.dtd.1.0\" -O2 -march=native -pipe -I/usr/include/libxml2 -MT scanner.lo -MD -MP -MF .deps/scanner.Tpo -c scanner.c -o scanner.o >/dev/null 2>&1 mv -f .deps/pviterbi_propagate.Tpo .deps/pviterbi_propagate.Plo mv -f .deps/mes.Tpo .deps/mes.Plo mv -f .deps/scanner.Tpo .deps/scanner.Plo In file included from matrixop.c:48: /usr/include/clapack.h:4:24: error: atlas_misc.h: No such file or directory In file included from matrixop.c:48: /usr/include/clapack.h:42: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:42: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:43: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:44: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:44: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:45: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:46: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:46: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:47: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:48: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:48: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:49: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:77: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:77: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:78: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:79: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:79: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:80: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:81: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:81: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:82: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:83: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:83: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:84: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:112: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:112: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:113: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:114: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:114: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:115: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:116: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:116: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:117: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:118: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:118: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:119: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:147: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:147: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:148: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:149: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:149: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:150: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:151: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:151: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:152: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:153: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:153: error: expected declaration specifiers or '...' before 'ATL_CINT' /usr/include/clapack.h:154: error: expected declaration specifiers or '...' before 'ATL_CINT' distcc[32136] ERROR: compile (null) on localhost failed make[3]: *** [matrixop.lo] Error 1 make[3]: *** Waiting for unfinished jobs.... libtool: compile: x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DDTD_LOC=\"/usr/share/ghmm/ghmm.dtd.1.0\" -O2 -march=native -pipe -I/usr/include/libxml2 -MT linkedlist.lo -MD -MP -MF .deps/linkedlist.Tpo -c linkedlist.c -o linkedlist.o >/dev/null 2>&1 libtool: compile: x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DDTD_LOC=\"/usr/share/ghmm/ghmm.dtd.1.0\" -O2 -march=native -pipe -I/usr/include/libxml2 -MT gauss_tail.lo -MD -MP -MF .deps/gauss_tail.Tpo -c gauss_tail.c -o gauss_tail.o >/dev/null 2>&1 mv -f .deps/linkedlist.Tpo .deps/linkedlist.Plo mv -f .deps/gauss_tail.Tpo .deps/gauss_tail.Plo libtool: compile: x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DDTD_LOC=\"/usr/share/ghmm/ghmm.dtd.1.0\" -O2 -march=native -pipe -I/usr/include/libxml2 -MT mprintf.lo -MD -MP -MF .deps/mprintf.Tpo -c mprintf.c -o mprintf.o >/dev/null 2>&1 mv -f .deps/mprintf.Tpo .deps/mprintf.Plo libtool: compile: x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DDTD_LOC=\"/usr/share/ghmm/ghmm.dtd.1.0\" -O2 -march=native -pipe -I/usr/include/libxml2 -MT vector.lo -MD -MP -MF .deps/vector.Tpo -c vector.c -o vector.o >/dev/null 2>&1 mv -f .deps/vector.Tpo .deps/vector.Plo make[3]: Leaving directory `/home/portage/portage/sci-libs/ghmm-0.9_rc1/work/ghmm-0.9-rc1/ghmm' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/portage/portage/sci-libs/ghmm-0.9_rc1/work/ghmm-0.9-rc1/ghmm' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/portage/portage/sci-libs/ghmm-0.9_rc1/work/ghmm-0.9-rc1' make: *** [all] Error 2 Fail in the same file but the error is when compiling, not at link phase.
(In reply to comment #98) > Well, my homework :) > > I only have the lapack that was instaled by sage. > $ eselect blas list > Installed BLAS for library directory lib64 > [1] atlas > [2] atlas-threads > [3] reference * > > $ eselect cblas list > Installed CBLAS for library directory lib64 > [1] atlas > [2] atlas-threads > [3] gsl * > I don't mean to muddy things, but I get similar errors to yours in building ghmm if I set blas and cblas to what you have and if I eselect lapack set reference (3.1.1-r1) What do you have lapack set to? If I eselect lapack set atlas (3.9.3) then ghmm builds. Generally, I have all these packages set to either atlas or atlas-threads and ghmm builds.
I believe this problems are solved with blas-atlas/lapack-atlas 3.9.21-r1 give it a try. I should have posted this 2 days ago.
It doesn't work until I set lapack to atlas instead of reference. Thanks for the hard work :)
(In reply to comment #102) > It doesn't work until I set lapack to atlas instead of reference. > > Thanks for the hard work :) > lapack-atlas at least needs to be selected. Yes we know. The reason is that a number of sage packages are using atlas implementation of clapack. There are no standard for clapack, there is another implementation in the science overlay but it is probably not compatible. culprits that I know for sure are: linbox ghmm
It has been 2.5 years since the first ebuild became available. Is there any chance that this will be included in the official tree, even if it is out of date? By the way, version 4.4.4 is out.
(In reply to comment #104) > It has been 2.5 years since the first ebuild became available. Is there any > chance that this will be included in the official tree, even if it is out of > date? Though I am not a official gentoo developer I tend to say yes ! The main problem would be a small patch which is applied to python and which is not (yet) adopted by upstream (http://bugs.python.org/issue7689). Also, Sage has a long list of dependencies which one needs to put in the main tree first. In the mean-time you may use our "sage-on-gentoo"-overlay at http://github.com/cschwan/sage-on-gentoo which always supports the most recent version of Sage (that includes 4.4.4). > > By the way, version 4.4.4 is out. >
getting this into portage would be absolutely wonderful. Layman overlay good for now though :)
Getting it into portage is our long-term objective, of course. And always remember: If you have problems with sage-on-gentoo, just write a mail to the gentoo-science list! Cheers
I have some (maybe QA) questions about current sage ebuilds from sage-on-gentoo overlay (4.6-r1 versions). First of all, why sage-banner is installed to /usr/bin/? It isn't executable file, after all. Secondly, I don't agree that some debugger helpers (like sage-gdb or sage-valgrind) should be installed only when debug use-flag is enabled (sage-baselayout ebuild). Correct me please if I'm wrong, but I think this flag is used to enable some extra debug _code_.
(In reply to comment #108) > I have some (maybe QA) questions about current sage ebuilds from sage-on-gentoo > overlay (4.6-r1 versions). > First of all, why sage-banner is installed to /usr/bin/? It isn't executable > file, after all. > Secondly, I don't agree that some debugger helpers (like sage-gdb or > sage-valgrind) should be installed only when debug use-flag is enabled > (sage-baselayout ebuild). Correct me please if I'm wrong, but I think this flag > is used to enable some extra debug _code_. > Your two concerns are well noted. Moving sage-banner would be a further departure from upstream, I believe upstream may do something about it soon so we'll wait before finding a solution. I think you are right about the debug flag. Thanks for your feed back, do not hesitate to voice your opinion we are listening!
(In reply to comment #109) > (In reply to comment #108) > > I have some (maybe QA) questions about current sage ebuilds from sage-on-gentoo > > overlay (4.6-r1 versions). > > First of all, why sage-banner is installed to /usr/bin/? It isn't executable > > file, after all. > > Secondly, I don't agree that some debugger helpers (like sage-gdb or > > sage-valgrind) should be installed only when debug use-flag is enabled > > (sage-baselayout ebuild). Correct me please if I'm wrong, but I think this flag > > is used to enable some extra debug _code_. > > > Your two concerns are well noted. Moving sage-banner would be a further > departure from upstream, I believe upstream may do something about it soon > so we'll wait before finding a solution. > I think you are right about the debug flag. Thats absolutely right. I just removed the USE-flag so that these files are installed by default. > > Thanks for your feed back, do not hesitate to voice your opinion we are > listening! >
There are least two people experiencing startup problems on amd64. If this sounds familiar to you, please take a look at my mail: http://archives.gentoo.org/gentoo-science/msg_fbdeb9ffce6dd65a98953b648fd31000.xml
In the past, I have wanted to install sage, but did not try because all of the USE flags that had to be enabled manually turned me away. I just tried again today and I am receiving fetch failures for the following packages: sci-libs/libcliquer-1.2_p6 sci-mathematics/flintqs-20070817_p4 I also had to enable USE flags for an inordinate number of ebuilds. I think that many of them are in the sage overlay, so having to enable USE flags for them does not make sense to me. I put the sage USE flag into /etc/make.conf because it occurred so many times. Here are the lines that I had to add to /etc/portage/package.use: dev-lisp/ecls -unicode dev-python/numpy lapack media-gfx/tachyon threads sci-libs/flint ntl sci-libs/linbox ntl sci-mathematics/eclib pari24 sci-mathematics/glpk gmp sci-mathematics/lcalc pari24 sci-mathematics/maxima ecls sci-mathematics/pari data gmp sci-mathematics/singular libsingular
(In reply to comment #112) > In the past, I have wanted to install sage, but did not try because all of the > USE flags that had to be enabled manually turned me away. I just tried again > today and I am receiving fetch failures for the following packages: > > sci-libs/libcliquer-1.2_p6 > sci-mathematics/flintqs-20070817_p4 Thank you for notifying me - those were updatedand I already uploaded new ebuilds for them. If this happens again, please notify us so we can fix it. These problems happened before (and will happen again, i think) because once you have downloaded the files you wont noticed that they are removed from upstream. > > I also had to enable USE flags for an inordinate number of ebuilds. I think > that many of them are in the sage overlay, so having to enable USE flags for > them does not make sense to me. I put the sage USE flag into /etc/make.conf > because it occurred so many times. Here are the lines that I had to add to > /etc/portage/package.use: > > dev-lisp/ecls -unicode > dev-python/numpy lapack > media-gfx/tachyon threads > sci-libs/flint ntl > sci-libs/linbox ntl > sci-mathematics/eclib pari24 > sci-mathematics/glpk gmp > sci-mathematics/lcalc pari24 > sci-mathematics/maxima ecls > sci-mathematics/pari data gmp > sci-mathematics/singular libsingular > We have prepared a package.use file for that - please read the file README.rst in our overlay or go to https://github.com/cschwan/sage-on-gentoo where you may read a formatted version of it. Everyone interested in Sage should take a look at this site!
(In reply to comment #112) > In the past, I have wanted to install sage, but did not try because all of the > USE flags that had to be enabled manually turned me away. I just tried again > today and I am receiving fetch failures for the following packages: Install the autounmask package, and learn how to use it. It's very handy, and I think it also handles USE flags. Essentially, if you want to install a package and it needs some USE flags to be set in other packages, it will populate package.use for you.
(In reply to comment #114) > (In reply to comment #112) > > In the past, I have wanted to install sage, but did not try because all of the > > USE flags that had to be enabled manually turned me away. I just tried again > > today and I am receiving fetch failures for the following packages: > > Install the autounmask package, and learn how to use it. It's very handy, and I > think it also handles USE flags. > > Essentially, if you want to install a package and it needs some USE flags to be > set in other packages, it will populate package.use for you. > There is even a third option: emerge --autounmask sage which was introduced with portage 2.1.9.x (though I havent tested that).
*** Bug 372683 has been marked as a duplicate of this bug. ***
Is there a chance to get an init script for sage to run a sage server?
(In reply to comment #117) > Is there a chance to get an init script for sage to run a sage server? sci-mathematics/sage-notebook-server is written exactly for this purpose. I wrote it some time ago, but it should still work. If it does no longer work or if you have any ideas how to improve it, let me know.
(In reply to comment #118) > (In reply to comment #117) > > Is there a chance to get an init script for sage to run a sage server? > > sci-mathematics/sage-notebook-server is written exactly for this purpose. I > wrote it some time ago, but it should still work. If it does no longer work or > if you have any ideas how to improve it, let me know. Thank you! It mostly works. Only 'mostly' because I couldn't start a secure notebook. It complained that 'certtool' is missing when running the setup. Until recently I used upstream's tarball to compile and run sage in my home directoy. After copying my .sage directory over to /var/lib/sage the server started. Two additional points: a) It would be nice if the user that runs the notebook would be configurable. b) Why don't you install sci-mathematics/sage-notebook-server as a dependency of sage? Two files won't hurt anyone and those searching for an init script would find it right away.
(In reply to comment #119) > It mostly works. Only 'mostly' because I couldn't start a secure notebook. It > complained that 'certtool' is missing when running the setup. /usr/bin/certool is a part of gnutls. Do you get the error as well if you have net-libs/gnutls installed? If yes, maybe it's a PATH problem?
(In reply to comment #119) > (In reply to comment #118) > > (In reply to comment #117) > > > Is there a chance to get an init script for sage to run a sage server? > > > > sci-mathematics/sage-notebook-server is written exactly for this purpose. I > > wrote it some time ago, but it should still work. If it does no longer work or > > if you have any ideas how to improve it, let me know. > > Thank you! > > It mostly works. Only 'mostly' because I couldn't start a secure notebook. It > complained that 'certtool' is missing when running the setup. Until recently I > used upstream's tarball to compile and run sage in my home directoy. After > copying my .sage directory over to /var/lib/sage the server started. > > Two additional points: > a) It would be nice if the user that runs the notebook would be configurable. Thats a good idea. I will add some code to interactively configure it. > b) Why don't you install sci-mathematics/sage-notebook-server as a dependency > of sage? Two files won't hurt anyone and those searching for an init script > would find it right away. I tried to be careful because I do not have any experience regarding servers. I am also not sure if the current behavior (starting everything as user "sage") is safe. If the startup scripts are thoroughly tested I will include them into sci-mathematics/sage.
(In reply to comment #120) > (In reply to comment #119) > > It mostly works. Only 'mostly' because I couldn't start a secure notebook. It > > complained that 'certtool' is missing when running the setup. > > /usr/bin/certool is a part of gnutls. Do you get the error as well if you have > net-libs/gnutls installed? If yes, maybe it's a PATH problem? You're right, I didn't have gnutls installed. Now that this error is gone, there is another problem. For 'setup' to do all necessary things, sage needs to be passed all the arguments it's started later on with. If this doesn't happen it tries to run notebook.setup() on start which is interactive in my case. The following line worked for me in setup(): su sage -c "/usr/bin/sage -notebook accounts=${accounts-False} interface=${interface-localhost} open_viewer=False port=${port-8000} require_login=${require_login-True} secure=${secure-False} timeout=${timeout-0}"
(In reply to comment #121) > (In reply to comment #119) > > Two additional points: > > a) It would be nice if the user that runs the notebook would be configurable. > > Thats a good idea. I will add some code to interactively configure it. > I thought more about a setting in /etc/conf.d/sage-notebook-server
After upgrading from 4.7-r2 to 4.7.1, sage does no longer work. On the first start it asked me to run %upgrade and after that it asked me to delete a file in ~/.sage. After that it asked again for %upgrade, but that had no effect. After removing ~/.sage, I get the trace back below. ---------------------------------------------------------------------- | Sage Version 4.7.1, Release Date: 2011-08-11 | | Type notebook() for the GUI, and license() for information. | ---------------------------------------------------------------------- Please wait while the Sage Notebook server starts... Traceback (most recent call last): File "/usr/bin/sage-notebook-real", line 9, in <module> from sage.server.notebook.all import notebook File "/usr/lib/python2.7/site-packages/sage/server/notebook/all.py", line 22, in <module> from sagenb.notebook.all import * File "/usr/lib/python2.7/site-packages/sagenb/notebook/all.py", line 16, in <module> from notebook_object import notebook, inotebook File "/usr/lib/python2.7/site-packages/sagenb/notebook/notebook_object.py", line 17, in <module> import notebook as _notebook File "/usr/lib/python2.7/site-packages/sagenb/notebook/notebook.py", line 35, in <module> from sagenb.misc.misc import (pad_zeros, cputime, tmp_dir, load, save, File "/usr/lib/python2.7/site-packages/sagenb/misc/misc.py", line 183, in <module> import sage.all File "/usr/lib/python2.7/site-packages/sage/all.py", line 85, in <module> import sage.symbolic.pynac File "expression.pxd", line 6, in init sage.symbolic.pynac (sage/symbolic/pynac.cpp:19320) File "expression.pyx", line 6651, in init sage.symbolic.expression (sage/symbolic/expression.cpp:36442) File "/usr/lib/python2.7/site-packages/sage/misc/decorators.py", line 648, in __call__ @sage_wraps(func) File "/usr/lib/python2.7/site-packages/sage/misc/decorators.py", line 106, in f argspec = sage_getargspec(wrapped) File "/usr/lib/python2.7/site-packages/sage/misc/sageinspect.py", line 1076, in sage_getargspec return inspect.ArgSpec(*_sage_getargspec_cython(sage_getsource(obj))) File "/usr/lib/python2.7/site-packages/sage/misc/sageinspect.py", line 865, in _sage_getargspec_cython raise ValueError, "Could not parse cython argspec" ValueError: Could not parse cython argspec
Thanks for reporting! You can solve the problem immediately by compiling sage and sage-baselayout with USE=testsuite. However, I will upload a new ebuild shortly which takes care of that. See also the following discussions on gentoo-science: http://archives.gentoo.org/gentoo-science/msg_715609e30f80b243448c4cee38bc8028.xml http://archives.gentoo.org/gentoo-science/msg_e70ba547fd186a09cb1d5754930cead6.xml
(In reply to comment #125) > Thanks for reporting! > Thank you for the quick reply!
No problem. Sage should now work again!
(In reply to comment #123) > (In reply to comment #121) > > (In reply to comment #119) > > > Two additional points: > > > a) It would be nice if the user that runs the notebook would be configurable. > > > > Thats a good idea. I will add some code to interactively configure it. > > > > I thought more about a setting in /etc/conf.d/sage-notebook-server I just updated the startup script and its configuration file. If Sage isnt properly setup, it should detect this and print instructions how to do this. I plan to keep sage-notebook-server.ebuild separate for a little longer; tell me if you like the current behavior of the startup script, what to do better and so on. If I feel fine with it, I will eventually merge it with sage-notebook.
(In reply to comment #128) > I just updated the startup script and its configuration file. If Sage isnt > properly setup, it should detect this and print instructions how to do this. > > I plan to keep sage-notebook-server.ebuild separate for a little longer; tell > me if you like the current behavior of the startup script, what to do better > and so on. Following instructions works. I think this approach is better than the old one. Some comments: a) Steps 2 and 3 could be one step with su $user -c "$cmd". b) It would be nice if the sever would not start after the configuration steps. > If I feel fine with it, I will eventually merge it with sage-notebook. Makes sense. Could you use some versioning for sage-notebook-server? Otherwise it's not possible to go forth and back and one easily misses changes you make. Keep up the good work!
$ LC_ALL=C sage ---------------------------------------------------------------------- | Sage Version 4.7.1, Release Date: 2011-08-11 | | Type notebook() for the GUI, and license() for information. | ---------------------------------------------------------------------- sage: var('i n') (i, n) sage: sum(4*i+1, i, 1, n) /usr/bin/sage-sage: line 230: 8666 Power failure sage-ipython "$@" -i
(In reply to comment #129) > (In reply to comment #128) > > I just updated the startup script and its configuration file. If Sage isnt > > properly setup, it should detect this and print instructions how to do this. > > > > I plan to keep sage-notebook-server.ebuild separate for a little longer; tell > > me if you like the current behavior of the startup script, what to do better > > and so on. > > Following instructions works. I think this approach is better than the old one. > Some comments: > a) Steps 2 and 3 could be one step with su $user -c "$cmd". That is much better. > b) It would be nice if the sever would not start after the configuration steps. You are right, but I am not sure if this is possible with the current approach. > > > If I feel fine with it, I will eventually merge it with sage-notebook. > Makes sense. Could you use some versioning for sage-notebook-server? Otherwise > it's not possible to go forth and back and one easily misses changes you make. OK, I changed the version from 9999 to 1 and 1-r1. > > Keep up the good work! Thank you! (In reply to comment #130) > $ LC_ALL=C sage > ---------------------------------------------------------------------- > | Sage Version 4.7.1, Release Date: 2011-08-11 | > | Type notebook() for the GUI, and license() for information. | > ---------------------------------------------------------------------- > sage: var('i n') > (i, n) > sage: sum(4*i+1, i, 1, n) > /usr/bin/sage-sage: line 230: 8666 Power failure sage-ipython "$@" > -i Strange. Yields LC_ALL=C sage ---------------------------------------------------------------------- | Sage Version 4.7.1, Release Date: 2011-08-11 | | Type notebook() for the GUI, and license() for information. | ---------------------------------------------------------------------- sage: var('i n') (i, n) sage: sum(4*i+1,i,1,n) 2*n^2 + 3*n on my box. Is anyone able to reproduce that behavior?
Paulo (from Mandriva) reported something similar in: http://trac.sagemath.org/sage_trac/ticket/11752 Do you have boehm-gc/ecls with threads enabled? I have threads in boehm-gc but not ecls and don't have any issue.
(In reply to comment #132) > Paulo (from Mandriva) reported something similar in: > http://trac.sagemath.org/sage_trac/ticket/11752 > > Do you have boehm-gc/ecls with threads enabled? I have threads in boehm-gc but > not ecls and don't have any issue. I had both with +threads. Rebuilding ecls with -threads and then rebuilding maxima and sage fixed the issue (and the one in sage bug tracker too). Rebuilding ecls only cuased sage to segfault.
(In reply to comment #133) > (In reply to comment #132) > > Paulo (from Mandriva) reported something similar in: > > http://trac.sagemath.org/sage_trac/ticket/11752 > > > > Do you have boehm-gc/ecls with threads enabled? I have threads in boehm-gc but > > not ecls and don't have any issue. > > I had both with +threads. Rebuilding ecls with -threads and then rebuilding > maxima and sage fixed the issue (and the one in sage bug tracker too). > Rebuilding ecls only cuased sage to segfault. Yes one would need to rebuild sage as well because of sage/libs/ecl.pyx. Paulo has included a nice patch that will make the problem go away whatever the threads setting. So we'll include that at some point. Thank you for coming back with the info.
(In reply to comment #133) > (In reply to comment #132) > > Paulo (from Mandriva) reported something similar in: > > http://trac.sagemath.org/sage_trac/ticket/11752 > > > > Do you have boehm-gc/ecls with threads enabled? I have threads in boehm-gc but > > not ecls and don't have any issue. > > I had both with +threads. Rebuilding ecls with -threads and then rebuilding > maxima and sage fixed the issue (and the one in sage bug tracker too). > Rebuilding ecls only cuased sage to segfault. Paulo's patch is now in the overlay so you can use threads with ecls and it shouldn't cause any trouble anymore.
(In reply to comment #135) > Paulo's patch is now in the overlay so you can use threads with ecls and it > shouldn't cause any trouble anymore. Works now. Thanks!
Any idea why 3d plotting doesn't work for me? I tried an example from the sage documentation in the notebook: #The stuff below works. x, y = var('x y') W = plot3d(sin(pi*((x)^2+(y)^2))/2,(x,-1,1),(y,-1,1), frame=False, color='purple', opacity=0.8) S = sphere((0,0,0),size=0.3, color='red', aspect_ratio=[1,1,1]) #This does not. show(W + S, figsize=8) A popup appears telling me: "ReferenceError: jmolSetDocument is not defined".
(In reply to comment #137) > [..] > > A popup appears telling me: "ReferenceError: jmolSetDocument is not defined". Did you compile the sage-notebook with USE=-java ?
(In reply to comment #138) > (In reply to comment #137) > > [..] > > > > A popup appears telling me: "ReferenceError: jmolSetDocument is not defined". > > Did you compile the sage-notebook with USE=-java ? Right, that was the problem. Somewhat unexpected, but I don't have a better idea how to deal with this. Maybe +java should be an IUSE default and everyone insisting on -java can do this, sacrificing some functionality. Additionally to the use flag change I had to keyword =sci-libs/vecmath-objectclub-1.14. Now the applet shows up and seems to work properly, except that I again and again get popups telling me things like: "Second attempt to finish launch of Jmol Applet #2 failed. Recommend reevaluating the cell manually"
I'll confess that the jmol integration in the sage-notebook is not quite as good as the rest in sage-on-gentoo. I'll try to find the source of the problem. What browser are you using or does that make no difference?
(In reply to comment #140) > What browser are you using or does that make no difference? On Windows 7, with firefox 5 it happens that often that it's really annoying. On gentoo with firfox 3 and chromium 13 is much harder to trigger, but it happens too from time to time. I have yet to find a reproducible way to trigger it.
(In reply to comment #140) > I'll confess that the jmol integration in the sage-notebook is not quite as > good as the rest in sage-on-gentoo. I'll try to find the source of the problem. > What browser are you using or does that make no difference? Here the popups are associated with one of the patches epatch "${FILESDIR}"/trac_9238_interactive_js.patch epatch "${FILESDIR}"/trac_9238_jmol_lib_async.patch in sage-notebook. I'm not sure exactly where. I suspect a search path isn't quite correct for the sog installation. If I remove the patches and re-install sage-notebook, I get no pop-ups but one looses the "interactive" functionality.
We need help from someone who knows js or possibly jmol well. I am out of my depth here. And possibly not in the best condition to find stuff by raw mental power.
(In reply to comment #143) > We need help from someone who knows js or possibly jmol well. I am out of my > depth here. And possibly not in the best condition to find stuff by raw mental > power. Yep. No popups with just the first patch. The second patch produces the problem. And I believe somewhere around function jmolUpdateState(n){ //make sure the default directory is correct // jmolScript('x=defaultdirectory;data "directory @x";');<--this is done on launch of the applet. jmolStatus.defaultdirectory[n] = jmolEvaluate("x",n); in jmol_lib.js For some reason jmolEvaluate("x",n) isn't returning what one would like it to return?
(In reply to comment #144) > (In reply to comment #143) > > We need help from someone who knows js or possibly jmol well. I am out of my > > depth here. And possibly not in the best condition to find stuff by raw mental > > power. > Yep. No popups with just the first patch. The second patch produces the > problem. [...] Does the plugin work for you after omitting this patch? Without it I don't get the popups either (at least on ubunut 10.04 with firefox and chromium), but there is nothing drawn inside the window (except the Jmol Text and the Advanced Controls button).
(In reply to comment #145) > (In reply to comment #144) > > (In reply to comment #143) > > > We need help from someone who knows js or possibly jmol well. I am out of my > > > depth here. And possibly not in the best condition to find stuff by raw mental > > > power. > > Yep. No popups with just the first patch. The second patch produces the > > problem. [...] > > > Does the plugin work for you after omitting this patch? Without it I don't get > the popups either (at least on ubunut 10.04 with firefox and chromium), but > there is nothing drawn inside the window (except the Jmol Text and the Advanced > Controls button). Correction. It didn't work on that system with the patch either. Apparently this is caused by the icedtea6 plugin. After installing the sun plugin it works. Without the patch I got no popups so far. Loading a worksheet with lots of 3d plots is faster now too (the pictures show up faster).
(In reply to comment #146) > Without the patch I got no popups so far. Loading a worksheet with lots of 3d > plots is faster now too (the pictures show up faster). Same on Windows 7, where it got tons of popups before.
(In reply to comment #147) > (In reply to comment #146) > > Without the patch I got no popups so far. Loading a worksheet with lots of 3d > > plots is faster now too (the pictures show up faster). > > Same on Windows 7, where it got tons of popups before. So we are incriminating the second patch? It works better for you without it, so long as you use sun (now oracle) java? Can we presume then that the other patch was meant to get things working on ubuntu? I should check if the patch for the latest jmol have been updated we never know.
(In reply to comment #148) > Can we presume then that the other patch was meant to get things working on ubuntu? Even with the patch it didin't work on ubuntu using the icedtea plugin. I don't see this patch doing any good atm. Do you have an idea what it was supposed to fix?
(In reply to comment #149) > (In reply to comment #148) > > Can we presume then that the other patch was meant to get things working on ubuntu? > > Even with the patch it didin't work on ubuntu using the icedtea plugin. I don't > see this patch doing any good atm. Do you have an idea what it was supposed to > fix? It's all part of http://trac.sagemath.org/sage_trac/ticket/9238 which is a bit of a mess at the moment, to upgrade jmol to version 12.0.xx. According to the description it is to work around some safari bugs. We kind of want to go to jmol 12.0.xx because jmoll-11 has problems with modern browser it seems. Sorting out what is useful on that ticket is not easy and I must say I didn't go through it with a fine comb. If you want to help with that, that would be most welcome. In the meantime, I'll remove the offending patch from the overlay.
Is this package going to appear in sci overlay? Any current sage-4.8.ebuild?
(In reply to comment #151) > Is this package going to appear in sci overlay? Any current sage-4.8.ebuild? No, we have our own overlay at https://github.com/cschwan/sage-on-gentoo, see the README on that page for the installation procedure. An ebuild for Sage 4.8 is available.
The currently stable version doesn't work on amd64 because dependencies cannot be satisfied: emerge: there are no ebuilds to satisfy ">=sci-libs/symmetrica-2.0". (dependency required by "sci-mathematics/sage-4.5.3" [ebuild]) (dependency required by "sage" [argument])
Did you sync your local copy of our overlay? Some days before we pushed Sage 5.1 and your are trying to install 4.5.3 ...
I have some dependency conflicts. For example, sage-5.1 insists on numpy-1.5.1, yet I have another package that needs numpy-1.6.1. Ditto for a few other packages. Is there any way to resolve this? Thanks.
(In reply to comment #155) > I have some dependency conflicts. For example, sage-5.1 insists on > numpy-1.5.1, yet I have another package that needs numpy-1.6.1. > > Ditto for a few other packages. > > Is there any way to resolve this? > That's a very annoying thing I am afraid. There is a problem in numpy 1.6.x with regards to sage (numpy devs have acknowledged it was something they have to fix). Technically you can use sage with numpy-1.6. and I am tempted to change the ebuild to allow it but you should be warned that some stuff involving numpy may not work as expected unless you explicitly cast to a numpy type. http://trac.sagemath.org/sage_trac/ticket/11334 Which ebuilds require numpy-1.6? Francois
> Which ebuilds require numpy-1.6? (dev-python/numpy-1.6.1-r1::gentoo, installed) pulled in by >=dev-python/numpy-1.6.1-r1 required by (dev-python/cython-0.15.1-r1::sage-on-gentoo, ebuild scheduled for merge) (dev-python/pexpect-2.4-r1::sage-on-gentoo, installed) pulled in by >=dev-python/pexpect-2.1 required by (app-backup/duplicity-0.6.19::gentoo, installed)
(In reply to comment #157) > > Which ebuilds require numpy-1.6? > > (dev-python/numpy-1.6.1-r1::gentoo, installed) pulled in by > >=dev-python/numpy-1.6.1-r1 required by > (dev-python/cython-0.15.1-r1::sage-on-gentoo, ebuild scheduled for merge) > That's because cython has a numpy useflag requiring numpy-1.6. However that particular useflag is useless. Add: dev-python/cython -numpy to /etc/portage/package.use > > (dev-python/pexpect-2.4-r1::sage-on-gentoo, installed) pulled in by > >=dev-python/pexpect-2.1 required by > (app-backup/duplicity-0.6.19::gentoo, installed) Not numpy but still annoying. Thanksfully pexpect-2.4-r1 from the sage-on-gentoo overlay is functional overall if I remember correctly but it is slow compared to the earlier version.
why is this not in the gentoo tree, but in an overlay?
We have come a long way but there are still a few bits and pieces that are not quite ready for the main tree. Bits that are shaky: libsingular pexpect for which I ended up making a sage specific ebuild because we are locked into that particular version. ppl main tree is stuck with 0.12 so long as we keep some gcc depending on it. jmol
sage-ppl will be gone from the overlay in the next 24h. I may have to drop further version of sage depending on ppl<1.0 we'll see what's in the tree and in what shape.
Sage 9.0 was released since, with the Python 3 usage only: https://wiki.sagemath.org/Python3-Switch https://www.sagemath.org/download-source.html
(In reply to Anton Kochkov from comment #162) > Sage 9.0 was released since, with the Python 3 usage only: > > https://wiki.sagemath.org/Python3-Switch > > https://www.sagemath.org/download-source.html Now that SageMath is gaining the ability to use system packages, https://trac.sagemath.org/ticket/27330 I've begun to move those packages into ::gentoo from the overlay. That means that in the meantime, at least, you can build a git checkout of sage (after installing all of those packages), and it will use the system copies. Your best bet as an end user is still the sage-on-gentoo overlay, but as more and more things get moved to the ::gentoo tree, the overlay can shrink in size. At some point, it will finally be feasible to move the rest of it into ::gentoo.
