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
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
