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

Reply via email to