Takahiro Kambe <taca%back-street.net@localhost> 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 > CONFIGURE_ARGS. 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 > CONFIGURE_ARGS. 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