There are really two problems to consider:

problem 1:

You can see from the following log that without -arch armv6, that 
/iPhoneOS4.2.sdk/usr/include/machine/limits.h is trying to pull in 
"i386/limits.h". In the MacOSX sdk, this header is at 
"/usr/include/i386/limits.h" However, the iphone sdk does not have an i386 
entry. it only has an arm entry.

Without the -arch flag, the g++ -E defaults to i386 which doesn't exist in the 
iphone sdk. I would guess that the same thing happens when building ppc on 
i386, but because the MacOSX sdk happens to have the i386 version, it still 
works by accident. Supplying "-arch armv6" in CPPFLAGS fixes the problem and 
produces the expat lib for armv6 (verified with lipo). The question 
is....SHOULD CPPFLAGS have the -arch flag or is the expat configure script 
wrong. Joshua says that expat is the problem.

I need clear guidance on where to go on this point. Should macports be patched 
to add the missing flags to CPPFLAGS or should the expat folks be approached 
about corrections to their configure script.



log:


configure:4976: checking how to run the C++ preprocessor
configure:5007: 
/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/llvm-g++-4.2 -E 
-I/iopt/include -isysroot 
/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk 
conftest.cc
In file included from 
/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk/usr/include/limits.h:64,
                 from 
/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin10/4.2.1/include/limits.h:15,
                 from 
/Developer/Platforms/iPhoneOS.platform/Developer/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin10/4.2.1/include/limits.h:15,
                 from conftest.cc:24:
/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk/usr/include/machine/limits.h:8:25:
 error: i386/limits.h: No such file or directory


problem 2:


When you build universal without using muniversal, the configure script is 
asked to compile with two or more arches. This causes gcc -E to fail. I suppose 
the answer here is that the portfile should be switched to use muniversal.  It 
seems to me that configure scripts are inherently designed to accept one 
architecture at a time....which is what muniveral does.


However, I'd like guidance on this point. Am I correct or are there some 
details I'm not seeing and the port should work as is.


NOTE: I'm guessing that the port works for ppc/intel because CPPFLAGS doesn't 
contain the -arch entries.

comments?

On Feb 2, 2011, at 11:44 PM, Ryan Schmidt wrote:

> On Feb 2, 2011, at 19:49, James Gregurich wrote:
> 
>> I"m not sure what to do about this one. The expat port does not use 
>> muniversal to do a universal build. The configure script fails when it 
>> attempts to invoke the preprocessor. Is the correct answer to switch the 
>> port to muniversal or is there another flaw for which I should be looking? I 
>> suppose this is happening because I modified the system to put the arch 
>> flags in CPPFLAGS. However, if you don't supply an arch flag of some kind 
>> when building ppc on i386, it seems that should be incorrect behavior even 
>> if it happens to work. It definitely doesn't work without the -arch flag 
>> when building armv6 on x86_64. Can I get some guidance on what this system 
>> SHOULD be doing?
>> 
>> 
>> 
>> 
>> 
>> log:
>> 
>> 
>> configure:4028: 
>> /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/llvm-gcc-4.2 -E 
>> -traditional-cpp -I/iopt/include -isysroot 
>> /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk -arch 
>> armv6 -arch armv7 conftest.c
>> llvm-gcc-4.2: -E, -S, -save-temps and -M options are not allowed with 
>> multiple -arch flags
> 
> 
> The error message is correct... 
> 
> Per the previous thread, I'm not aware of any existing problems with the 
> expat port on any Mac OS X architectures, so I'm not sure why you're seeing a 
> lack of -arch flags now, though I have not attempted to evaluate the MacPorts 
> base changes you've made.
> 
> 
> 

_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Reply via email to