Frank Sweetser said:
On Thu, Mar 14, 2002 at 01:06:54PM -0500, Aaron Haviland wrote:
it's not dpkg that has the problem. debian's gcc is patched so it defaults to i386 if the arch is any ix86, unless specified otherwise. (at least, that's what i'm making of this patch...)
Actually, that's standard gcc behavior, which redhat has as well.
Well, I seem to remember seeing something... somewhere... to some effect that I'm not entirely sure of... and I can't find it anymore... (sadly, this is how my mind usually works. broken and partial memories)
The difference here is that (if I understand things correctly) if you want to compile a package for iX86 where X != 3, then you have to download and install a package which *changes the default for every compile on the whole system*. As Charles mentioned, the way that RPM does it is by macros. You tell RPM "I want to build this particular packate for i586". It then goes off, and via the correct configure macros, adds the flags to gcc (probably the same flags that the debian package makes the system wide default) to compile *only* that package for i586.
So if I'm a random user who wants to compile a package on a i686 platform to be run on a 386, and the sysadmin has installed the i686 package, that means that I have to do *extra* work to get *standard* behavior!
Someone please tell me if I'm wrong, because that seems like a pretty hackish way to do things.
pentium-builder is a wrapper for gcc/g++ that iff DEBIAN_BUILDARCH is set, runs gcc/g++ with -march=$DEBIAN_BUILDARCH -mcpu=$DEBIAN_BUILDARCH, otherwise it just runs gcc/g++. it's transparant to whatever called gcc. you don't have to specify DEBIAN_BUILDARCH=i386 to revert to default. the name "pentium-builder" doesn't mean it's specifically for pentium. as for it being hackish... from the pentium-builder README: Why did I do it this way? There are alternatives after all. I could just set CFLAGS or GCC, or I could place the shell script wrappers in a separate directory and set the PATH to point to them when you want to build pentium optimized stuff. The problem with all these ideas is that I can imagine packages that would circumvent them. It's a hack, but it works. I welcome a cleaner solution. ... on another note, i've compiled povray for k6 and pentium and timed them, aka "time ./povray" running on a k6 machine, the k6 optimised one consistently runs 1 second faster overall (33 seconds total) but the pentium optimised one has a .1 second lower sys time. which is better? (i don't have the output anymore. just thought i'd ask while on the topic of optimising) (yes, i read the time manpage. just doesn't seem to sink in through this thick skull :) ) -- Aaron Haviland orion [at] tribble [dot] dyndns [dot] org orion [at] parsed [dot] net A man on a slushy bender can do some crazy things.