[Nix-dev] Re: libgmp impurity

Isaac Dupree ml at isaac.cedarswampstudios.org
Mon Jun 29 21:21:24 CEST 2009


Marc Weber wrote:
> On Mon, Jun 29, 2009 at 06:58:10PM +0200, Peter Simons wrote:
>> The gmp library in stdenv-updates uses plain GNU config.guess now. This
>> should remedy overly aggressive choice of optimizer flags. 
>>
>> My understanding is that there is no trivial solution to the underlying
>> problem, though. Configure scripts usually guess a lot, and that's
>> [..]
> 
> Maybe we should talk about solutions even if we can't implement them at
> the moment?
> 
> a) patch the config.guess script.
>      can be easy but won't catch everything
> 
> b) patch the stuff config.guess is using
>      requires patching gcc and assembler because the CPUID processor
>      instruction can't be faked. Thus gcc and the assemblers must be
>      taught to rewrite this instruction by a set of instruction returning a
>      constsant but similar string.
> 
> c) cross compile everything from x86 to x86 or such.
>      I guess too much work. cross compiling can cause a lot of problem
>      because the majority of packages isn't cross compiled often except the
>      most basic ones (?)
> 
> Can you think about other solutions?

more powerful sandboxing. Do User-Mode-Linux or QEMU or anything allow 
you to simulate some sort of "standard" system?  Albeit even with 
QEMU-acceleration or KVM, it'd probably be slower.  If you can patch the 
kernel, is there a way to trap all uses of the CPUID instruction?  On 
the other direction of things, maybe you could just search somehow 
(sources? binaries?) to detect what packages packages use CPUID 
instruction, with the intention to patch any that you find :-P

hmm how coincidental, when I go to look up qemu the first thing in the 
recent changelog mentions something that's somehow related,
http://www.qemu.org/changelog.html
"kvm: trim unsupported cpu features from cpuid"

but seriously if QEMU can be made fast enough for common purposes 
(compiling for the same architecture), it somehow seems like the "right" 
solution to me, even could support a sort of "cross-compiling" that's 
not cross-compile-toolchain based but emulation based. hmm.

-Isaac



More information about the nix-dev mailing list