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
_______________________________________________
nix-dev mailing list
[email protected]
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

Reply via email to