multiple arch flags won't work with -E

[James Gregurich]

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