One persistent problem with X is that it cannot operate correctly with the immediate symbol loading of -z now, passed to hardened-gcc in its normal spec file. Though -z now is a very important security protection, since you can immediately make those places read-only, it just don't work with X. ajax of the X project told me that getting rid of the circular dependancies that result from using -z now is not a high priority, but that in the meantime we only need to supplant xorg-server and x11-drivers/* packages with -nonow passed as a compile flag. The other libraries, applications, protocols, components etc. of modular X should work with -z now, as he put it, "At your own risk." Since modular X uses the autotools package, the best I can think is to put a 'now' USE flag in xorg-server and the drivers, off by default, that determines whether to add -z now to CFLAGS or not. So somewhere in the pkg_setup, if use now; then : else append-flags -nonow fi Reproducible: Always Steps to Reproduce: 1. switch to a gcc with -z now in the spec file 2. emerge xorg-server 3. startx Actual Results: X fails with circular dependancies: that is, one library refers to symbols defined in another library, but the second library refers to symbols defined in the first. Basically "___ will not load: undefined symbol ____" Expected Results: The drivers and extensions should load, and X should start up. Gentoo Base System version 1.6.13 Portage 2.0.51.22-r3 (hardened/x86/2.6, gcc-3.4.4-vanilla, glibc-2.3.5-r2, 2.6.13-hardened-r2 i686) ================================================================= System uname: 2.6.13-hardened-r2 i686 AMD Sempron(tm) 2200+ distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [disabled] dev-lang/python: 2.3.5-r2, 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.15.92.0.2-r10 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe" CHOST="i686-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/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/ /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig buildpkg distlocks fixpackages sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.mirrors.easynews.com/linux/gentoo/ http://gentoo.osuosl.org/ http://mirror.datapipe.net/gentoo ftp://ftp.ussg.iu.edu/pub/linux/gentoo ftp://gentoo.mirrors.tds.net/gentoo ftp://gentoo.arcticnetwork.ca/pub/gentoo/ http://gentoo.chem.wisc.edu/gentoo/ http://gentoo.seren.com/gentoo ftp://ftp.ndlug.nd.edu/pub/gentoo/ ftp://gentoo.netnitco.net/pub/mirrors/gentoo/source/ ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo http://mirror.phy.olemiss.edu/mirror/gentoo http://gentoo.arcticnetwork.ca/ http://adelie.polymtl.ca/ http://gentoo.gg3.net/ http://ftp.gentoo.or.kr/ http://mirror.isp.net.au/pub/gentoo/ ftp://mirror.isp.net.au/pub/gentoo/ http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/ ftp://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage//packages/x86/" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage/" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.ca.gentoo.org/gentoo-portage" USE="X acpi alsa avi bzlib caps cdr crypt curl dlloader emacs encode fam fortran gd gdbm gif gpm gtk gtk2 guile hardened imagemagick imap imlib jpeg libwww mad mikmod mmx mp3 mpeg mysql ncurses nls nodrm nptl nptlonly offensive ogg oggvorbis opengl pam pcre perl pic png python quicktime readline real ruby samba sasl sdl slang ssl svga tcltk tcpd tetex tiff truetype udev unicode userlocales vorbis x86 xanim xml xml2 xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
I'm still shocked the Xorg team is unable to fix this as we already have before (even provided patches to them/ajax)
Why would we add a USE flag for something that's already known to not work? Am I missing something?
(In reply to comment #1) > I'm still shocked the Xorg team is unable to fix this as we already have before > (even provided patches to them/ajax) uhm, weren't there actually two different kinds of problems? one was what Starling seems to describe (lib on lib dependency), the other was lib on X executable dependency. the latter is what i think ajax was referring to as not high priority as it requires some serious refactoring of the X server itself, and i don't even want to guess how far that would lead (maybe one would end up with a single main() in X itself and the rest as a lib ;-). i know of two instances of the former, both of which we fixed/worked around over the years, i don't know where they went. one was a mutual dependency between glx and GLcore, a one liner patch fixes it (one is poking at some internal variable in another, apparently for no good reason). the second one is iirc the ATI drivers which are built as several .so and reference each other, the solution was to link them altogether into a single .so. are there any other issues left? as for the suggested fix, i don't see the point behind a USE flag either, it either works with -z now and then it should be used (users should have no business tweaking it, especially not under hardened), or it doesn't, then -z nonow has to be used, regardless of user wishes.
(In reply to comment #3) > then -z nonow has to be used, regardless of user wishes. err, i of course meant that '-z now' must not be used (which under hardened means passing -nonow to gcc, there's no '-z nonow' linker switch).
solar, i never got any patches addressing -z now. and it simply is not fixable with X's loader in its current form. the initial issue in moving to dlloader was that modules would reference variables in other modules, which are effectively always resolved with LD_BIND_NOW semantics. that required code fixes, and i think there's only one such issue left that i need to fix before 7.0. -z now enforces resolution at dlopen time for functions too. but X's modules aren't linked against each other at ld time, so this fails. i'd like to address that in 7.1 but i'm not making any promises. it's fixable, but it breaks elfloader compatibility, which i can't do as long as elfloader continues to exist.
Thanks for explaining whats up with the state. Now how do we want to address this? A bunch of tiny patches that are going to be depreciated rather quickly does not seem very ideal.
Yeah, a USE flag does seem to be not the way to go in this case. Easy enough to fix though, by changing if use now; then : else append-flags -nonow fi with just "append-flags -nonow" until the elfloader thing gets resolved. Add that line to the xorg-server, and all the x11-drivers/* ebuild files, and it should work. I hope. No patches necessary, just a modification to the ebuild file itself, the method of construction.
For info, disabling the automatic '-z now' can be done simply by: gcc-specs-now && append-flags -nonow as Donnie says, no USE flags are necessary (gcc-specs-now is in toolchain-funcs.eclass). The 'now' problem can't be solved until the circular symbol resolution dependencies between the various X libraries are removed. X relies on the lazy binding to get around the circular dependencies, on the basis that the symbols that form the circular dependency aren't resolved until all the relevant libraries are loaded. Last time I looked, there was a circular dependency in the ATI driver modules, and another in the GL stuff. Probably more in the other video drivers, particularly those that consist of more than one library. I can understand upstream's reluctance to fix this soon; it'd be quite a disruptive fix. BTW '-z now' doesn't _cause_ the circular dependencies; they're always there. It does however make circular dependencies a real problem. It seemed to me that the original module loader architecture/design was ok; but over time stuff has been added/hacked that didn't respect the architecture or didn't revise the architecture in line with the changing usage.
Please don't change the severity, as the x11 team has its own definitions and makes use of them. In particular, our definition of 'blocker' means 'destroys your system.' I'd prefer to add a hack in the eclass to `append-flags -nonow` rather than editing N ebuilds. Something like a check for xf86-video-* or xf86-input-* or xorg-server as name. Thoughts?
perhaps something like this is what we are after? --- x-modular.eclass 2 Nov 2005 06:11:29 -0000 1.19 +++ x-modular.eclass 10 Nov 2005 00:50:06 -0000 @@ -123,6 +123,9 @@ x-modular_src_configure() { } x-modular_src_make() { + for x in xorg-server xf86-video- xf86-input- ; do + [[ "${PN:0:11}" == "$x" ]] && gcc-specs-now && append-flags -nonow + done emake || die "emake failed" }
You've tested it?
Nope sorry. I'm not willing to break my X
I thought it was supposed to work. If the hardened people aren't willing to test a hardened fix, why should we inflict it upon everyone using modular X? We'll need somebody to test this using the -now specs and confirm.
I went and tested it, and it didn't work. Then I moved the append-flag to above configure (autotools ignores environment, post-configure) and it... didn't work. I visually confirmed that -nonow was being passed to every compile instruction. Tried the input-keyboard, input-mouse, video-vga, video-vesa, and video-via, as well as xorg-server. (I only have a via video card, so can't test ati, nvidia, etc.) The input- drivers seemed to be working, but video- drivers were most certainly not. Even once I'd restored all the old binary ebuilds, created using gcc vanilla, video-vga wouldn't work, so my video card probably got jammed again. (Sometimes it needs a full power down, being cheap UniChrome junk.) video-via works, unlike video-vga. Very odd. I'll ask the #xorg developers for more details about the -nonow issue, and what else hardened gcc might do that screws them up. In the meantime, I recommend this patch, to prevent wasted effort. Might be wise to also check for ssp and relro and all that, though the only problem #xorg people acknowledged so far was the -z now thing. --- x-modular.eclass 2005-11-01 22:35:42.000000000 -0800 +++ x-modular.eclass 2005-11-10 00:52:56.000000000 -0800 @@ -12,7 +12,7 @@ EXPORT_FUNCTIONS src_unpack src_compile src_install pkg_preinst pkg_postinst -inherit eutils libtool +inherit eutils libtool toolchain-funcs # Directory prefix to use for everything XDIR="/usr" @@ -107,6 +107,12 @@ } x-modular_src_unpack() { + for x in xorg-server xf86-video- xf86-input- ; do + [[ "${PN:0:11}" == "$x" ]] && gcc-specs-now && + eerror "Do not emerge ${PN} without gcc vanilla!" && + die "use gcc-config to set gcc to vanilla" + done + x-modular_unpack_source x-modular_patch_source x-modular_reconf_source
(In reply to comment #14) > I went and tested it, and it didn't work. Then I moved the append-flag to above > configure (autotools ignores environment, post-configure) and it... didn't work. can you be more specific beyond "didn't work"? any error messages? also, can you run scanelf -a/readelf -d on all the modules that were supposed to be built with -nonow? then excerpts from your compile log where one/some of these modules are being built (compiled & linked) would be helpful as well. > I visually confirmed that -nonow was being passed to every compile instruction. > Tried the input-keyboard, input-mouse, video-vga, video-vesa, and video-via, as > well as xorg-server. (I only have a via video card, so can't test ati, nvidia, > etc.) The input- drivers seemed to be working, but video- drivers were most > certainly not. > > Even once I'd restored all the old binary ebuilds, created using gcc vanilla, > video-vga wouldn't work, so my video card probably got jammed again. (Sometimes > it needs a full power down, being cheap UniChrome junk.) video-via works, unlike > video-vga. Very odd. > > I'll ask the #xorg developers for more details about the -nonow issue, and what > else hardened gcc might do that screws them up. In the meantime, I recommend > this patch, to prevent wasted effort. Might be wise to also check for ssp and > relro and all that, though the only problem #xorg people acknowledged so far was > the -z now thing. > > --- x-modular.eclass 2005-11-01 22:35:42.000000000 -0800 > +++ x-modular.eclass 2005-11-10 00:52:56.000000000 -0800 > @@ -12,7 +12,7 @@ > > EXPORT_FUNCTIONS src_unpack src_compile src_install pkg_preinst pkg_postinst > > -inherit eutils libtool > +inherit eutils libtool toolchain-funcs > > # Directory prefix to use for everything > XDIR="/usr" > @@ -107,6 +107,12 @@ > } > > x-modular_src_unpack() { > + for x in xorg-server xf86-video- xf86-input- ; do > + [[ "${PN:0:11}" == "$x" ]] && gcc-specs-now && > + eerror "Do not emerge ${PN} without gcc vanilla!" && > + die "use gcc-config to set gcc to vanilla" > + done > + > x-modular_unpack_source > x-modular_patch_source > x-modular_reconf_source >
bleah, sorry for not cleaning up the rest of my previous response, it's apparently too early morning ;P
*** Bug 113760 has been marked as a duplicate of this bug. ***
If I understand correctly, this bug is about the same thing as the FEATURES="stricter" failure. QA Notice: the following files are setXid, dyn linked, and using lazy bindings This combination is generally discouraged. Try re-emerging the package: LDFLAGS='-Wl,-z,now' emerge xorg-server LAZY usr/bin/Xorg
xorg is the only semi valid suid program that needs lazy bindings. It by design is faultly and can be fixed, but upstream is not in a rush to fix that right now. In due time it will be addressed.
However, this bug still requires any users with a hardened profile to have to manually recompile certain drivers and the xorg-server with a vanilla gcc profile, otherwise xorg will not successfully start. This appears to be only because of a very small number of dri/drm/gl symbols which aren't found on startup by X even though everything compiled absolutely fine. Patches would be much appreciated, or failing patches, something in the ebuild to force a non-hardened gcc profile, so that the user doesn't have to make a special case every time an upgrade occurs (and with modular x in testing, hopefully new versions will be many and fast flowing)...
(In reply to comment #14) > --- x-modular.eclass 2005-11-01 22:35:42.000000000 -0800 > +++ x-modular.eclass 2005-11-10 00:52:56.000000000 -0800 > @@ -12,7 +12,7 @@ > > EXPORT_FUNCTIONS src_unpack src_compile src_install pkg_preinst pkg_postinst > > -inherit eutils libtool > +inherit eutils libtool toolchain-funcs > > # Directory prefix to use for everything > XDIR="/usr" > @@ -107,6 +107,12 @@ > } > > x-modular_src_unpack() { > + for x in xorg-server xf86-video- xf86-input- ; do > + [[ "${PN:0:11}" == "$x" ]] && gcc-specs-now && > + eerror "Do not emerge ${PN} without gcc vanilla!" && > + die "use gcc-config to set gcc to vanilla" > + done > + > x-modular_unpack_source > x-modular_patch_source > x-modular_reconf_source > Josh, would you like to commit some form of this? It could probably use a little less of the && and a little more if..then.
Sure, I'll try to find some time soonish to do so.
Committed a functionally identical version to CVS.
*** Bug 116698 has been marked as a duplicate of this bug. ***
not sure why this bug is closed
As far as x11 are concerned, they've resolved it by aborting in the presence of a compiler that defaults -z,now. Since it's of no particular interest to x11 and they're likely to just close it again as a result, reassigning to hardened.
(In reply to comment #18) > QA Notice: the following files are setXid, dyn linked, and using lazy > bindings. This combination is generally discouraged. Try re-emerging > the package: LDFLAGS='-Wl,-z,now' emerge xorg-server As reported in duplicate bug #116698, I do exactly this, setting LDFLAGS in make.conf for my entire system, so the current test only for the specfile doesn't trigger. I've been having to special-case each xorg-server and ati driver upgrade as a result. Thanks for reopening the bug. This still disturbed me since it was still broken for folks just following the instructions in the QA notice. Whatever the solution, please don't ignore that aspect. Duncan
(In reply to comment #5) > -z now enforces resolution at dlopen time for functions too. > but X's modules aren't linked against each other at ld time, > so this fails. i'd like to address that in 7.1 but i'm not > making any promises. So... with 7.1-rc2 now out, /did/ this get into 7.1? I'm about to try the compile now. I guess I'll find out soon enough! =8^) Duncan
(In reply to comment #28) > (In reply to comment #5) > > i'd like to address that in 7.1 but i'm not making any promises. > > So... with 7.1-rc2 now out, /did/ this get into 7.1? > > I'm about to try the compile now. I guess I'll find out soon enough! =8^) Apparently not. =8^( I had the usual warnings about missing symbols for both xf86-video-ati and xorg-server. Thanks to ccache, the recompile went fairly quickly, however, and I'm writing this on xorg-server-1.0.99.902-r1. (exa accel with composite ROCKS! =8^) Duncan
Ok; here goes :) The BIND_NOW problem with X is two-fold. Firstly, when one X module (A) uses another module (B), typically A contains direct references to symbols in B. However it is A that triggers the loading of B (directly or indirectly) so obviously when A is loaded via libdl, B is not loaded so libdl cannot resolve the references to B in A. Normally this sort of straightforward dependency is managed by A having a DT_NEEDED reference to B, so attempts to load A automatically cause B to be loaded first. However X, as always, does things its own way by requiring everything to be linked BIND_LAZY, relying on the design of A to make sure it loads B before any path that references a symbol from B is traversed. I think this problem could be solved relatively easily by making use of the ELF DT_NEEDED header, however I haven't tried this as it can be worked around by manally loading modules in the correct order in xorg.conf. Secondly, some modules depend on each other; i.e. while A refers to symbols in B, B also refers to symbols in A. Although again I think making use of DT_NEEDED might sort this out, it does mean that it's impossible to load modules in the right order (because there's no valid order). So the minimum required to get X working with BIND_NOW (i.e. on hardened) is to eliminate these co-dependencies. Co-dependencies exist between: * the cirrus video driver and its sub-modules * the ati video driver and its sub-modules * glx and GLcore The glx one is a bit tricky; it's been dealt with before by linking GLcore directly into glx, but for the moment I've ignored it as it's not necessary to get an X desktop up and running on ATI or cirrus hardware. Also there's a fair bit of upstream development going on with glx so it's worth waiting until that settles down. However it turns out that it's easy to remove the circular dependencies from those two video drivers, since they only refer to one or two symboles from their submodules. So, patches to follow to do this...
Created attachment 88026 [details, diff] Remove circular references between cirrus driver and its sub-modules. With this patch, in the Device section of xorg.conf one can specify "cirrus" as the driver, and add the following text to the "Module" section and X can be built completely BIND_NOW. Section "Module" ... Load "vgahw" # needed by cirrus Load "int10" # needed by vbe Load "i2c" # needed by ddc Load "ddc" # needed by vbe Load "vbe" # needed by cirrus Load "xaa" # needed by cirrus_alpine Load "ramdac" # needed by cirrus_alpine Load "fb" # needed by cirrus_alpine Load "xf1bpp" # needed by cirrus_alpine Load "xf4bpp" # needed by cirrus_alpine Load "shadowfb" # needed by cirrus_alpine EndSection
Created attachment 88027 [details, diff] Remove circular dependencies between the ATI driver and its sub-modules With this patch, in the Device section of xorg.conf one can specify "ati" as the driver, and add the following text to the "Module" section and X can be built completely BIND_NOW. Section "Module" ... Load "fbdevhw" # needed by radeon Load "xaa" # needed by radeon Load "fb" # needed by exa Load "exa" # needed by radeon Load "int10" # needed by radeon Load "vgahw" # needed by radeon Load "i2c" # needed by ddc Load "ddc" # needed by radeon Load "ramdac" # needed by radeon Load "vbe" # needed by radeon EndSection
As mentioned before, the above two patches are good enough to get a working X, _without_ glx (which means comment out 'Load "glx"' from the "Modules" section if you have it). Obviously one has to commend out the code in x-modular.eclass that chucks you out if you're using the hardened compiler. Other drivers work fine; here are the load sequences for vga: Load "vgahw" # needed by vga_drv Load "int10" # needed by vga_drv Load "fb" # needed by vga_drv Load "xf1bpp" # needed by vga_drv Load "xf4bpp" # needed by vga_drv Load "shadowfb" # needed by vga_drv and for vesa: Load "int10" # needed by vesa Load "i2c" # needed by ddc Load "ddc" # needed by vbe Load "vbe" # needed by vesa Load "fb" # needed by shadow Load "shadow" # needed by vesa Load "mfb" # needed by vesa (also supplied by cfb) Load "xf1bpp" # needed by vesa Load "xf4bpp" # needed by vesa spyderous - the patches supplied are made against the 1.0 versions of the drivers; they also apply directly to the Xorg CVS as it stands today (some slight offsets but nothing of any significance) so should be fine on 1.1 as well. If you're happy to apply these two patches, that's good enough for hardened for now - I'll have a go at glx later, perhaps, but that's not critical. You can then remove the bin-with-hardened-gcc bit from x-modular.eclass - I suggest you replace it with an ewarn pointing users to the hardened Xorg guide at http://www.gentoo.org/proj/en/hardened/hardenedxorg.xml, which we'll update as necessary, to prevent too many users bugging x11 because they haven't done the manual module load thing.
Kevin, please file those upstream at bugs.freedesktop.org, point us to the URL, and nudge us again reopening the bug by when they get committed so we can add them as patches. I don't expect either of these patches to be controversial. Thanks!
Please leeave this bug open till it's resolved @ gentoo
Raised at https://bugs.freedesktop.org/show_bug.cgi?id=7085
Created attachment 88073 [details, diff] fix for glx/GLcore dependency first of all, thanks for fixing these ;-). as i mentioned before, the GL/glcore dependency is easy to fix, see this attachment, i think it still applies.
hmm; haven't tried the patch yet, but scanning glx and GLcore I find 8 symbols referenced by GLcore, defined in glx: __glXFree __glXLastContext __glXMalloc _gl_context_modes_create _gl_context_modes_destroy _gl_convert_from_x_visual_type _gl_convert_to_x_visual_type _gl_copy_visual_to_context_mode so I figured all occurrences of the above in glx need to be removed or looked up via LoadSymbol(). All are used directly in xf86glx.c
i think GLcore depending on glx is not a problem as you Load "glx" which will load GLcore as a submodule, so by that time all symbols of glx are available. the issue is the glx dependence on GLcore, and now that i looked at it more, my patch won't do squat to fix that, it seems glx has the entire GL API unresolved in GLcore, i don't see how that's fixable except for linking GLcore to glx via DT_NEEDED (and hope that ld.so will still resolve the cross-dependence ;-). the next small issue is that glxSetup() has a compile time selection for the actual submodule name ("GL" vs. "GLcore" depending #ifdef GLX_USE_SGI_SI), that would have to be pushed into LDFLAGS (-lgl vs -lGLcore or so).
The main problem as you say is that you can't load "glx" because it needs GLcore to be loaded first (something that would normally be sorted out with DT_NEEDED where the loader would bring in the whole dependency tree and resolve them all together). To work around that, first attempt is to try manually loading GLcore then load glx, like we do for the other modules. However this fails (much like cirrus and ati did) becuase GLcore needs those 8 symbols from glx - mutually dependent modules. Modifying GLcore to look them up at run time via LoadSymbols means the glx symbols are no longer in the GOT and the loader can fix it up without needing glx. That's my understanding, anyway :) I'll have a go over the weekend. Ultimately DT_NEEDED would be better I think, because the pointer data (which is obviously always read/write) added for those symbols wouldn't be required - they could go back to the GOT to be marked read-only after loading. However the X modules often have their own tables of function and data pointers, so there's no real gain at the moment.
(In reply to comment #40) > The main problem as you say is that you can't load "glx" because it needs > GLcore to be loaded first (something that would normally be sorted out with > DT_NEEDED where the loader would bring in the whole dependency tree and resolve > them all together). To work around that, first attempt is to try manually > loading GLcore then load glx, like we do for the other modules. well, that works from our point of view ('fix DSO dependencies') but i'm not sure if it actually works as intended from the glx/GLcore point of view, that is, i don't know whether glx does something important before it loads GLcore that GLcore can't live without. FWIW, i'd been using my patch and the explicit GLcore/glx load order for years myself and it seemed to work, but according to ajax (he should probably be CC'd on this bug) that's not the 'proper way', it was a design decision to not link them via DT_NEEDED and it'd be a lot of work to fix it (whether he meant the kind of work that you plan to do or something more i don't know).
Cannot the workaround with -nonow be implemented for 7.0? I do not see how the X server is ever getting stable if it needs special compiler to build. Plus implementing the workaround would make using the X server much easier. I sure could patch a version of X server locally but I do not want to do it for every new version.
See comment #14 -- it was tested but broke.
(In reply to comment #43) > See comment #14 -- it was tested but broke. > that reported never posted the output. I really don't think he tested properly. Would need to see the output of scanelf -b
Quick update, btw, on progress with glx/GLcore. Things are more complicated than I'd hoped. LoadSymbol can't be used as things stand - while Xorg itself is ok because it links to these libraries anyway, Xvfb doesn't link to the library that defines LoadSymbol, and neither do Xnest and Xprint, I think. Re-organising glx/GLcore is probably out of the question. Previously I think we rigged it to link them as a single shared object (which obviously solves the problem) so I may look at doing that again. Less likely that upstream would approve, however.
The build system somehow ignores the -nonow flag. i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I../../../include -I../../../hw/xfree86 -I../../../hw/xfree86/include -I../../../hw/xfree86/common -I../../../hw/xfree86/os-support -I../../../hw/xfree86/os-support/bus -I../../../os -DHAVE_XORG_CONFIG_H -DXF86PM -DXFree86Server -DIN_MODULE -DXFree86Module -DXFree86LOADER -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I../../../include -I../../../include -I../../../Xext -I../../../composite -I../../../damageext -I../../../xfixes -I../../../Xi -I../../../mi -I../../../miext/shadow -I../../../miext/damage -I../../../render -I../../../randr -I../../../fb -O2 -march=pentium4 -pipe -g -MT mf3-xaaStipple.lo -MD -MP -MF .deps/mf3-xaaStipple.Tpo -c mf3-xaaStipple.c -fPIC -DPIC -o .libs/mf3-xaaStipple.o In file included from mf3-xaaStipple.c:4: ./xaaStipple.c:36: warning: no previous prototype for 'XAAGetStippleScanlineFunc3MSBFirstFixedBase' /bin/sh ../../../libtool --tag=CC --mode=link i686-pc-linux-gnu-gcc -DHAVE_XORG_CONFIG_H -DXF86PM -DXFree86Server -DIN_MODULE -DXFree86Module -DXFree86LOADER -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I../../../include -I../../../include -I../../../Xext -I../../../composite -I../../../damageext -I../../../xfixes -I../../../Xi -I../../../mi -I../../../miext/shadow -I../../../miext/damage -I../../../render -I../../../randr -I../../../fb -O2 -march=pentium4 -pipe -g -Wl,-z,nonow -o libxaa.la -rpath /usr/lib/xorg/modules -avoid-version xaaInit.lo xaaGC.lo xaaInitAccel.lo xaaFallback.lo xaaBitBlt.lo xaaCpyArea.lo xaaGCmisc.lo xaaCpyWin.lo xaaCpyPlane.lo xaaFillRect.lo xaaTEText.lo xaaNonTEText.lo xaaPCache.lo xaaSpans.lo xaaROP.lo xaaImage.lo xaaWrapper.lo xaaPaintWin.lo xaaRect.lo xaaLineMisc.lo xaaBitOrder.lo xaaFillPoly.lo xaaWideLine.lo xaaTables.lo xaaFillArc.lo xaaLine.lo xaaDashLine.lo xaaOverlay.lo xaaOffscreen.lo xaaOverlayDF.lo xaaStateChange.lo xaaPict.lo s-xaaLine.lo s-xaaDashLine.lo l-xaaBitmap.lo l-xaaStipple.lo l-xaaTEGlyph.lo m-xaaBitmap.lo m-xaaStipple.lo m-xaaTEGlyph.lo lf-xaaBitmap.lo lf-xaaStipple.lo lf-xaaTEGlyph.lo mf-xaaBitmap.lo mf-xaaStipple.lo mf-xaaTEGlyph.lo l3-xaaBitmap.lo l3-xaaStipple.lo m3-xaaBitmap.lo m3-xaaStipple.lo lf3-xaaBitmap.lo lf3-xaaStipple.lo mf3-xaaBitmap.lo mf3-xaaStipple.lo -lm i686-pc-linux-gnu-gcc -shared .libs/xaaInit.o .libs/xaaGC.o .libs/xaaInitAccel.o .libs/xaaFallback.o .libs/xaaBitBlt.o .libs/xaaCpyArea.o .libs/xaaGCmisc.o .libs/xaaCpyWin.o .libs/xaaCpyPlane.o .libs/xaaFillRect.o .libs/xaaTEText.o .libs/xaaNonTEText.o .libs/xaaPCache.o .libs/xaaSpans.o .libs/xaaROP.o .libs/xaaImage.o .libs/xaaWrapper.o .libs/xaaPaintWin.o .libs/xaaRect.o .libs/xaaLineMisc.o .libs/xaaBitOrder.o .libs/xaaFillPoly.o .libs/xaaWideLine.o .libs/xaaTables.o .libs/xaaFillArc.o .libs/xaaLine.o .libs/xaaDashLine.o .libs/xaaOverlay.o .libs/xaaOffscreen.o .libs/xaaOverlayDF.o .libs/xaaStateChange.o .libs/xaaPict.o .libs/s-xaaLine.o .libs/s-xaaDashLine.o .libs/l-xaaBitmap.o .libs/l-xaaStipple.o .libs/l-xaaTEGlyph.o .libs/m-xaaBitmap.o .libs/m-xaaStipple.o .libs/m-xaaTEGlyph.o .libs/lf-xaaBitmap.o .libs/lf-xaaStipple.o .libs/lf-xaaTEGlyph.o .libs/mf-xaaBitmap.o .libs/mf-xaaStipple.o .libs/mf-xaaTEGlyph.o .libs/l3-xaaBitmap.o .libs/l3-xaaStipple.o .libs/m3-xaaBitmap.o .libs/m3-xaaStipple.o .libs/lf3-xaaBitmap.o .libs/lf3-xaaStipple.o .libs/mf3-xaaBitmap.o .libs/mf3-xaaStipple.o -lm -march=pentium4 -Wl,-z -Wl,nonow -Wl,-soname -Wl,libxaa.so -o .libs/libxaa.so creating libxaa.la (cd .libs && rm -f libxaa.la && ln -s ../libxaa.la libxaa.la) make[4]: Leaving directory `/var/tmp/portage/xorg-server-1.1.0/work/xorg-server-1.1.0/hw/xfree86/xaa' # scanelf -b /var/tmp/portage/xorg-server-1.1.0/work/xorg-server-1.1.0/hw/xfree86/xaa/.libs/libxaa.so TYPE BIND FILE ET_DYN NOW /var/tmp/portage/xorg-server-1.1.0/work/xorg-server-1.1.0/hw/xfree86/xaa/.libs/libxaa.so
I have built and discovered that xorg-server to be at fault here for ignoring user defined LDFLAGS. First I made the following change x-modular_specs_check() { if [[ ${PN:0:11} = "xorg-server" ]] || [[ -n "${DRIVER}" ]]; then if gcc-specs-now; then msg="${PN} does not work with hardened gcc specs. Switch to vanilla gcc specs to emerge ${PN}." eerror "$msg" #die "$msg" fi # (#116698) breaks loading filter-ldflags -Wl,-z,now append-ldflags -nonow append-flags -nonow fi } Then built it. qlist -e x11-base/xorg-server| scanelf -by -f - TYPE BIND FILE ET_DYN NOW /usr/lib/xorg/modules/libddc.so ET_DYN NOW /usr/lib/xorg/modules/libi2c.so ET_DYN NOW /usr/lib/xorg/modules/multimedia/bt829_drv.so ET_DYN NOW /usr/lib/xorg/modules/multimedia/fi1236_drv.so ET_DYN NOW /usr/lib/xorg/modules/multimedia/msp3430_drv.so ET_DYN NOW /usr/lib/xorg/modules/multimedia/tda8425_drv.so ET_DYN NOW /usr/lib/xorg/modules/multimedia/tda9850_drv.so ET_DYN NOW /usr/lib/xorg/modules/multimedia/tda9885_drv.so ET_DYN NOW /usr/lib/xorg/modules/multimedia/uda1380_drv.so ET_DYN NOW /usr/lib/xorg/modules/libint10.so ET_DYN NOW /usr/lib/xorg/modules/linux/libfbdevhw.so ET_DYN NOW /usr/lib/xorg/modules/linux/libdrm.so ET_DYN NOW /usr/lib/xorg/modules/librac.so ET_DYN NOW /usr/lib/xorg/modules/libramdac.so ET_DYN NOW /usr/lib/xorg/modules/libshadowfb.so ET_DYN NOW /usr/lib/xorg/modules/libvbe.so ET_DYN NOW /usr/lib/xorg/modules/libvgahw.so ET_DYN NOW /usr/lib/xorg/modules/libxaa.so ET_DYN NOW /usr/lib/xorg/modules/libxf1bpp.so ET_DYN NOW /usr/lib/xorg/modules/libxf4bpp.so ET_DYN NOW /usr/lib/xorg/modules/libxf8_16bpp.so ET_DYN NOW /usr/lib/xorg/modules/libxf8_32bpp.so ET_DYN NOW /usr/lib/xorg/modules/libscanpci.so ET_DYN NOW /usr/lib/xorg/modules/libpcidata.so ET_DYN NOW /usr/lib/xorg/modules/extensions/libextmod.so ET_DYN NOW /usr/lib/xorg/modules/extensions/libdbe.so ET_DYN NOW /usr/lib/xorg/modules/extensions/librecord.so ET_DYN NOW /usr/lib/xorg/modules/extensions/libGLcore.so ET_DYN NOW /usr/lib/xorg/modules/extensions/libxtrap.so ET_DYN NOW /usr/lib/xorg/modules/extensions/libdri.so ET_DYN NOW /usr/lib/xorg/modules/fonts/libbitmap.so ET_DYN NOW /usr/lib/xorg/modules/fonts/libfreetype.so ET_DYN NOW /usr/lib/xorg/modules/fonts/libtype1.so ET_DYN NOW /usr/lib/xorg/modules/libafb.so ET_DYN NOW /usr/lib/xorg/modules/libcfb.so ET_DYN NOW /usr/lib/xorg/modules/libcfb16.so ET_DYN NOW /usr/lib/xorg/modules/libcfb32.so ET_DYN NOW /usr/lib/xorg/modules/libfb.so ET_DYN NOW /usr/lib/xorg/modules/libmfb.so ET_DYN NOW /usr/lib/xorg/modules/libshadow.so ET_DYN NOW /usr/lib/xorg/modules/libexa.so ET_DYN NOW /usr/lib/opengl/xorg-x11/extensions/libglx.so ET_DYN LAZY /usr/bin/gtf ET_DYN LAZY /usr/bin/cvt ET_DYN LAZY /usr/bin/ioport ET_DYN LAZY /usr/bin/pcitweak ET_DYN LAZY /usr/bin/scanpci ET_DYN LAZY /usr/bin/xorgcfg ET_DYN LAZY /usr/bin/xorgconfig ET_DYN LAZY /usr/bin/Xorg If xorg-server can be made to respect user defined LDFLAGS/CFLAGS then this problem would probably not be a problem.
I have no clue why it wouldn't respect LDFLAGS. It's a normal autotooled package at this point. AFAIK, any user-specified LDFLAGS should be added to the foo_LDFLAGS specified in the Makefile.am's.
hmm, it would work if I could pass -nonow directly to the gcc link command. But xorg uses libtool, and it eats the flag. It looks like -Wl,-z,nonow is passed on by libtool as -Wl,-z -Wl,nonow but ignored by gcc. <rant>The damn libtool prevents one from linking almost anything.</rant> * sys-devel/libtool Latest version available: 1.5.22 Latest version installed: 1.5.22
I saw shat solar saw, while experimenting before - LDFLAGS goes through ok to executables but not to the shared libraries. I tried adding stuff like foo_la_LDFLAGS into the Makefile.am's, but to no avail. I managed to get it to add the LDFLAGS to the command that built the .la file, but it wouldn't add it to the command that actually built the .so :/ Tried a number of other combinations, but was reduced to guessing so gave it up and focused on removing the mutual dependencies. One thing I didn't try was defining LIBRARY_LDFLAGS which may be worth a go; autotools info seems to imply it'll get passed through libtool to shared libraries.
(In reply to comment #50) > One thing I didn't try was defining LIBRARY_LDFLAGS which may be worth a go; > autotools info seems to imply it'll get passed through libtool to shared > libraries. The documentation more accurately should say ${LIBRARY}_LDFLAGS, which is generally specified in the Makefile.am.
(In reply to comment #49) > It looks like -Wl,-z,nonow is passed on by libtool as -Wl,-z -Wl,nonow but > ignored by gcc. -z,nonow doesn't exist - but we could add it; see bug #134514. I guess libtool is filtering out anything that isn't '-Wl,<something>' (or presumably -Xlinker <something>).
(In reply to comment #49) > hmm, it would work if I could pass -nonow directly to the gcc link command. But > xorg uses libtool, and it eats the flag. > It looks like -Wl,-z,nonow is passed on by libtool as -Wl,-z -Wl,nonow but > ignored by gcc. afaik, the two forms are equivalent and both would result in gcc invoking ld (or collect2 or whatever) with '-z nonow' in the end. the actual problem is, as others pointed it out already that nonow doesn't exist (yet) and ld silently ignores unknown -z options. since passing it to the xorg ebuilds seems a lot smaller exercise than fixing the interdependencies between the xorg modules, i'd prefer this approach for now (no pun intended ;-) and gentoo could/should incorporate the -z nonow patch in binutils until it hits upstream.
OK, with the binutils patch passing nonow works. I am now running "hardened" X server and ati driver. The input drivers I use do not need nonow - I compiled them before I patched binutils and they work fine. --- /usr/portage/eclass/x-modular.eclass~ 2006-05-23 20:05:47.000000000 +0200 +++ /usr/portage/eclass/x-modular.eclass 2006-06-12 15:42:29.000000000 +0200 @@ -172,9 +172,9 @@ x-modular_specs_check() { if [[ ${PN:0:11} = "xorg-server" ]] || [[ -n "${DRIVER}" ]]; then if gcc-specs-now; then - msg="${PN} does not work with hardened gcc specs. Switch to vanilla gcc specs to emerge ${PN}." + msg="${PN} does not work with hardened gcc specs. Appending nonow." eerror "$msg" - die "$msg" + append-ldflags -Wl,-z,nonow fi # (#116698) breaks loading Please, somebody add dependency on the binutils bug 134514
Alright, new proposed patch below. This does mean we'll have to wait for 2.16.94 to be keyworded, though, unless someone is kind enough to include a back-ported patch... diff -u -b -B -r1.60 x-modular.eclass --- x-modular.eclass 23 May 2006 17:50:30 -0000 1.60 +++ x-modular.eclass 18 Jun 2006 16:31:09 -0000 @@ -157,7 +157,8 @@ fi DEPEND="${DEPEND} - >=dev-util/pkgconfig-0.18" + >=dev-util/pkgconfig-0.18 + >=sys-devel/binutils-2.16.94" if [[ "${PN/util-macros}" = "${PN}" ]]; then DEPEND="${DEPEND} @@ -172,9 +173,9 @@ x-modular_specs_check() { if [[ ${PN:0:11} = "xorg-server" ]] || [[ -n "${DRIVER}" ]]; then if gcc-specs-now; then - msg="${PN} does not work with hardened gcc specs. Switch to vanilla gcc specs to emerge ${PN}." - eerror "$msg" - die "$msg" + msg="${PN} does not work with hardened gcc specs. Enforcing lazy bindings for ${PN}." + einfo "$msg" + append-ldflags -Wl,-z,lazy fi # (#116698) breaks loading
*** Bug 155575 has been marked as a duplicate of this bug. ***
Rather than wait for binutils to get patched (!!!) or throw away hardened gcc entirely, I have been using the following sets of patches in my overlay. They are fairly minimal, just to include the requisite flags and patch ltmain.sh so that it doesn't ignore -nonow. My gentoo ebuild fu is pretty weak, but I reintregate these patches against xorg-server every time there's an update and it usually works without issues: The following saved as files/dont-ignore-vitally-important-nonow-flag-patch.diff --- ltmain.sh 2006-02-11 19:50:49.000000000 -0500 +++ ltmain.sh.patch 2006-07-09 16:12:49.000000000 -0400 @@ -1788,6 +1788,14 @@ continue ;; + # vitally important flag + -nonow) + compiler_flags="$compiler_flags $arg" + ;; + # Some other compiler flag. -* | +*) # Unknown arguments in both finalize_command and compile_command need And something like the following applied the the xorg-server-*.*.*-ebuild: --- orig/xorg-server-1.1.1-r4.ebuild 2007-02-12 16:25:17.000000000 -0500 +++ new/xorg-server-1.1.1-r4.ebuild 2007-02-12 16:25:52.000000000 -0500 @@ -281,7 +281,8 @@ ${FILESDIR}/${PV}-fix_acpi_tokenize.patch ${FILESDIR}/${PV}-fixdualhead.patch ${FILESDIR}/${PV}-sparc-includes.patch - ${FILESDIR}/${PV}-dbe-render.diff" + ${FILESDIR}/${PV}-dbe-render.diff + ${FILESDIR}/dont-ignore-vitally-important-nonow-flag-patch.diff" # Patches required for compiz to work with AIGLX, # but they slow EXA down (bug #147841). @@ -332,6 +333,8 @@ --enable-install-setuid --with-fontdir=/usr/share/fonts ${conf_opts}" + LDFLAGS="${LDFLAGS} -nonow" + CFLAGS="${CFLAGS} -nonow" local diemsg="You must build xorg-server and mesa with the same nptl USE setting." if built_with_use media-libs/mesa nptl; then @@ -368,6 +371,8 @@ fi fi x-modular_reconf_source + # Make sure libtool doesn't strip out really useful flags like nonow + ( pushd ${S} ; patch -p0 < ${FILESDIR}/dont-ignore-vitally-important-nonow-flag-patch.diff ; popd ) } src_install() {
Er, the "-z lazy" binutils patch has been in for a while, as has the change to x-modular.eclass. I guess we should have closed this a while back. Also, if you're interested, I maintain an overlay which allows you to have X built -z,now throughout, the downside is that loading modules has to be done manually in xorg.conf. See http://overlays.gentoo.org/dev/kevquinn
Maybe my system's configuration is screwed up somehow, but whenever I emerge xorg-server (up to 1.1.1-r4), it always fails to start up (due to various undefined symbols) unless I force libtool to pass through my "-nonow" flags, to allow it to do the lazy loading. I traced it down to the fact that my hardened gcc spec ALWAYS forces "-now" through, which seems to supercede "-lazy" as passed to ld (maybe it depends on the order in which now vs lazy get passed in on the command line? who knows). The only way I could stop that was with -nonow, which required the ltmain patch. I use the hardened/x86/2.6 profile and gcc 3.3.6.
I'm wondering how you are hitting this. Under current stable I get the following without any mods. hardened ~ # qlist ^xorg-server ^x11-drivers | scanelf -f - -b | grep NOW ET_DYN NOW /usr/bin/synclient ET_DYN NOW /usr/bin/syndaemon
Ah; it's your binutils that's rather old (that version has even been punted from the portage tree). Your gcc is old as well, fwiw. Upgrade to binutils-2.16.1-r3. The reason it's not working for you, is that unrecognised '-z' options are silently ignored by ld, for compatibility with Solaris.
