On Feb 4, 2011, at 7:43 PM, Ryan Schmidt wrote:
> On Feb 3, 2011, at 20:50, Toby Peterson wrote:
>
>> 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}/
On Feb 3, 2011, at 20:50, Toby Peterson wrote:
> 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 ${worksrcp
Am 04.02.2011 um 04:18 schrieb Joshua Root:
> On 2011-2-4 14:07 , James Gregurich wrote:
>> 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 i
yes. I am aware of that one. I've seen in used in terms of running tests in
icu. I had to switch it off for the cross-compile of icu. when configured with
--host, icu requires a native build to be specified and it runs the tests as
part of the native build.
On Feb 3, 2011, at 7:18 PM, Joshua
On 2011-2-4 14:07 , James Gregurich wrote:
> 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
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 workingparticularly one that wo
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 head
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.
I
Actually, I have it working.
I am able to successfully build non-universal armv6 and universal armv6/armv7
for icu, bzip2 and expat.
The only change I made to the expat portfile was to set the PortGroup to
muniversal.
For bzip2, since it bypasses the normal configure, I added a few lines
Then putting the -arch flags in CPPFLAGS simply can't work and
muniversal with merger_arch_compiler set may indeed be your only option
short of modifying the SDK. As Toby said, this isn't a change we would
want to put in the main ports tree as muniversal adds a lot of
complexity and fragility.
On
yep. armv6 armv7
On Feb 3, 2011, at 5:10 PM, Joshua Root wrote:
> On 2011-2-4 06:54 , James Gregurich wrote:
>> I think that I'll change the expat port to use muniversal.
>>
>>
>>
>> Is this reasonable?
>
> What does muniversal have to do with this? Are you trying to do a
> universal cross
On Feb 3, 2011, at 11:54 AM, James Gregurich wrote:
> I think that I'll change the expat port to use muniversal.
>
>
>
> Is this reasonable?
Not really a reasonable change for the mainline expat, since it's not necessary
for supported configurations (i386, x86_64). If you do make the change
On 2011-2-4 06:57 , James Gregurich wrote:
> excuse me. I should quoted the following instead:
>
>
>
> |CFLAGS|
> Extra flags to give to the C compiler.
> |CXXFLAGS|
> Extra flags to give to the C++ compiler.
>
> |CPPFLAGS|
> Extra flags to give to the C preprocessor and programs
On 2011-2-4 06:54 , James Gregurich wrote:
> I think that I'll change the expat port to use muniversal.
>
>
>
> Is this reasonable?
What does muniversal have to do with this? Are you trying to do a
universal cross compile?
- Josh
___
macports-dev ma
excuse me. I should quoted the following instead:
CFLAGS
Extra flags to give to the C compiler.
CXXFLAGS
Extra flags to give to the C++ compiler.
CPPFLAGS
Extra flags to give to the C preprocessor and programs that use it (the C and
Fortran compilers).
On Feb 3, 2011, at 11:54 AM, James
Where else would you put them?
On Feb 3, 2011, at 11:39 AM, Daniel J. Luke wrote:
> On Feb 3, 2011, at 2:35 PM, James Gregurich wrote:
>>
>> ok. ignoring the practical perspective, what is conceptually correct? What
>> is the design purpose of CPPFLAGS and CXXFLAGS In the configure script
>>
CC
Program for compiling C programs; default ‘cc’.
CXX
Program for compiling C++ programs; default ‘g++’.
CPP
Program for running the C preprocessor, with results to standard output;
default ‘$(CC) -E’.
Based on this statement, it seems to me that CPP needs to have the arch flag.
However,
I found the following:
http://stackoverflow.com/questions/495598/difference-between-cppflags-and-cxxflags-in-gnu-make
http://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html#Implicit-Variables
On Feb 3, 2011, at 11:35 AM, James Gregurich wrote:
>
> ok. ignoring the practical
On Feb 3, 2011, at 2:35 PM, James Gregurich wrote:
>
> ok. ignoring the practical perspective, what is conceptually correct? What is
> the design purpose of CPPFLAGS and CXXFLAGS In the configure script system?
AFAIK, -arch isn't a cpp option (but an [apple modified] gcc one), so it would
be in
ok. ignoring the practical perspective, what is conceptually correct? What is
the design purpose of CPPFLAGS and CXXFLAGS In the configure script system?
On Feb 3, 2011, at 11:24 AM, Daniel J. Luke wrote:
> On Feb 3, 2011, at 2:14 PM, James Gregurich wrote:
>>
>> I need clear guidance on wher
There is such a variable. In the .conf file you specify:
os_target_platform darwin.iPhoneOS.iphone
os_target_platform darwin.iPhoneSimulator.iphone
os_target_platform darwin.MacOSX.pc
along with
os_target_version 4.2
os_target_version 10.6
There are variables that allow you access this info
On Feb 3, 2011, at 2:14 PM, James Gregurich wrote:
>
> 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.
I don't have an easy answer but...
On Feb 3, 2011, at 11:05 AM, Toby Peterson wrote:
> On Feb 2, 2011, at 5:49 PM, 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 t
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
On Feb 2, 2011, at 5:49 PM, 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
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 t
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 suppo
27 matches
Mail list logo
