On 04 Mar 2016 16:11, Sean Byland wrote: > I’m trying to help users get autotools-based projects to compile in our > somewhat unique environment. It’s fairly common for users to want to compile > on a Intel ivybridge system (node) with Intel broadwell-specific (a superset > of CPU instructions) performance optimization to run elsewhere (a compute > node). With default options configure won’t handle this scenario because the > build system can’t execute the Broadwell-specific x86 instructions. In > varying degrees of success configure will work by: > > 1. Setting --build to a slightly different canonical name to the --build > name, indicating to configure that it should do a cross-compile > > 2. Generating a config.cache on the Ivybridge compute node, which shares > the majority of the file system with the Sandybridge system and can > successfully execute everything. Then point configure on the sandybridge > system at the cache generated while using the Ivybridge CPU. > > 3. Setup configure to use a test “launcher,” so configure tests will be > launched on the Ivybridge system. > > > I like option one because it seems to follow a use-case that the autotools > were designed for but I seem to get regular failures because (for example) > the packager will use AC_TRY_RUN without defining a sensible > “[action-if-cross-compiling]”. I like that option three allows configure’s > main code path to function as intended but strongly dislike that it requires > use of an Broadwell CPU that won’t always be available for every build and > would probably require hacking and/or a configure user to perform packager > actions. Option two get’s test results from the desired execution > environment, allows configure to run really fast, and only requires minimal > use of the Ivybridge system. Is using the cache in this manner generally a > bad idea? > > > I’d also appreciate any general feedback, in the past my lack of autotools > knowledge has led me to “fight” things and so I’d like to avoid deviating too > far from what these tools were designed for.
seems like the only thing you need to do is properly set CFLAGS/CXXFLAGS.
if you want a build that'll work on all x86 systems, then use something
like:
./configure CFLAGS='-O2 -march=x86-64 ...' CXXFLAGS='-O2 -march=x86-64
...'
no need to mess with --build or --host, or config.cache. i'm assuming
the configure script doesn't attempt to detect CPU extensions via some
RUN tests ... if it does, then the script should be fixed to do define
probing and/or add a configure flag to control them (like --disable-mmx).
-mike
signature.asc
Description: Digital signature
_______________________________________________ Autoconf mailing list [email protected] https://lists.gnu.org/mailman/listinfo/autoconf
