mingw-cross-env-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

OSX GCC Versions (was Re: [Mingw-cross-env-list] updated gtk)


From: Tony Theodore
Subject: OSX GCC Versions (was Re: [Mingw-cross-env-list] updated gtk)
Date: Mon, 27 Sep 2010 09:37:39 +1000

On 27 September 2010 07:16, Volker Grabsch <address@hidden> wrote:
> Tony Theodore <address@hidden> schrieb:
>> The basic problem is that gcc 4.2 produces 64-bit binaries by default
>> and different configure scripts can cause it to have a mismatch of 32
>> and 64-bit libs. [...]
>>
>> The attached is one (working) approach to this, it sets a conditional
>> OSX_CC_ENV that can be passed along to ./configure. It has the feel of
>> a portability variable, so I added to the place for those, even though
>> it turns out to only be required in two places (I initially thought it
>> might be necessary in other places).
>
> I think we should get to the root of this issue. It's not only "just
> two places", it's even just _one_ package!

There are two other packages affected: the native ilmbase build in
openexr (different issue - use a patch to remove "-Wno-long-double" as
this option is not available), and the native steps in Qt (similar
arch mismatch, Qt complains that it's building a 64-bit application
with a 32-bit version - use patch for makespecs)

> So why is libiconv using
> the 32-bit mode of the compiler when 64-bit is the default on that
> system?
>
> What's in the config.log of the native libiconv build(s)?

Attached are the logs for glib/libiconv. You'll see where the mismatch
happens in glib-config.log:173 and libiconv-config.log:164. The core
tests are the same, but then ./configure in glib decides to to use the
x86_64* target where libiconv uses the i386*.

Thanks,

Tony

Attachment: glib-libiconv.zip
Description: Zip archive


reply via email to

[Prev in Thread] Current Thread [Next in Thread]