/xorg-x11/lib/libGL.so.1 can't be prelinked I first began seeing this message after upgrading to xorg-x11-7.1. Note that I'm using the xorg radeon driver only; I've never installed the ATI proprietary drivers on this box. Reproducible: Always Steps to Reproduce: 1.# prelink -amR 2. 3. Actual Results: Error messages like: prelink: /usr/bin/glxgears: Cannot prelink against non-PIC shared library //usr//lib/opengl/xorg-x11/lib/libGL.so.1 prelink: /usr/bin/mplayer: Cannot prelink against non-PIC shared library //usr//lib/opengl/xorg-x11/lib/libGL.so.1 ... etc.
Please paste the output of "emerge --info" as a reply to this bug so that Gentoo devs can help you.
Sorry, my original post copied the format of another, resolved prelink bug that didn't include any "emerge --info": http://bugs.gentoo.org/show_bug.cgi?id=106412 Here's mine: Portage 2.1_rc4-r5 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.3.6-r3, 2.6.16-gentoo-r9 i686) ================================================================= System uname: 2.6.16-gentoo-r9 i686 AMD Sempron(tm) Processor 2800+ Gentoo Base System version 1.6.14 ccache version 2.4 [enabled] dev-lang/python: 2.4.2 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r1 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 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-r2 sys-devel/gcc-config: 1.3.13-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon64 -msse3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/lib/X11/xkb /usr/share/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -march=athlon64 -msse3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig buildpkg ccache distlocks metadata-transfer sandbox sfperms strict userfetch" GENTOO_MIRRORS="http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/" LANG="en_US.utf8" LC_ALL="en_US.utf8" LDFLAGS="-Wl,-O1" LINGUAS="en" 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="/usr/portage/tmp" PORTDIR="/usr/portage/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowext X aac acpi alsa apache2 apm berkdb bitmap-fonts bzip2 cairo cdparanoia cli crypt css cups dri dvd dvdr dvdread emboss encode fbcon flac foomaticdb fortran gdbm gif glibc-omitfp glitz gnome gpm gtk gtk2 hal imlib isdnlog java jpeg lcms libg++ libwww live mad matroska mikmod mime mmx mmxext motif mp3 mpeg ncurses nptl nptlonly nsplugin ogg opengl oss pam pcre pdf pdflib perl pic png pppd python quicktime readline real reflection rtc sdl session spell spl sse sse2 ssl svg svga tcpd theora threads tiff truetype truetype-fonts type1-fonts udev unicode vorbis win32codecs xml xml2 xorg xv xvid zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux linguas_en userland_GNU video_cards_apm video_cards_radeon video_cards_vesa" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_RSYNC_EXTRA_OPTS
Exactli the same problem. It was present before I use gcc-4.1.1 Portage 2.1 (default-linux/x86/2005.1, gcc-4.1.1/vanilla, glibc-2.4-r3, 2.6.16-ck11-K7 i686) ================================================================= System uname: 2.6.16-ck11-K7 i686 AMD Sempron(tm) 2500+ Gentoo Base System version 1.12.1 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.3.5-r2, 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.18.1 sys-devel/autoconf: 2.13, 2.59-r7 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-r2 sys-devel/gcc-config: 2.0.0_rc1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -Os -falign-loops -freorder-blocks -pipe -fomit-frame-pointer -finline-functions --param max-inline-insns-auto=24" 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" CONFIG_PROTECT_MASK="/etc/env.d /etc/eselect/compiler /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-march=athlon-xp -Os -falign-loops -freorder-blocks -pipe -fomit-frame-pointer -finline-functions --param max-inline-insns-auto=24" DISTDIR="/mnt/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict userpriv" GENTOO_MIRRORS="http://ftp.sh.cvut.cz/MIRRORS/gentoo/gentoo http://ftp.linux.cz/pub/linux/gentoo " LANG="cs_CZ.UTF-8" LC_ALL="cs_CZ.UTF-8" LINGUAS="en en_GB en_US cs" MAKEOPTS="-j2" PKGDIR="/root/work/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://ftp.sh.cvut.cz/gentoo-portage" USE="x86 3dnow 3dnowext 7zip X X509 a52 aac ada afs aim alsa apache2 apm arts asf async audiofile avi bash-completion berkdb bidi bitmap-fonts bl blas bluetooth bookmarks bzip2 cairo canvas caps cdparanoia chroot clearcase cli crosscompile crypt cups curl cvs dba djbfft djvu doc dri dts dv dvb dvd dvdread dvi ecc eds emboss encode examples exif expat fam ffmpeg firefox flac foomaticdb fortran fpx freetype fuse gd gdbm gif gimp glep glitz glut gmp gnutls gphoto2 grammar graphviz gs gtk gtk2 gzip haskell hdf5 httpd iconv icq id3 idn imagemagick imlib imlib2 iproute2 ipv6 irc irda isdnlog jabber javascript jbig jpeg jpeg2k kde kqemu lame lcms libg++ libsamplerate libwww live lm_sensors logrotate lzo lzw-tiff mad mailwrapper math matroska md5sum mikmod mmap mmx mmxext mng mod modplug mp3 mp4 mp4live mpeg mpeg2 msn multicall musepack nas ncurses netboot network nls nntp no-old-linux no_wxgtk1 nodrm nptl nptlonly nsplugin objc ocaml ogg oggvorbis on-the-fly-crypt openal openexr opengl pam pam_chroot pascal pcre pda pdf pdflib perforce perl php pic player plotutils png ppds pppd python qt quicktime rdesktop readline real reflection rle rogue rss rtc ruby samba sametime scanner screen sdl serial session shout silc slang sms sndfile speex spell spl sql sqlite sse ssl stencil-buffer stream subversion svg swat t1lib tcltk test tetex theora thesaurus tiff truetype truetype-fonts type1-fonts unicode usb userlocales utf8 v4l v4l2 vcd vdr vhosts vim-pager vim-with-x vlm vorbis win32codecs wxwindows x264 xanim xatrix xine xml xml2 xorg xosd xpm xprint xscreensaver xv xvid yv12 zip zlib dvb_cards_dibusb-usb1 dvb_cards_dibusb-usb2 dvb_cards_or51132 dvb_cards_or51211 dvb_cards_ttpci dvb_cards_usb-a800 dvb_cards_usb-dtt200u dvb_cards_usb-umt dvb_cards_usb-vp702x dvb_cards_usb-vp7045 dvb_cards_usb-wt220u elibc_glibc input_devices_acecad input_devices_aiptek input_devices_calcomp input_devices_citron input_devices_digitaledge input_devices_dmc input_devices_dynapro input_devices_elo2300 input_devices_elographics input_devices_evdev input_devices_fpit input_devices_hyperpen input_devices_jamstudio input_devices_joystick input_devices_keyboard input_devices_magellan input_devices_magictouch input_devices_microtouch input_devices_mouse input_devices_mutouch input_devices_palmax input_devices_penmount input_devices_spaceorb input_devices_summa input_devices_synaptics input_devices_tek4957 input_devices_ur98 input_devices_vmmouse input_devices_void input_devices_wacom kernel_linux linguas_en linguas_en_GB linguas_en_US linguas_cs userland_GNU video_cards_apm video_cards_ark video_cards_ati video_cards_chips video_cards_cirrus video_cards_cyrix video_cards_dummy video_cards_-fglrx video_cards_glint video_cards_i128 video_cards_i740 video_cards_i810 video_cards_imstt video_cards_mach64 video_cards_mga video_cards_-newport video_cards_neomagic video_cards_nsc video_cards_nv video_cards_-nvidia video_cards_r128 video_cards_radeon video_cards_rendition video_cards_s3 video_cards_s3virge video_cards_savage video_cards_siliconmotion video_cards_sis video_cards_sisusb video_cards_tga video_cards_trident video_cards_tseng video_cards_v4l video_cards_vesa video_cards_vga video_cards_via video_cards_vmware" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPT
Take also a look into this thread (it is the same problem): http://forums.gentoo.org/viewtopic-t-468064-highlight-.html An this bug at freedesktop.org: https://bugs.freedesktop.org/show_bug.cgi?id=6624
(In reply to comment #4) > Take also a look into this thread (it is the same problem): > http://forums.gentoo.org/viewtopic-t-468064-highlight-.html > An this bug at freedesktop.org: > https://bugs.freedesktop.org/show_bug.cgi?id=6624 > I doubt these are related to this problem. In any case, I don't see any obvious sign that it's not being told to build with PIC...
I think different, as far as I know everyone with the prelink-failure got also a problem with glxgears/visual-errors. Of course, it is "not the same", but they are seem to be in a connection.
same problem here on a Compaq Presario 2100US. I DIDN'T have any problems with graphics/glxgears before prelinking although I haven't tried it after (I'm not on or near the laptop now so I can't pose emerge --info or try glxgears though I beleive I am using GCC 3.4.4 and the newest ~x86 xorg-x11 packages). A fix/response really would be helpful.
(In reply to comment #7) > same problem here on a Compaq Presario 2100US. I DIDN'T have any problems with > graphics/glxgears before prelinking although I haven't tried it after (I'm not > on or near the laptop now so I can't pose emerge --info or try glxgears though > I beleive I am using GCC 3.4.4 and the newest ~x86 xorg-x11 packages). A > fix/response really would be helpful. > Ok, it's conformed I do now have glx problems, specifically libGL.so.1 complains about opening DRM failing as the operation is not permitted hence I no longer have direct rendering support.
mythbackend: error while loading shared libraries: libGL.so.1: cannot handle TLS data This is a show stopper for Mythtv. Began when I upgraded to xorg-x11-7.1 TLS, (Thread Local Storage). libGL.so.1 points (eventually) to libGL.so.1.2. Suspect feature for 3D rendering was recently added and is braking other things. cbl ~ # emerge --info Portage 2.1_rc4-r3 (default-linux/x86/2006.0, gcc-20050110, glibc-2.3.3.20040420-r0, 2.6.11-rc5 i686) ================================================================= System uname: 2.6.11-rc5 i686 AMD Athlon(tm) XP 1700+ Gentoo Base System version 1.4.16 dev-lang/python: 2.3.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.59-r7 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.14.90.0.8-r1 sys-devel/libtool: 1.4.3-r4, 1.5.22 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /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/gconf /etc/revdep-rebuild /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=i686 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--alphabetical" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="ftp://206.75.217.181/ ftp://gentoo.mirrors.tds.net/gentoo http://gentoo.mirrors.pair.com /" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --d elete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/package s'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/opt/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X alsa apache2 apm arts avi berkdb bitmap-fonts cli crypt cups dri dvb dvd dvdr eds emacs embos s encode esd foomaticdb fortran ftp gdbm gif gnome gpm gstreamer gtk gtk2 imlib ipv6 isdnlog jpeg kde li bg++ libwww mad mikmod motif mozilla mp3 mpeg mysql mythtv ncurses nls nptl ogg opengl oss pam pcre pdfl ib perl png pppd python qt quicktime readline reflection sdl session sockets spell spl ssl tcpd truetype truetype-fonts type1-fonts udev usb vorbis xine xml xmms xorg xv zlib elibc_glibc kernel_linux userland _GNU" Unset: CTARGET, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS
I can confirm this. During the compile -fPIC does get added to the flags: # emerge -v1 mesa Calculating dependencies... done! >>> Emerging (1 of 1) media-libs/mesa-6.5-r3 to / [...] make[3]: Entering directory `/var/tmp/portage/mesa-6.5-r3/work/Mesa-6.5/src/glx/x11' i686-pc-linux-gnu-gcc -c -I. -I../../../include -I../../../include/GL/internal -I../../../src/mesa/main -I../../../src/mesa/glapi -I../../../src/mesa/drivers/dri/common `pkg-config --cflags libdrm` -I/usr/X11R6/include -Wall -Wmissing-prototypes -O2 -march=pentium-m -pipe -funroll-loops -fno-strict-aliasing -fPIC -m32 -DGLX_USE_TLS -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DHAVE_ALIAS -DDEFAULT_DRIVER_DIR='"/usr/lib/dri"' -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -std=c99 -ffast-math -DXF86VIDMODE -D_REENTRANT -UIN_DRI_DRIVER glcontextmodes.c -o glcontextmodes.o [...] But then there is a strange linker warning about creating a DT_TEXTREL (not sure if this is related): ../../../bin/mklib -o GL -linker 'i686-pc-linux-gnu-gcc' \ -major 1 -minor 2 \ -install ../../../lib -lX11 -lXext -lXxf86vm -lm -lpthread -ldl `pkg-config --libs libdrm` glcontextmodes.o clientattrib.o compsize.o eval.o glxcmds.o glxext.o glxextensions.o indirect.o indirect_init.o indirect_size.o indirect_window_pos.o indirect_transpose_matrix.o indirect_vertex_array.o indirect_vertex_program.o pixel.o pixelstore.o render2.o renderpix.o single2.o singlepix.o vertarr.o xfont.o glx_pbuffer.o glx_query.o glx_texture_compression.o dri_glx.o XF86dri.o ../../../src/mesa/main/dispatch.o ../../../src/mesa/glapi/glapi.o ../../../src/mesa/glapi/glthread.o ../../../src/mesa/x86/glapi_x86.o mklib: Making Linux shared library: libGL.so.1.2 /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../../i686-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object. mklib: Installing libGL.so.1.2 libGL.so.1 libGL.so in ../../../lib make[3]: Leaving directory `/var/tmp/portage/mesa-6.5-r3/work/Mesa-6.5/src/glx/x11' Afterwards, as has been reported, prelink complains: # prelink -amqR prelink: /usr/bin/exrdisplay: Cannot prelink against non-PIC shared library /usr/lib/opengl/xorg-x11/lib/libGL.so.1.2 [...] my emerge --info: Portage 2.1-r1 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.3.6-r4, 2.6.16-suspend2-r8 i686) ================================================================= System uname: 2.6.16-suspend2-r8 i686 Intel(R) Pentium(R) M processor 1.73GHz Gentoo Base System version 1.6.15 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.59-r7 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-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium-m -pipe -funroll-loops" 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/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -march=pentium-m -pipe -funroll-loops" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://mirror.pacific.net.au/linux/Gentoo" LDFLAGS="-Wl,-O1" 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" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X a52 aac acl acpi alsa apache2 arts audiofile avi berkdb bitmap-fonts bluetooth bzip2 cairo cddb cdparanoia cdr cli crypt css cups curl dga dhcp dlloader doc dri dts dv dvd dvdr dvdread emacs encode enscript exif expat ffmpeg flac foomaticdb fortran gcj gdbm gif gimp gimpprint glut gmp gphoto2 gpm graphviz gs idn ieee1394 imagemagick imlib immqt ipv6 isdnlog java javascript jbig jpeg jpeg2k kde kdeenablefinal kerberos latex lcms ldap libg++ libwww live lzo lzw-tiff mad mailwrapper mikmod mmx mmxext mng motif mp3 mpeg mplayer musepack musicbrainz mysql ncurses network nls nodrm nptl nptlonly nsplugin objc odbc ogg openexr opengl pam pcre pdflib perl pic png ppds pppd python qt qt3 quicktime readline real reflection rle rtc sasl scanner session slp sndfile speex spell spl sse sse2 ssl svg tcpd tetex theora threads tiff truetype truetype-fonts type1-fonts udev unicode usb vcd vidix vorbis wifi win32codecs wmf xanim xine xml xorg xpm xprint xv xvid xvmc zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux userland_GNU video_cards_radeon" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY Let me know if I can do additional testing.
I had the same problem when I emerged Mesa (6.5 from portage and also CVS version from XGL overlay) with USE="nptl". Without this flag prelink does not complain, and a warning during emerge about executable stack is gone. But I have no idea why, nptl USE flag enables -DGLX_USE_TLS, which changes a lot of things, many of them in assembly code. I'm on x86, GCC 3.4.6.
(In reply to comment #11) > But I have no idea why, nptl USE flag enables -DGLX_USE_TLS, which changes a > lot of things, many of them in assembly code. Ah, finally something useful! Please file an upstream bug at bugs.freedesktop.org in the mesa product to tell them GLX_USE_TLS prevents PIC builds, and post the URL here.
OK, the report is here: https://bugs.freedesktop.org/show_bug.cgi?id=7459
This has been long overdue. Has anyone heard smthing from upstream?
Nothing in the upstream bug, so no. That's the place to check.
*** Bug 152181 has been marked as a duplicate of this bug. ***
*** Bug 153527 has been marked as a duplicate of this bug. ***
*** Bug 151789 has been marked as a duplicate of this bug. ***
*** Bug 153682 has been marked as a duplicate of this bug. ***
I was having the libGL.so TLS problem even though I don't use prelink. Fixed the problem by building mesa with -ntpl
*** Bug 169841 has been marked as a duplicate of this bug. ***
Try modifying _x86_get_dispatch in glapi_x86.S to: GLNAME(_x86_get_dispatch): #ifdef __PIC__ call 1f 1: popl %edx addl $_GLOBAL_OFFSET_TABLE_+[.-1b], %edx #if 0 movl %gs:0, %eax addl _glapi_tls_Dispatch@GOTNTPOFF(%edx), %eax #else movl _glapi_tls_Dispatch@GOTNTPOFF(%edx), %eax movl %gs:(%eax), %eax #endif /* 0 */ #else movl %gs:_glapi_tls_Dispatch@NTPOFF, %eax #endif /* __PIC__ */ ret
(In reply to comment #22) > Try modifying _x86_get_dispatch in glapi_x86.S to: > GLNAME(_x86_get_dispatch): > #ifdef __PIC__ > call 1f > 1: popl %edx this form of getting EIP has been deprecated for a while now because it plays badly with the return address stack found in modern CPUs, better use the get_pc method as generated by gcc. now with that said, the easier and more future-proof fix is to simply not use the asm GL API dispatch code at all, that is, use CONFIG="linux-dri" in the ebuild (instead of CONFIG="linux-dri-x86" as it is now), maybe based on a USE flag.
(In reply to comment #23) > now with that said, the easier and more future-proof fix is to simply not use > the asm GL API dispatch code at all, that is, use CONFIG="linux-dri" in the > ebuild (instead of CONFIG="linux-dri-x86" as it is now), maybe based on a USE > flag. I believe USE=hardened does that already, in a slightly different fashion.
(In reply to comment #23) > (In reply to comment #22) > > Try modifying _x86_get_dispatch in glapi_x86.S to: > > GLNAME(_x86_get_dispatch): > > #ifdef __PIC__ > > call 1f > > 1: popl %edx > this form of getting EIP has been deprecated for a while now because it plays > badly with the return address stack found in modern CPUs, better use the get_pc > method as generated by gcc. You mean __i686.get_pc_thunk.bx method? I can change that if we go on. > now with that said, the easier and more future-proof fix is to simply not use > the asm GL API dispatch code at all, that is, use CONFIG="linux-dri" in the > ebuild (instead of CONFIG="linux-dri-x86" as it is now), maybe based on a USE > flag. OK, so there is no intresst in making the x86 API TEXTREL free? if so, why is mesa compiled with -fPIC(it is slower, isn't it?) BTW, my suggestion didn't work so I tried another version: GLNAME(_x86_get_dispatch): pushl %ebx call 1f 1: popl %ebx addl $_GLOBAL_OFFSET_TABLE_+[.-1b], %ebx leal _glapi_tls_Dispatch@TLSGD(,%ebx,1), %eax call ___tls_get_addr@PLT movl (%eax), %eax popl %ebx ret This didn't work either, but now I am out of ideas. with this many instructions maybe the C version is just as fast?
(In reply to comment #25) > OK, so there is no intresst in making the x86 API TEXTREL free? > if so, why is mesa compiled with -fPIC(it is slower, isn't it?) It shouldn't be, we actually asked upstream about this which said it should be fine. And indeed.. with Mesa 6.3, or 6.4 -fPIC was still working and performance was equal.
Well, there is no interest from upstream in losing any performance for any reason. If you can fix stuff without doing that, then they'll be all for it.
(In reply to comment #27) > Well, there is no interest from upstream in losing any performance for any > reason. If you can fix stuff without doing that, then they'll be all for it. > Well, I managed to get GLNAME(_x86_get_dispatch): #ifdef __PIC__ call 1f 1: popl %edx addl $_GLOBAL_OFFSET_TABLE_+[.-1b], %edx movl _glapi_tls_Dispatch@GOTNTPOFF(%edx), %eax movl %gs:(%eax), %eax #else movl %gs:_glapi_tls_Dispatch@NTPOFF, %eax #endif /* __PIC__ */ ret to work by disabling the init_glapi_relocs fun in glapi.c This version will not patch the x86 asm code at all and will perform a little worse(although glxgears performs the same for me) This could probably be improved upon by allowing runtime patching of x86 asm code. Would that be accepable? Dunno how to do that though, ideas welcome.
Created attachment 117970 [details] No more TEXTREL for libGL on x86 Managed to extract a patch that works for me that has no TEXTREL. There is only 1 extra instruction in the fast path iff one allows runtime patching of the GL dispatch functions. If you don't want writable text at all, add a -DGLX_X86_READONLY_TEXT to gcc. That will add 5 more instructions to the fast path. Please test and tell me what you think.
Created attachment 118024 [details] No more TEXTREL for libGL on x86 v2 Here is an updated patch. This one has the same performance as the original code in 6.5.2 but is TEXTREL free. Define -DGLX_X86_READONLY_TEXT iff you want non writable .text. This is suitable for hardened users, but also adds 6 instructions to the fast path, but should be faster than the plain C version. Note: This patch only addresses the TLS case. I am pretty much done now and I hope someone can push this patch into gentoo/upstreams. Anyone?
Removing CC. People, you should take this to bugzilla at freedesktop.org to get attention from upstream.
Created attachment 118044 [details] No more TEXTREL for libGL on x86 v3 Oops, a small typo got in. Here is a new one
(In reply to comment #25) > OK, so there is no intresst in making the x86 API TEXTREL free? > if so, why is mesa compiled with -fPIC(it is slower, isn't it?) there's no interest in making the asm optimized versions text relocation free, the normal C dispatch ABI should be (and is) properly PIC. you're right that the asm version at this point doesn't need -fPIC at all, one textrel or a thousand doesn't make a difference for hardened users. > You mean __i686.get_pc_thunk.bx method? I can change that if we go on. yes, the current call/pop is not good. (In reply to comment #32) i think you're misunderstanding something re: textrels here. what we're after is the ability to run GL based apps with the PaX MPROTECT restrictions. textrels are only one source of the problems, in general we want to get rid of runtime code generation. therefore the !GLX_X86_READONLY_TEXT case is simply not needed, if you want that, you might as well stick to the original (faster) asm version, in either case the GL dispatch API will want to do runtime code generation, whether in the form of textrels or the explicit memcpy, it makes no difference for us. now with that said, upstream (well, one particular dev) has explicitly rejected the PIC form of _x86_get_dispatch, so i doubt you'll get much luck pushing it there.
(In reply to comment #33) > (In reply to comment #25) > > OK, so there is no intresst in making the x86 API TEXTREL free? > > if so, why is mesa compiled with -fPIC(it is slower, isn't it?) > > there's no interest in making the asm optimized versions text > relocation free, the normal C dispatch ABI should be (and is) > properly PIC. you're right that the asm version at this point > doesn't need -fPIC at all, one textrel or a thousand doesn't > make a difference for hardened users. > > > You mean __i686.get_pc_thunk.bx method? I can change that if we go on. > > yes, the current call/pop is not good. > > (In reply to comment #32) > > i think you're misunderstanding something re: textrels here. > what we're after is the ability to run GL based apps with the > PaX MPROTECT restrictions. Don't think so, thats why I added GLX_X86_READONLY_TEXT #define > > textrels are only one source of the problems, in general we > want to get rid of runtime code generation. therefore the > !GLX_X86_READONLY_TEXT case is simply not needed, if you want > that, you might as well stick to the original (faster) asm > version, in either case the GL dispatch API will want to do > runtime code generation, whether in the form of textrels or > the explicit memcpy, it makes no difference for us. I want the !GLX_X86_READONLY_TEXT since that is TEXTREL free, but does runtime patching(which also the current code does) of the dispatch table so that the overhead is the same as before my patch. This was the main purpose of this patch. The GLX_X86_READONLY_TEXT was just an addon for hardened users that wanted some better performance. > > now with that said, upstream (well, one particular dev) has > explicitly rejected the PIC form of _x86_get_dispatch, so i I found https://bugs.freedesktop.org/show_bug.cgi?id=4197 Is that that what you are referring to? Don't think he would mind too much, especially if I removed the GLX_X86_READONLY_TEXT case. Then my patch just removes the TEXTREL but retain the same performance. > doubt you'll get much luck pushing it there. Maybe, but I was hoping this could start as an add on patch in gentoo to test it first and possible fix some minor details first. I am running beryl without problems so far.
(In reply to comment #34) > I want the !GLX_X86_READONLY_TEXT since that is TEXTREL free, but > does runtime patching(which also the current code does) of the > dispatch table so that the overhead is the same as before my patch. > This was the main purpose of this patch. The GLX_X86_READONLY_TEXT was > just an addon for hardened users that wanted some better performance. let me ask it this way: what is the benefit of removing the textrels and *still* requiring runtime code generation? what does it help? it certainly does *not* help hardened users who have PaX with MPROTECT on. also you have yet to show that the READONLY_TEXT code has better performance than the C dispatch code. nor does it help non-hardened users since they can just use the current code with textrels and get the best performance out of it without any extra patches needed. the prelink issue is a non-problem as well because noone should be using it anyway in the days of ASLR and the GNU_HASH stuff in newer ld (http://sourceware.org/ml/binutils/2006-06/msg00418.html). in other words, there's only one problem to solve here: getting rid of textrels *and* runtime code generation (all for hardened only) and that one is solved by the C dispatch code (and is what upstream considers the solution). > I found https://bugs.freedesktop.org/show_bug.cgi?id=4197 > Is that that what you are referring to? yes. > Don't think he would mind too much, especially if I removed the > GLX_X86_READONLY_TEXT case. Then my patch just removes the TEXTREL > but retain the same performance. if you remove the READONLY_TEXT case then you 1. don't solve the hardened problem 2. you don't make the current code any better since it'll still require runtime code generation but i'm not the one deciding what gets into mesa, go try your luck there ;-). also one thing you will have to check out is that your new stub code does not exceed DISPATCH_FUNCTION_SIZE for all possible APIs. in particular, when 'off' no longer fits 1 byte, then your stub size will be 5+6+6=17 bytes which i think is over DISPATCH_FUNCTION_SIZE.
(In reply to comment #35) > (In reply to comment #34) > > I want the !GLX_X86_READONLY_TEXT since that is TEXTREL free, but > > does runtime patching(which also the current code does) of the > > dispatch table so that the overhead is the same as before my patch. > > This was the main purpose of this patch. The GLX_X86_READONLY_TEXT was > > just an addon for hardened users that wanted some better performance. > > let me ask it this way: what is the benefit of removing the textrels > and *still* requiring runtime code generation? what does it help? Prelinking works. > > it certainly does *not* help hardened users who have PaX with MPROTECT on. > also you have yet to show that the READONLY_TEXT code has better performance > than the C dispatch code. I don't intend to show that as am not a PaX user. I figured that maybe some PaX users were interested and then they could test and report. > > nor does it help non-hardened users since they can just use the current > code with textrels and get the best performance out of it without any > extra patches needed. the prelink issue is a non-problem as well because > noone should be using it anyway in the days of ASLR and the GNU_HASH stuff > in newer ld (http://sourceware.org/ml/binutils/2006-06/msg00418.html). Heard of GNU_HASH but didn't know it was that good, maybe I will impl. it in uClibc ld.so and I don't use ASLR. What gentoo ld/glibc has GNU_HASH support? > > in other words, there's only one problem to solve here: getting rid of > textrels *and* runtime code generation (all for hardened only) and that > one is solved by the C dispatch code (and is what upstream considers the > solution). > > > I found https://bugs.freedesktop.org/show_bug.cgi?id=4197 > > Is that that what you are referring to? > > yes. > > > Don't think he would mind too much, especially if I removed the > > GLX_X86_READONLY_TEXT case. Then my patch just removes the TEXTREL > > but retain the same performance. > > if you remove the READONLY_TEXT case then you > > 1. don't solve the hardened problem I know and I don't mind > 2. you don't make the current code any better since it'll still require > runtime code generation My goal was to get rid of the TEXTREL and maintain performance. I added the READONLY option because I figured that it would be interesting to hardened users, but it doesn't seem so. > > but i'm not the one deciding what gets into mesa, go try your luck there ;-). :), if nobody here is interested I won't. I wanted to push this as a gentoo addon that possibly could make its way into upstrems one day. > > also one thing you will have to check out is that your new stub code does > not exceed DISPATCH_FUNCTION_SIZE for all possible APIs. in particular, when > 'off' no longer fits 1 byte, then your stub size will be 5+6+6=17 bytes which > i think is over DISPATCH_FUNCTION_SIZE. I have only addressed the TLS case and that one is OK as it is now.
FYI, "No more TEXTREL for libGL on x86 v3" made into mesa 7.0. See bug 7459 in mesa's bugzilla.
