dev-util/bugle currently has only the ~x86 keyword. I am the upstream developer of bugle and do most of the development on AMD64, so I believe it should be suitable for ~amd64. I don't know of any reason it shouldn't also work on other architectures, but I on the other hand I haven't tested it. Reproducible: Always Steps to Reproduce:
2 out of 7 tests fail... It doesn't compile.. It says i should contact you so here it is :) Build log: ------------------------------------------- make[3]: Entering directory `/var/tmp/portage/dev-util/bugle-0.0.20070325/work/bugle-0.0.20070325' PASS: tests/errors.sh PASS: tests/misc.sh FAIL: tests/queries.sh PASS: tests/setstate.sh PASS: tests/triangles.sh Line 2 does not match FAIL: tests/pointers.sh Use of uninitialized value in regexp compilation at ./tests/comparelog.perl line 12. PASS: tests/pbo.sh ============================================= 2 of 7 tests failed Please report to bmerry@users.sourceforge.net ============================================= make[3]: *** [check-TESTS] Error 1 make[3]: Leaving directory `/var/tmp/portage/dev-util/bugle-0.0.20070325/work/bugle-0.0.20070325' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/var/tmp/portage/dev-util/bugle-0.0.20070325/work/bugle-0.0.20070325' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/dev-util/bugle-0.0.20070325/work/bugle-0.0.20070325' make: *** [check] Error 2 !!! ERROR: dev-util/bugle-0.0.20070325 failed. Call stack: ebuild.sh, line 1614: Called dyn_test ebuild.sh, line 1026: Called qa_call 'src_test' environment, line 3577: Called src_test ebuild.sh, line 653: Called die Also my emerge --info: Portage 2.1.2.2 (default-linux/amd64/2006.1/no-multilib, gcc-4.1.1, glibc-2.5-r2, 2.6.20-gentoo-r3 x86_64) ================================================================= System uname: 2.6.20-gentoo-r3 x86_64 AMD Turion(tm) 64 Mobile Technology MT-28 Gentoo Base System release 1.12.9 Timestamp of tree: Thu, 10 May 2007 14:50:01 +0000 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] dev-java/java-config: 1.3.7, 2.0.31-r5 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -msse3 -O2 -pipe" CHOST="x86_64-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" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-march=athlon64 -msse3 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="collision-protect distcc distlocks metadata-transfer multilib-strict sandbox sfperms strict test" GENTOO_MIRRORS="ftp://gentoo.tiscali.nl/pub/mirror/gentoo/" LINGUAS="en nl" MAKEOPTS="-j4" 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-overlay" SYNC="rsync://rsync.nl.gentoo.org/gentoo-portage" USE="X alsa amd64 apache2 bitmap-fonts bzip2 cli cracklib crypt cvs dvd dvdr exif flac gdbm gif gstreamer highlight history iconv imagemagick ipod isdnlog jpeg jpeg2k kde latex libg++ md5sum midi mp3 mplayer music ncurses nls nomotif nptl nptlonly ogg opengl oss pcre pdf perl png ppds pppd python qt readline reflection samba session spl ssl tcpd test tetex truetype-fonts type1-fonts unicode vorbis xine xml xml2 xorg zlib" ALSA_CARDS="intel8x0" 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" ELIBC="glibc" INPUT_DEVICES="keyboard mouse synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en nl" USERLAND="GNU" VIDEO_CARDS="sis" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
It looks like it compiles, it just fails some of the tests. That's more likely to be the OpenGL driver than the architecture, but I guess we should investigate it to be sure. Can you tell me what OpenGL driver you're using, and also attach the files tests/queries.base.log, tests/queries.log, tests/pointers.base.log and tests/pointers.log from the build directory.
O crap you are right :) The opengl drivers could indeed be the problem... I have a crappy sis videocard in my laptop... Here is the openGL stuf: OpenGL vendor string: Mesa project: www.mesa3d.org OpenGL renderer string: Mesa GLX Indirect OpenGL version string: 1.4 (1.5 Mesa 6.5.2) I'll attach the files...
Created attachment 118851 [details] pointer.base.log
Created attachment 118853 [details] pointers.log
Created attachment 118854 [details] queries.base.log
Created attachment 118856 [details] queries.log
Same tests fail here; I have working opengl (intel 945 on mesa). I would have said it's a 64-bit problem, but it doesn't have any of the typical warnings of non-64-bit-clean code.
I tested this on an nvidia video card with amd64 and the same tests fail. Maybe the tests are just non amd64 compatible...
It looks like the culprit is Mesa - I can reproduce the same failures (and with similar logs) if I switch to Mesa OpenGL (eselect opengl set xorg-x11), while everything passes with NVIDIA OpenGL. I'll need to do some more investigation to find out if this is actually a Mesa bug or if I'm making dodgy API calls that NVIDIA is just handling better.
My guess is that it's not working because of direct rendering, would be nice to see if it fails for someone who uses Mesa for direct rendering :>
You're just about right, assuming that you meant "it's not working because of indirect rendering". I haven't tracked the queries.sh failure yet, but the pointers.sh failure is due to a bug in Mesa's indirect rendering code that I've just filed (https://bugs.freedesktop.org/show_bug.cgi?id=10938). I strongly suspect this will affect x86 as well. Will confirm when I've had a chance to check it out.
It appears that both failures occur in the same way when using Mesa indirect rendering on x86 i.e., they are not amd64 specific. When you tested on the NVIDIA card, were you perhaps using indirect rendering?
I just checked and it indeed did. (it is not my system so i didn't know for sure). But then it is an indirect rendering problem....
My tests were done on mesa with working DRI. So it's not an indirect rendering problem.
Daniel: if you're using DRI, then the failures are for different reasons. Would you mind attaching the same logfiles that Roeland did (see comment #2), as well as the output of glxinfo? Also if you have a 32-bit install on that machine, or another 32-bit machine with a similar setup, I'd be interested to know if you can reproduce the bug. So far I don't believe that any of the test failures have been confirmed as 64-bit specific, and while with my BuGLe hat on I'm working at fixing these problems, the thread seems to have wondered a bit off the original topic of adding the ~amd64 keyword to the build.
Okay, looking at the logs of the two failures, it does appear to be DRI related: libGL error: open DRM failed (Operation not permitted) libGL error: reverting to (slow) indirect rendering DRM generally works: [19:51:33 athena] ~> glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: Yes glxgears (and my 3D games, of course) all work correctly. The following tests complained they couldn't open DRM: athena tests # grep DRM *.log pbo.log:libGL error: open DRM failed (Operation not permitted) pointers.log:libGL error: open DRM failed (Operation not permitted) queries.log:libGL error: open DRM failed (Operation not permitted) setstate.log:libGL error: open DRM failed (Operation not permitted) triangles.log:libGL error: open DRM failed (Operation not permitted) Only pointers and queries actually failed, tho. I can still post full logs, if you want.
Oh, and I don't have 32-bit of any kind on this box, sorry.
It sounds like it probably is the same issues then. The other failure I've also traced to a Mesa problem, which I've filed (https://bugs.freedesktop.org/show_bug.cgi?id=11003). At this point, is there any reason not to mark the package ~amd64?
Well, there's still the question of why those tests fail to use perfectly fine DRM... If it's believed that's not an issue (ie, it won't come up while using the thing) then I'm fine.
Are you getting that error from a manual 'make check', or with ebuild? If the latter, my first guess would be that it is sandbox-related. Also try installing bugle, then running LD_PRELOAD=/path/to/libbugle.so glxgears That should tell you whether you'll get the error.
Well, it runs with glxgears, and eventually (after ~5 iterations) gets up to full speed, so I'll say it works.
