glibc/xorg and CFLAGS

[sofar]

On Sun, 5 Feb 2006 19:59:30 +0100, Jan Eidtmann <cmak at lunar-linux.org> wrote:
> hi all,
> 
> we unset CFLAGS in glibc but i found that it will work just fine
> without unsetting it.

this may be relatively new to glibc. In the old days you could seriously harm
your silicon with it, hence it is in there.

> my (pretty aggressive?) optimizations:
> 
> PLATFORM=x86
> BUILD=i686-pc-linux-gnu
> CPU=Pentium4
> BOPT=Fastest
> XTRA=( MMX SSE SSE2 )
> SPD=(  )
> FPM=SSE
> CC_OPTS=( ccpipe cxxpipe )
> LDF=( Strip Optimize Combreloc )
> ADDON=( CCache )
> MAKES=2
> STACK=

that\'s indeed pretty unsafe !

> i built everything (including glibc) with this just fine and have no
> problems. my question: (i know it must be there for a reason but) why
> do we unset CFLAGS in glibc?

historical. And we want people to have working machines. always.

> there is however one module that doesnt like my optimizations: XOrg
> (6.8.2). pretty unstable! it crashes sometimes by just opening apps or
> clicking somewhere inside some windows (nautilus). so i choosed save
> optimizations for XOrg and i have no more such crashes.
> 
> so...waht i found is (for my box)...glibc doesnt need unsetting CFLAGS,
> but we do that, and XOrg does need unsetting too aggressive flags, but
> we dont do that.
> 
> also...glibc isnt PSAFE here. since we have HT, there are different SMP
> systems (real- and \"fake\"(HT)-SMP). with HT glibc is not PSAFE!!!
> it fails without setting \"PSAFE=no\" everytime! *pain*

I\'ve never had problems building glibc on SMT/SMP systems - I assume that
your optimizations are the problem - they cause your gcc/make/binutils to
be instable. With sa*F*e optimizations there are no problems building
glibc parallel.

> i think we shouldnt unset CFLAGS in glibc but instead we should make
> sure that everything will build fine IF the user choosed to enable
> \"save optimizations\" (what are save optimizations if they aint save
> for glibc? not really save..). and IF the user choosed advanced
> optimizations...use it for ALL modules.

sa_f_e (not save). I don\'t appreciate this type of behaviour. People who want
to build glibc with anything other than the default lunar build, should make
a zlocal copy of glibc and experiment there themselves.

This is the *recommended* way too - It keeps the default glibc module safe
for everyone.

Auke
> 
> cmak
> _______________________________________________
> Lunar mailing list
> Lunar at lunar-linux.org
> http://foo-projects.org/mailman/listinfo/lunar