tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: How to handle "-march=native"?

Takahiro Kambe <> writes:

> Today, I tried to run squid-3.4.1nb1 package on NetBSD/amd64
> 6.1_STABLE and I met a troulbe, squid core dump soon with SIGILL.
> Finally, I found some comments about --(disable/enable)-arch-native
> option in squid's configure script.

I'm not sure I follow what you are saying 100%.

> # Clang 3.2 on some CPUs requires -march-native to detect correctly.

I don't understand this statement

> # GCC 4.3+ can also produce faster executables when its used.

Sure, but then they aren't portable.

> # But building inside a virtual machine environment has been found to
> # cause random Illegal Instruction errors due to mis-detection of CPU.
> Yes, I built my package in VMware Fusion.

So perhaps Fusion is buggy.

It seems there are multiple things going on:

  1) there may be some bugs about cpu detection, particulaly in various
  vm environments, or about the mapping of flags to instructions.

  2) upstream code is trying to build a binary that is optimized for the
  CPU it is built on, which is basically the wrong thing to do in the
  general case

You may be running into problem (1), which is just bugs to fix.  But
problem 2 is (from the pkgsrc viewpoint) a bug in the upstream code.
In my opinion, code should be produced that conforms to the system ABI,
which means not using cpu-specific instructions.

> So, how can I avoid this situation?
> 1. Avoid "-march=native" with adding --disable-arch-native to

I think this is the right approach.  Also file a bug upstream to make
this the default.

> 2. Add a PKG_OPTIONS to control addition of --disable-arch-native to

If anything the option should be for building non-portable code.

> 3. Some way to detect machine is running under VM?

This is going in the wrong direction; it's not really about VM, but
about "reasoning based on reading cpuflags in a previous invocation will
get the wrong answer".  Moving physical disks across physical CPU boxes
has the same issue (and is part of a reasonable failure recovery plan).

> For pkgsrc-2013Q4, 1. is handy to solve this problem, but what do you
> think it better way?

I think your option 1 is the right approach.

Longer term, there is the notion of resurrecting(?) and generalizing (to
clang and other compilers) devel/cpuflags to produce code specific for a
processor type.  But the most important thing is to keep that notion
From creeping in when it has not been specifically requested.

Attachment: pgpatGiZP3uA5.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index