|
|
X.Org 7.1 to enter stable for amd64 and x86
The Gentoo X11 team plans to stabilize X.Org 7.1 for x86 and amd64 on or after Thursday, 12 October. The lack of binary driver support previously held up this release, but Nvidia and ATI released compatible versions that are now marked stable on both architectures.
This release features the addition of accelerated indirect GLX (AIGLX), which allows for eye candy such as the Compiz window/compositing manager, as well as running 3D accelerated display walls with Xdmx. X.Org 7.1 also integrates the kdrive (TinyX) servers for embedded systems into the xorg-server package with the kdrive USE flag. The kdrive integration additionally provides Xephyr, an enhanced Xnest-like client. Numerous video drivers also received significant updates.
Safe CFLAGS
Being able to tune CFLAGS is part of the user control and extreme configurability that are hallmarks of the Gentoo experience. Being in control brings both benefits and problems. CFLAGS tuning is not an exception.
Warning: Using anything beyond -O2 -fomit-frame-pointer -march/-mcpu/-mtune in CFLAGS or CXXFLAGS (and -mieee, -mabi etc. on selected archs that tell you to do this), and using anything at all in LDFLAGS or ASFLAGS, is usually not worth the trouble for most users. There's usually very little benefit, if any, high risks, and large amounts of time spent on frustrating tuning that could be enjoyed doing far more interesting things.
The recent upgrade to GCC 4.1 for stable x86 and amd64 users changed the CFLAGS landscape. Users that spent some time tuning their CFLAGS with GCC 3.4 might find that an upgrade to GCC 4.1 leaves them with an unstable system.
Examples of this are:
* nss_ldap stopped working with -ffast-math (-ffast-math is often misused and must be considered a dangerous flag)
* -fvisibility-inlines-hidden still breaks some code
* -ftree-loop-linear now breaks in GCC 4.1 (at least with mesa)
* -ftree-vectorize is known to be broken in GCC 4.1 (at least for x86 and ppc, there are fewer problems reported by amd64 users, but no guarantees)
* -fforce-addr and -fweb break regularly on x86 with video libraries or graphic processing apps which use hand-optimized assembly (-fweb may be safe on amd64 but like above no guarantees)
There are known-to-be-broken flags for all GCC versions that you want to check for too:
* -fvisibility=hidden
* -frename-registers (may be safe on amd64, at your own risks)
* -ftracer
* -D_FILE_OFFSET_BITS=64
* -msse, -mmmx, and -m3dnow (no need for them on amd64, they are wrapped up by -march=k8/nocona/... and safely used there)
* -W
* -mfpmath=sse,387
* -malign-double
Users with unsupported CFLAGS might want to return to safe CFLAGS (see warning above) if recent updates caused them stability problems. On the other hand, more adventurous users might want to experiment with CFLAGS that didn't work properly with GCC 3.4.6... As always, the user is in control (and the gun pointed to their feet is in his/her hand).
Final notes:
* The GCC man page contains warnings for some unsafe optimization options. You should read it carefully when you experiment with CFLAGS or upgrade GCC on a CFLAGS-customized Gentoo.
* Some options that are unsafe in the system-wide CFLAGS might be added automatically in some ebuilds if the developer deems them safe (by redefining CFLAGS or using append-flags from the flag-o-matic eclass). For example -ffast-math is added by the xmame/xmess ebuilds on most architectures even though you should not put it in your CFLAGS.
* You might get an idea of the stability issues of a specific optimization option by running: find /usr/portage -name '*.ebuild' | xargs grep -- '-your-risky-optimization-option'. It takes quite some time, but might be enlightening: look for the 'filter-flags'. |
|
IP卡
狗仔卡
发表于 2006-10-12 11:12:24
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
发表于 2006-10-12 11:42:30
楼主