ok. I will continue running tests on what I have to see what works and what doesn't work. I have the thing working for 3 different ports with no unreasonable modifications to the port files. There is no point to starting over with a new strategy if this one is working....particularly one that would mean much more complex port files.
The key is running the configure scripts through muniversal and setting the the -host option on the configure script. These projects appear to be designed to cross-compile you just have to pass the right options in. muniversal builds one architecture at a time...which is exactly what is needed for the configure scripts to work right on cross-compiling. On Feb 3, 2011, at 6:50 PM, Toby Peterson wrote: > On Feb 3, 2011, at 6:29 PM, James Gregurich wrote: > >> I've been attempting to explain that I think that doing universal builds >> with configure scripts (without muniversal) works on standard macports by >> accident. It is actually broken, but works just because the MacOSX sdk >> provides i386 headers and because CPPFLAGS didn't contain the -arch flag. > > It's no accident. When necessary, ports are tweaked to build universal > despite the deficiencies of configure scripts. You'll find numerous examples > of this throughout the ports tree. > >> I'm now trying a case where the accident can't happen because the iOS sdk >> doesn't have the i386 headers and I have to use the -arch flag with the >> preprocessor.....so, the bug is being exposed for the first time. > > It's not a bug. You can't run configure scripts with multiple arch flags, > it's really as simple as that. If you're trying to compile against an SDK, > your best bet is to just run the configure script against the native SDK > (since it's running on the native machine, as configure scripts are designed > to do), then tweak the configure outputs as necessary. > >> BTW: I could be wrong about this...I'll be the first to admit that my >> knowledge of this codebase is limited, and I'm therefore naive about it. I'm >> figuring it out in pieces as I go along, but learning a large batch of >> scripts in a alien language takes time. I'm just stating my theory that >> I've derived from working through the problems and going through the code. >> So, feel free to tell me I'm full of it. >> >> Also, the whole purpose of my investing weeks of engineering time into this >> project is to make iOS cross compiling a supported configuration. > > Here's what I would suggest, as far as actual modifications to base go: > > (1) Ensure that ./configure is always run natively. That is, use the native > SDK and don't pass -arch flags. This is really the only way to ensure we can > actually _run_ configure when cross-compiling. > > (2) Add functionality for automatically performing replacements on the files > generated by configure. Usually this just involves changing some #ifdefs. > Using examples from the c-ares port, I'd envision something like this: > > platform x86_64 { > config_define ${worksrcpath}/ares_build.h CARES_SIZEOF_LONG 8 > config_define ${worksrcpath}/ares_config.h SIZEOF_LONG 8 > config_define ${worksrcpath}/ares_config.h SIZEOF_SIZE_T 8 > config_define ${worksrcpath}/ares_config.h SIZEOF_TIME_T 8 > } > > platform i386 { > config_define ${worksrcpath}/ares_build.h CARES_SIZEOF_LONG 4 > config_define ${worksrcpath}/ares_config.h SIZEOF_LONG 4 > config_define ${worksrcpath}/ares_config.h SIZEOF_SIZE_T 4 > config_define ${worksrcpath}/ares_config.h SIZEOF_TIME_T 4 > } > > platform armv6 { > ... > } > > Then it'd automatically perform replacements like changing: > > #define SIZEOF_LONG 8 > > to: > > #if defined(__x86_64__) > #define SIZEOF_LONG 8 > #elif defined(__i386__) > #define SIZEOF_LONG 4 > #elif defined(__armv6__) > ... > #else > #error unsupported platform > #endif > > (3) Document this, prominently warning port maintainers to ensure configure > outputs are correct. > > - Toby _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev