http://bugs.freedesktop.org/show_bug.cgi?id=7459
--- Comment #22 from Hugo Mildenberger <[EMAIL PROTECTED]> 2008-11-25 01:46:18 PST --- (In reply to comment #21) > I'd rather not add all these options. > For the first patch, if -DGLX_X86_READONLY_TEXT is needed when using TLS and > PIC, then we should just enable that instead of asking the user/packager to > make that distinction. The problem is not PIC and TLS, but PIC & TLS & PAX. PIC & TLS without PAX do run fine, even though the Gentoo build system generates QA-warnings. On a non-PAX x86 system, GLX_X86_READONLY_TEXT could cause a slight performance drawback, hence the switch. > For the second patch, if the point of the parameters is just for debugging, > then you can already do that by overriding ASM_FLAGS at build time. In the scenario I described above, it turned out that it was USE_SSE_ASM, which led to an invalid function pointer being dereferenced. Recognizing that it was provoked by an assembly coded SSE module was a lengthy process, because I needed to interfere with Gentoo's build framework, whereas directly compiling and installing git sources easily leads to a inconsistent system due to stale libaries and configuration files. >I really prefer the single --enable / disable-asm parameter. I would agree with you, however, this bug was opened more than a year ago. >Some of it is just superfluous, though. If you're building on x86_64 >and use `--enable-asm --disable-x86-64-asm', what are you left with? You could make a similar point for sparc, as there is currently no support for enabling or disabling sparc modules written in assembly from configure at all. I included x86_64 for consistency, because I did not want to exclude the case, that someone would come up with another module, freshly written in assembly for this platform. >But I don't really feel that strongly about it if people really want >to fine tune the assembly usage on x86. My intention was not fine tuning (btw: enabling assembly modules, there is no much performance difference within my environment), but factoring out what was going wrong. This was straighforward after having applied the proposed patches locally. Using them, everyone could control these obviously unstable features via USE flags (or similar mechanism) and draw the appropriate conclusions within his particular environment very quickly. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
