current stable sci-mathematics/scilab-2.7-r3 fails to build with GCC 4.1 due to the gfortran name change (bug #125203). if possible, please stabilize >=sci-mathematics/scilab-4.0 so we can work on getting GCC 4.1 into stable. needs bug #141432 and bug #141438. thanks ;d
Created attachment 95082 [details] scilab-compile-error.txt hmm, scilab-4.0 USE="gtk java -Xaw3d -debug -ocaml -tcltk" seems to have some problems, at least when trying to compile it with gcc-3.3.6-r1 ... Portage 2.1-r2 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.3.6-r4, 2.6.16-gentoo-r12 i686) ================================================================= System uname: 2.6.16-gentoo-r12 i686 AMD Athlon(tm) XP 2400+ Gentoo Base System version 1.12.4 app-admin/eselect-compiler: [Not Present] dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -O2 -pipe" 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/share/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=athlon-xp -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig collision-protect distlocks metadata-transfer sandbox sfperms strict test" GENTOO_MIRRORS="http://gentoo.ynet.sk/pub " LANG="en_US.utf8" LC_ALL="en_US.utf8" LINGUAS="en de" 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'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://192.168.0.1/gentoo-portage" USE="x86 3dnow 3dnowext X a52 aac acpi alsa apm audiofile avi beagle berkdb bitmap-fonts bzip2 cairo cdr cli crypt css cups dbus dlloader dri dvd dvdr dvdread eds emboss encode evo exif fam fbcon ffmpeg firefox flac foomaticdb fortran gdbm gif ginac gmp gnome gphoto2 gpm gstreamer gtk gtk2 hal howl icq imlib ipv6 isdnlog java javascript jpeg jpeg2k lcms libg++ libwww mad mikmod mime mmx mmxext motif mozsvg mp3 mpeg msn nautilus ncurses nfs nls nptl nsplugin nvidia offensive ogg oggvorbis opengl pam pcre pdflib perl plotutils png posix pppd python qt3 qt4 quicktime readline real reflection ruby sdl session sockets spell spl sqlite3 sse ssl subtitles svg tcpd tetex theora tiff truetype truetype-fonts type1-fonts udev unicode usb vcd vorbis win32codecs wma xine xml xmms xorg xv xvid zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux linguas_en linguas_de userland_GNU video_cards_nvidia" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
i can't seem to reproduce it. what blas-atlas, lapack-atlas, and java are you running? # e scilab These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] app-text/sablotron-1.0.1 USE="perl -doc" 474 kB [ebuild N ] x11-libs/vte-0.12.2 USE="opengl python -debug -doc" 951 kB [ebuild N ] x11-libs/libzvt-2.0.1-r2 USE="-debug" 244 kB [ebuild N ] sci-libs/blas-config-1.0.1 0 kB [ebuild N ] sci-libs/blas-atlas-3.7.11 USE="-debug -doc" 0 kB [ebuild N ] gnome-extra/gtkhtml-2.6.3 USE="-accessibility -debug" 382 kB [ebuild N ] sci-libs/lapack-config-1.0.1 0 kB [ebuild N ] sci-libs/lapack-atlas-3.7.11 USE="-debug -doc -ifc" 0 kB [ebuild N ] sci-mathematics/scilab-4.0 USE="gtk java -Xaw3d -debug -ocaml -tcltk" 12,230 kB [ebuild N f ] dev-java/sun-jdk-1.4.2.10-r2 USE="X alsa -browserplugin -doc -examples -jce -mozilla -nsplugin" 0 kB
well, this is: blas-atlas-3.7.11 USE="-debug -doc" lapack-atlas-3.7.11 USE="-debug -doc -ifc" $ java-config -L 1) Sun JDK 1.4.2.12 [sun-jdk-1.4] (/usr/share/java-config-2/vm/sun-jdk-1.4) *) Sun JDK 1.5.0.07 [sun-jdk-1.5] (/usr/share/java-config-2/vm/sun-jdk-1.5) sun-jdk-1.5.0.07-r3 USE="X alsa doc nsplugin -examples -jce" sun-jdk-1.4.2.12-r1 USE="X alsa -doc -examples -jce -nsplugin"
*** Bug 147003 has been marked as a duplicate of this bug. ***
*** Bug 148881 has been marked as a duplicate of this bug. ***
*** Bug 149026 has been marked as a duplicate of this bug. ***
it seems that the build error in metioned in comment #1 is triggered by the java USE flag, as i was just able to build scilab-4.0 USE="Xaw3d gtk -debug -java -ocaml -tcltk" building with "java" still fails with the same errors ...
*** Bug 153756 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > it seems that the build error in metioned in comment #1 is triggered by the > java USE flag, as i was just able to build > > scilab-4.0 USE="Xaw3d gtk -debug -java -ocaml -tcltk" > > building with "java" still fails with the same errors ... > Hi Matthias, I've just changed the build slightly to include the java-pkg-opt eclass which should (hopefully) set up the environment properly to build with USE="java". Everything works fine for me with both java-1.4 and 1.5. Could you please try again and report back once the updated ebuild hits the mirror in an hour or so. Thanks, Markus
Dear x86 folks, Could we please try to move scilab-4.0 into stable on x86!? Hopefully all issues are ironed out by now. Thanks in advance, Markus
at first i want to apologize to markusle for just ignoring comment #9; somehow i've missed that completely. but now back to the summary of this bug: sci-mathematics/scilab-4.0 USE="Xaw3d gtk java -debug -ocaml -tcltk" seems to be fine for me on x86 (notice "java"). i've tried some of the demos and a few things from http://www.scilab.org/doc/intro/node12.html. the only drawback are these messages from emerge: [...] QA Notice: pre-stripped files found: /var/tmp/portage/scilab-4.0/image/usr/lib/scilab-4.0/bin/scilex [...] QA Notice: the following files contain runtime text relocations [...] TEXTREL usr/lib/scilab-4.0/bin/libjavasci.so if i should attach /var/tmp/portage/scilab-4.0/temp/scanelf-textrel.log just let me know ...
(In reply to comment #11) > at first i want to apologize to markusle for just ignoring comment #9; somehow > i've missed that completely. but now back to the summary of this bug: > No problem :) > sci-mathematics/scilab-4.0 USE="Xaw3d gtk java -debug -ocaml -tcltk" seems to > be fine for me on x86 (notice "java"). i've tried some of the demos and a few > things from http://www.scilab.org/doc/intro/node12.html. the only drawback are > these messages from emerge: > > [...] > QA Notice: pre-stripped files found: > /var/tmp/portage/scilab-4.0/image/usr/lib/scilab-4.0/bin/scilex > [...] > QA Notice: the following files contain runtime text relocations > [...] > TEXTREL usr/lib/scilab-4.0/bin/libjavasci.so > > if i should attach /var/tmp/portage/scilab-4.0/temp/scanelf-textrel.log just > let me know ... > Yeah, I can confirm this on my dev-box as well. I'll have to check into this, thanks for pointing it out! Best, Markus
(In reply to comment #12) > > TEXTREL usr/lib/scilab-4.0/bin/libjavasci.so I just fixed this in portage cvs via a patch. From what I can tell this is a problem with the build system, since the Makefile happily links a whole zoo of non-pic .a and .o files which then give rise to the text relocations. Maybe Sylvestre could have a look at this at some point. Thanks, Markus
It is a funny bug :) I have been able to reproduce it using your command line : gcc -march=athlon-xp -O2 -pipe `pkg-config gtk+-2.0 --cflags` -I/usr/include -I/usr/include/linux -c -o javasci_SciStringArray.o javasci_SciStringArray.c The flag "-I/usr/include/linux" is not mandatory to build Scilab and when I remove it, it fixes the bug. Don't ask me why yet. :) Otherwise Markus, I saw the patch you did. I understand it can seem wrong to use $FC in order to link C code but I like that because there are some fortran code in Scilab...
Opfer says x86 done, and you don't want to mess with Opfer!
amd64 keywording is handled in Bug 155812 now; closing this.
