multiple arch flags won't work with -E

James Gregurich bayoubengal at mac.com
Thu Feb 3 11:14:08 PST 2011


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.
> 
> 
> 



More information about the macports-dev mailing list