At least for people using hardened the following error appears in Xorg.log: [ 47.835] (EE) AIGLX error: dlopen of /usr/lib64/dri/nouveau_dri.so failed (/usr/lib64/dri/nouveau_dri.so: undefined symbol: _glapi_get_proc_address) According to some people on IRC this is an issue for Gallium3D driver for Radeon too, but not for the classic mesa driver. By using the command rebind to weakning the symbol X can load the symbol, so this may be an issue with gallium and -z,now. By linking nouveau_dri.so to libGL.so the message also disappears, but that is not a fix since (according to ajax) nouveau_dri.so then may pick up stuff like the dispatcher from libGL which it is supposed to pick up by a providing Xserver. emerge --info Portage 2.2_rc67 (hardened/linux/amd64/10.0, gcc-4.4.4, glibc-2.11.2-r0, 2.6.34-hardened x86_64) ================================================================= System uname: Linux-2.6.34-hardened-x86_64-Intel-R-_Core-TM-_i7_CPU_920_@_2.67GHz-with-gentoo-2.0.1 Timestamp of tree: Sun, 18 Jul 2010 15:30:09 +0000 ccache version 2.4 [disabled] app-shells/bash: 4.1_p7 dev-java/java-config: 2.1.11 dev-lang/python: 2.6.5-r3, 3.1.2-r4 dev-util/ccache: 2.4-r8 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.1-r1 sys-apps/sandbox: 2.2 sys-devel/autoconf: 2.13, 2.65-r1 sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.4-r1 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.10 virtual/os-headers: 2.6.34 ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe -ggdb -mtune=native" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=native -O2 -pipe -ggdb -mtune=native" DISTDIR="/var/portage/distfiles" FEATURES="assume-digests distlocks fixpackages metadata-transfer news parallel-fetch preserve-libs protect-owned sandbox sfperms splitdebug strict test unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://ftp.sunet.se/pub/os/Linux/distributions/gentoo" INSTALL_MASK="*.la" LANG="sv_SE.UTF-8" LC_ALL="C" LDFLAGS="-Wl,--as-needed -Wl,-O1 -Wl,--sort-common -Wl,--warn-once,--hash-style=gnu" LINGUAS="sv en" MAKEOPTS="-j10 -l10" PKGDIR="/var/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="/var/tmp" PORTDIR="/var/portage" PORTDIR_OVERLAY="/var/overlays/layman/java-overlay /var/overlays/layman/hardened-development /var/overlays/layman/gamerlay /var/overlays/layman/x11 /var/overlays/mine" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac accessibility acl acpi alsa amd64 amr amrnb amrwb applet archive asyncns avahi bash-completion bluetooth branding bzip2 cairo ccache cdaudio cdda cdr cleartype cli consolekit coverart cracklib crypt cups cxx dbus device-mapper devicekit devkit dhcpcd digitalradio dirac djvu dmraid dri dts dvd dvdr dvi eds encode eselect evo exif faac faad fat fbcondecor ffmpeg fftw flac fontconfig fuse gdbm gdm gdu gif gimp glib gmp gnome gnome-keyring gphoto2 gpm grammar graphite gsf gsm gstreamer gtk gudev hal hardened hpn ical iconv iconvacl icq icu id3tag idn ieee1394 iptc ithreads jabber jack java6 jingle jpeg jpeg2k justify kate kvm lcms libffi libnotify libsamplerate logrotate lvm lvm2 lzma mad maps math matroska md mdadm midi mms mmx mmxext mng moonlight mp2 mp3 mpeg mpi msn mtp mudflap multilib musepack musicbrainz nautilus ncurses network-cron networkmanager nfs nls nntp nptl nptlonly ntfs offensive ogg openal opencore-amr opengl openmp openntpd ots pam pango parted pcre pdf perl pic pidgin playlist png policykit pppd pulseaudio python quicktime raw readline reflection rrdcgi rtmp samba sensord session smp sms speex spell spl sse sse2 ssl ssse3 startup-notification subversion svg sysfs test tex theora thesaurus threads tiff totem truetype udev unicode upnp urandom usb userlocales v4l2 vaapi vdpau vhook videos vim-syntax vorbis vpx webkit wmf x264 xcb xcomposite xmp xmpp xorg xrandr xscreensaver xulrunner xv xvid xvmc zeroconf zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share 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 cgi cgid 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" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="sv en" QEMU_SOFTMMU_TARGETS="i386 x86_64" QEMU_USER_TARGETS="i386 x86_64" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nouveau" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Eh, remi sorry, but this is with media-libs/mesa-7.8.2 from portage tree, however I think it is true for -9999 from x11-overlay as well (have not heard any conflicting opinions).
Me too: [ 26487.647] (EE) AIGLX error: dlopen of /usr/lib64/dri/r600_dri.so failed (/usr/lib64/dri/r600_dri.so: undefined symbol: _glapi_get_proc_address) [ 26487.647] (EE) AIGLX: reverting to software rendering [ 26487.647] (II) AIGLX: Screen 0 is not DRI capable [ 26487.651] (EE) AIGLX error: dlopen of /usr/lib64/dri/swrast_dri.so failed (/usr/lib64/dri/swrast_dri.so: undefined symbol: _glapi_get_proc_address) [ 26487.651] (EE) GLX: could not load software renderer [ 26487.651] (II) GLX: no usable GL providers found for screen 0 $ ls -la /usr/lib64/dri/ drwxr-xr-x 2 root root 4096 7. srp 21.50 . drwxr-xr-x 116 root root 139264 7. srp 21.50 .. lrwxrwxrwx 1 root root 22 7. srp 21.50 radeong_dri.so -> ../mesa/radeong_dri.so lrwxrwxrwx 1 root root 22 7. srp 01.31 r300_dri.so -> ../mesa/radeong_dri.so lrwxrwxrwx 1 root root 20 7. srp 01.26 r600_dri.so -> ../mesa/r600g_dri.so lrwxrwxrwx 1 root root 20 7. srp 21.50 r600g_dri.so -> ../mesa/r600g_dri.so lrwxrwxrwx 1 root root 22 7. srp 20.45 swrast_dri.so -> ../mesa/swrastg_dri.so lrwxrwxrwx 1 root root 22 7. srp 21.50 swrastg_dri.so -> ../mesa/swrastg_dri.so Whenever was mesa with gallium compiled by hardened gcc including hardenednopie, hardenednopiessp and hardenednossp profile, then it failed with undefined symbol: _glapi_get_proc_address. Just now it is impossible run gallium mesa with hardened gcc not only on nouveau but on r600g too. I reported this strange behavior in May 2010, but I never thought that the problem can be with hardened gcc.
profiles/base/package.use.mask # Still not really functional, upstream requires not building it. <media-libs/mesa-7.9 gallium Will not fix it before that mask is removed.
Getting the same error on x86 non-hardened profile.
(In reply to comment #3) > profiles/base/package.use.mask > # Still not really functional, upstream requires not building it. > <media-libs/mesa-7.9 gallium > Will not fix it before that mask is removed. > This is a bad solution to an already slow move in gallium. The bug should be fixed and a patch sent upstream now to prevent users from having to wait. Yes we are all aware that this is experimental but still without those testing and reporting issues this will not be resolved.
Created attachment 243305 [details] mesa-7.8.2-gallium-workaround This is just as it says, a workaround for those wanting to test. As this is a module used by X.org it should be treated as any other xorg component and be built with lazy binding.
A maybe more appropriate workaround (or maybe even fix?) for xorg-server is here: https://bugs.freedesktop.org/show_bug.cgi?id=30303
This is only a problem for people using AIGLX. When X already has started, the gallium drivers resolv this symbol back to libGL.so, which exports it correctly as PUBLIC. However when xserver starts up it tries to initiate AIGLX, and while doing it the driver resolves the symbols to the xserver glx module. And since one commit in mesa (http://cgit.freedesktop.org/mesa/mesa/commit/?id=8d62eb45997a199e116661e26217b4d44fb9ba1e) was never applied to xserver, that module does not export _glapi_get_proc_address as public, and gallium drivers fails. I cannot answer why this does not break for non-hardened. It may very well be that when the module is -z,lazy then when the functions are called AIGLX does resolv the symbols to libGL instead, but I do not know and tries to reach upstream for a comment. But I can confirm that marking _glapi_get_proc_address as PUBLIC in xserver/glx/glapi.c does make nouveau_dri.so load when mesa is compiled with -z,now.
(In reply to comment #7) > A maybe more appropriate workaround (or maybe even fix?) for xorg-server is > here: > https://bugs.freedesktop.org/show_bug.cgi?id=30303 > This patch works fine for me, thanks. I confirm that marking _glapi_get_proc_address as PUBLIC in xserver/glx/glapi.c does make nouveau_dri.so load when mesa is compiled with -z,now.
Created attachment 249787 [details, diff] Mark _glapi_get_proc_address PUBLIC Patch against xserver git, works with at least xorg-server-1.9.0
The _glapi_get_proc_address patch for xserver seems to work with xorg-server-1.9.2.901 on hardened. Running gallium radeon r300 now :)
I'm seeing this issue using the Intel/Gallium drivers on ~x86-64. # emerge mesa libdrm xf86-video-intel xorg-server -pv These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] x11-libs/libdrm-2.4.23 USE="libkms -static-libs" VIDEO_CARDS="intel -nouveau -radeon -vmware" 0 kB [ebuild R ] media-libs/mesa-7.10 USE="classic gallium llvm motif nptl pic -debug -gles (-selinux)" VIDEO_CARDS="intel -mach64 -mga -nouveau -r128 -radeon -savage -sis -tdfx -via -vmware" 0 kB [ebuild R ] x11-base/xorg-server-1.9.3.901 USE="ipv6 nptl udev xorg -dmx -doc -kdrive -minimal -static-libs -tslib" 0 kB [ebuild R ] x11-drivers/xf86-video-intel-2.14.0 USE="dri" 0 kB # grep EE /var/log/Xorg.0.log [502188.811] Current Operating System: Linux irrational 2.6.37-gentoo #1 SMP PREEMPT Wed Jan 5 12:11:49 EST 2011 x86_64 (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [502188.814] (II) Loading extension MIT-SCREEN-SAVER [502188.816] (EE) Failed to load module "vesa" (module does not exist, 0) [502188.816] (EE) Failed to load module "fbdev" (module does not exist, 0) [502189.300] (EE) AIGLX error: dlopen of /usr/lib64/dri/i965_dri.so failed (/usr/lib64/dri/i965_dri.so: undefined symbol: _glapi_get_proc_address) [502189.300] (EE) AIGLX: reverting to software rendering [502189.301] (EE) AIGLX error: dlopen of /usr/lib64/dri/swrast_dri.so failed (/usr/lib64/dri/swrast_dri.so: undefined symbol: _glapi_get_proc_address) [502189.301] (EE) GLX: could not load software renderer so this bug still exists in the latest versions available in portage today.
(In reply to comment #12) > so this bug still exists in the latest versions available in portage today. > Not so strange as this patch has yet to reach portage. Better yet if someone with a bit of time could poke upstream in mailinglist or alike and get this checked in there, or a explanation on why this should not go in...
Ok, since upstream as always hesitates when there is a problem only seen by Gentoo Hardened I ask of you in this bug: is there anyone who have had issues apart from the ugliness in the logs? Nothing should be by this message affected except stuff doing indirect rendering, and it seems like there are not many application doing that anymore. So if you have a case where the loss of indirect rendering breaks your system, we will gladly accept it.
(In reply to comment #14) > Ok, since upstream as always hesitates when there is a problem only seen by > Gentoo Hardened I ask of you in this bug: is there anyone who have had issues > apart from the ugliness in the logs? no problem. http://codepad.org/XsI35sVJ
(In reply to comment #14) > Ok, since upstream as always hesitates when there is a problem only seen by > Gentoo Hardened I ask of you in this bug: is there anyone who have had issues > apart from the ugliness in the logs? In my case, it breaks both glxinfo and glxgears. Applying the the patch from attachment 249787 [details, diff] makes glxinfo output info again. Without the patch: ohj@siv ~> glxinfo name of display: :0 Error: couldn't find RGB GLX visual or fbconfig With the patch: ohj@siv ~> glxinfo name of display: :0 display: :0 screen: 0 direct rendering: Yes <snip> This is on ~amd64 hardened with gallium radeon driver.
(In reply to comment #16) > In my case, it breaks both glxinfo and glxgears. Applying the the patch from > attachment 249787 [details, diff] makes glxinfo output info again. > Coul you please provide your xorg.conf (if any), and your Xorg.log so I may try to find a way to reproduce?
Created attachment 265051 [details] Xorg.log when failing to to load GLX
For some reason it refuses to let me attach the xorg.conf file, it gives error message "You already used the form to file attachment 265051 [details].". But basically my xorg.conf only contains a files section with font paths and a serverflags section with some DPMS stuff and dontzap option.
Created attachment 266199 [details] Xorg backtrace hmm... I can't seem to get one from mesa 7.10.1 ... This segfault happens with the given patch when gallium is enabled
Created attachment 266201 [details] mesa emerge --info neglected to mention mesa version (7.9.1)
This seem to be fixed in xserver master branch [1]. I have been running x11-base/xorg-server-1.10.1, x11-base/xorg-server-1.10.0.902 and x11-base/xorg-server-1.10.0.901 with patch from [1] for a while now without any trouble. [1] http://cgit.freedesktop.org/xorg/xserver/commit/?id=17d9e374721d6c8ee3f7f9cdc882f80127bdb57f
(In reply to comment #22) > http://cgit.freedesktop.org/xorg/xserver/commit?id=17d9e374721d6c8ee3f7f9cdc882f80127bdb57f Me find master candy has, wooohoooo!:-D @x11-herd, any possibility of adding this patch ontop of xorg-server-1.10.*? It applies cleanly on top of 1.10.1, the server starts, and stuff seems to work without scary messages in logfiles. I do not know exactly how you do test AIGLX, I think I heard something about LIBGL_ALWAYS_INDIRECT doing that job, but I am not sure...
(In reply to comment #23) > (In reply to comment #22) > > http://cgit.freedesktop.org/xorg/xserver/commit?id=17d9e374721d6c8ee3f7f9cdc882f80127bdb57f > > Me find master candy has, wooohoooo!:-D It's so rare that if you eat it you'll get an extra level. Congrats!
Applied without a revbump.
I had to patch this manually myself on 1.9.5 on x86... perhaps the patch should be backported?
(In reply to comment #26) > I had to patch this manually myself on 1.9.5 on x86... perhaps the patch should > be backported? 1.10 is being stabilized on all arches, so we don't need to backport the patch. Thanks
