Summary: | gnubg-0.14.3 fails to emerge in amd64 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | playmiac <eap> |
Component: | [OLD] Games | Assignee: | Gentoo Games <games> |
Status: | VERIFIED INVALID | ||
Severity: | blocker | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | neuralnet_amd64_atlas_include.patch |
Description
playmiac
2005-12-28 08:39:45 UTC
It's specifically keyworded -amd64 (i.e. - does not work on amd64 at all). I don't see why you are filing a bug, let alone a blocker one. I did not find any bugs related to why gnubg is not working on amd64, that's why I tested it. If nobody tries, no new software will appear to amd64 arch. Why rate it as blocker - definition from bugzilla: Blocker Blocks development and/or testing work Anything that is specifically -arch means it has been tested by the developers (us) and proven to be lacking enough to warrant not fixing it. I don't know if this will help anybody or not, but I wanted to try to put gnubg on my amd64. First, I just downloaded the source, and it seemed to compile and start, so then I added "-amd64" to /etc/portage/package.keywords. I then emerged it, and it compiled and installed without any complaints. Then I started it, and tested it for several hours, and everything appeared to work perfectly. Some info: [...] checking for stdint.h... yes checking for unistd.h... yes checking cblas.h usability... no checking cblas.h presence... no checking for cblas.h... no checking for ATL_buildinfo in -latlas... no checking for cblas_sgemm in -lcblas... no checking for ANSI C header files... (cached) yes checking whether time.h and sys/time.h may both be included... yes [...] x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -march=k8 -O3 -pipe -msse2 -mfpmath=sse -c `test -f 'heap.c' || echo './'`heap.c source='list.c' object='list.o' libtool=no \ depfile='.deps/list.Po' tmpdepfile='.deps/list.TPo' \ depmode=gcc3 /bin/sh ../depcomp \ x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -march=k8 -O3 -pipe -msse2 -mfpmath=sse -c `test -f 'list.c' || echo './'`list.c source='neuralnet.c' object='neuralnet.o' libtool=no \ depfile='.deps/neuralnet.Po' tmpdepfile='.deps/neuralnet.TPo' \ depmode=gcc3 /bin/sh ../depcomp \ x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -march=k8 -O3 -pipe -msse2 -mfpmath=sse -c `test -f 'neuralnet.c' || echo './'`neural net.c neuralnet.c: In function `NeuralNetCreateDirect': neuralnet.c:389: warning: use of cast expressions as lvalues is deprecated neuralnet.c:390: warning: use of cast expressions as lvalues is deprecated neuralnet.c:391: warning: use of cast expressions as lvalues is deprecated neuralnet.c:392: warning: use of cast expressions as lvalues is deprecated neuralnet.c:394: warning: use of cast expressions as lvalues is deprecated neuralnet.c:395: warning: use of cast expressions as lvalues is deprecated neuralnet.c:406: warning: use of cast expressions as lvalues is deprecated neuralnet.c:408: warning: use of cast expressions as lvalues is deprecated neuralnet.c:410: warning: use of cast expressions as lvalues is deprecated neuralnet.c:412: warning: use of cast expressions as lvalues is deprecated source='mt19937ar.c' object='mt19937ar.o' libtool=no \ depfile='.deps/mt19937ar.Po' tmpdepfile='.deps/mt19937ar.TPo' \ depmode=gcc3 /bin/sh ../depcomp \ x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -march=k8 -O3 -pipe -msse2 -mfpmath=sse -c `test -f 'mt19937ar.c' || echo './'`mt1993 7ar.c source='isaac.c' object='isaac.o' libtool=no \ [...] $ emerge -p info Portage 2.0.54 (default-linux/amd64/2005.1, gcc-3.4.4, glibc-2.3.5-r2, 2.6.15-gentoo-r1 x86_64) ================================================================= System uname: 2.6.15-gentoo-r1 x86_64 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.6.14 dev-lang/python: 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O3 -pipe -msse2 -mfpmath=sse" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=k8 -O3 -pipe -msse2 -mfpmath=sse" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="en_NZ.UTF-8" LINGUAS="en ru" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X aac aalib acpi alsa apache2 arts audiofile avi berkdb bitmap-fonts bzip2 caps cdparanoia cdr cjk crypt css cups dga directfb divx4linux dvd dvdr emboss encode exif expat faad fam fbcon ffmpeg flac freetype gd ggi gif gmp gphoto2 gpm gstreamer gtk2 idea idn imagemagick imap imlib ipv6 javascript jikes joystick jpeg kde lcms libcaca libwww live lm_sensors lzw lzw-tiff mad matroska mbox memlimit mng motif mp3 mpeg mpi mysql nas ncurses network nls nptl nptlonly ogg opengl pcre pdflib perl png ppds qt quicktime readline real rtc samba scanner sdl silc speex spell ssl tcpd theora tiff truetype truetype-fonts type1-fonts udev unicode usb userlocales utf8 vcd vorbis wifi xinerama xml2 xmms xpm xv xvid zlib linguas_en linguas_ru userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LC_ALL, LDFLAGS, MAKEOPTS (In reply to comment #3) > Anything that is specifically -arch means it has been tested by the developers > (us) and proven to be lacking enough to warrant not fixing it. But this specifically developer added -arch is not readily visible in packages-gentoo.org, all non-supported are just (gray)-. See for example http://packages.gentoo.org/search/?sstring=gnubg. It doesn't really matter how it shows up on packages.gentoo.org so much as what is in the ebuild. There's really no point in discussing this. Now, if you think that packages.gentoo.org should have some method of showing that a package is specifically -arch or masked on a specific architecture, then I think you should file a bug against that site. I agree on the no point discussing such trivialities. I haven't been the one wanting to start a flame for this, just tell why this bug was filed (as challenged in comment #1). I agree I am only a n00b+ with gentoo amd64 and that it was very stupid not to look the ebuild directly while relying on packages.gentoo.org search results, but this was the first time I encountered a -arch case. So f..k me, thank you very much. However, to the main point. Gnubg does not compile cleanly in amd64 in all cases. I would still want to find out why gnubg has been marked -amd64 while it appears that it works out of the box in some cases - like in comment #4. A comment like "proven to be lacking enough to warrant not fixing it" is not very helpful, is it? Isn't voluntary testing and sharing information the strenght of open source development or have I understood something terribly wrong? No, you haven't... ...and as soon as you "share" the patch to resolve the compilation problems, we'll gladly add it and submit it upstream. ;] We do not have the manpower to fix every single application that is broken on every architecture, so we choose to focus on important packages that affect multiple people. Now, if you really want this "fixed", then you're going to need to do the leg work. We aren't interested in spending the time necessary. That's what I am trying to do. But I also have a paying job to do, so I wouldn't like to waste my time doing something someone else has already tried and failed without knowing what and why. So is anyone aware if someone did actually document the reasons for -amd64 or was it just "it does not compile cleanly out of the box, let's make it -arch". Created attachment 79563 [details, diff]
neuralnet_amd64_atlas_include.patch
Patch to resolve the compile problem described in the beginning of this bug. Problem is ATLAS, for some probably blas-atlas related installation problem the include needs 'atlas/' to point the right header file.
It segfaults now, so once more: Could anyone guide me where to find reasons for -amd64?
|