Re: glibc - capaibility control mechanism
On Fri, Apr 01, 2005 at 10:40:51PM +0200, Bastian Blank wrote:
> On Fri, Apr 01, 2005 at 03:29:06PM -0500, Daniel Jacobowitz wrote:
> > On Fri, Apr 01, 2005 at 08:57:56PM +0200, Bastian Blank wrote:
> > > On Fri, Apr 01, 2005 at 01:27:26PM -0500, Daniel Jacobowitz wrote:
> > > > On Fri, Apr 01, 2005 at 07:11:04PM +0200, Bastian Blank wrote:
> > > > > So? Than please show me how to ask it to enable sse optimized libs and
> > > > > disable tls.
> > > > Debian doesn't offer a way to do this for libc, because we only ship
> > > > SSE optimized libraries which use TLS. If we did ship them, then
> > > > LD_ASSUME_KERNEL=2.4 would work fine. That disables TLS, but not
> > > > hardware capabilities.
> > > This does not answer the question.
> > What does it not answer? Your answer is:
> > export LD_ASSUME_KERNEL=2.4
>
> This is a sideeffect; I asked for disabling tls, not forceing the ld.so
> to remove it because the assumed kernel does not support it. As it is
> defined as a hwcap entry, either the default mask machanism is able to
> do that or I have to assume that it does not work.
TLS isn't a hwcap. It's supported in a similar fashion, that's all.
In practice, it is available iff your kernel is new enough, so tying it
to the kernel version makes sense.
> > it will not disable SSE.
>
> SSE is masked off by default, I asked for how to enable it.
Build a glibc which considers it a relevant capability for library
selection. It's just a matter of setting the bit in HWCAP_IMPORTANT. I
don't think it's a bug that glibc does not default to searching all
capabilities that it knows about. That would be horrendously slow.
--
Daniel Jacobowitz
CodeSourcery, LLC
Reply to: