[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Checking for SSE/MMX support
It occurred to me that Hugo Rivera wrote in
> # The line below it's what I'm talking about
> cpuinfof = os.popen('sysctl -n hw.instruction_sse')
> That's the freebsd part that came by default in the
> SConstruct file, I was trying to create a similar
> section for netbsd, so, what am I doing wrong?
The concept of determining whether to include SSE/MMX or not *at build time*
is wrong altogether. It assumes that the machine used for *building* is
the same machine as the one used at *runtime*. This is not the case per se.
In fact, in an ideal world, the build host can be of a completely different
architecture, not even capable of running the binaries it just generated. This
is called cross-compilation, and it's considered a Good Thing (TM) within
NetBSD. It allows me to build the NetBSD system for my old NeXTstation (which
is way too slow for this) on my spiffy fast AMD64. Unfortunately, because of
autoconf (Which makes the same assumption about "host == target", and compiles
small testprograms to be executed on the build host. Therefore, the build
host needs to be able to execute target binaries, which is not the case
in the amd64 vs. m68k example), I can't easily compile binary packages for my
old slab on my AMD64. However, I'm still able to compile software for my
Pentium laptop, as they're running the same architecture of NetBSD.
Most binary packages are compiled this way, on speedy fast modern machines, so
people with older hardware can just use the binary packages instead of building
themselves. However, this would *break* the minute a package starts doing
tests like the one you described above.
On my spiffy fast AMD64, it would detect SSE and MMX, compile my package
accordingly, and it would no longer work on my Pentium laptop. In fact, since
it's being probed automatically, it's even *impossible* to build it in such
a way that I could run it on my pentium, unless I compiled it on there - which
is not what I want.
So, therefore, there are two ways how to deal with this:
1) Do the detection at runtime. However, this probably means rather serious
modifications to the package, so it may not be a valid option.
2) Don't use detection, but make the usage of SSE/MMX optional. We have a
mechanism for this. It would allow people to use SSE or MMX, by means of
specifying PKG_OPTIONS.dangerdeep+="sse" or PKG_OPTIONS.dangerdeep+="mmx"
in /etc/mk.conf, but it would *default* to building a package which would
run on *all* systems - not just the system which happens to have the
same capabilities than the build host.
Hope this helps to clear things up,
 e.g. a world without autoconf, or at the very least a world without crummy
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
pkgsrc-wip-discuss mailing list
Main Index |
Thread Index |