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
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
