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

[Tony Theodore]

On 27 September 2010 10:58, Volker Grabsch <address@hidden> wrote:
> Tony Theodore <address@hidden> schrieb:
>> On 27 September 2010 07:16, Volker Grabsch <address@hidden> wrote:
>> >
>> > 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*.
>
> This is really strange. Both use standard ./configure mechnisms.
> However, they have different Autoconf versions. Glib, which works
> correctly, uses 2.67 while libiconv uses 2.63. Maybe there was a
> bugfix to that issue between those Autoconf versions.
>
> It might be worth a try to run autconf >= 2.64 over libiconv before
> the native build.

I couldn't get it to reconfigure entirely (with 2.65 and 2.67), but it
seems to be later versions of config.guess that use the compiler as
part of the processor determination. It's a bit of a red herring
though, libiconv was still a 64-bit lib (using nm to inspect it).

I think there's a simpler solution. Removing the --with-libiconv=gnu
option allows configure to complete - it seems to go through a few
more checks before failing. There's a build failure later, but some
extra checks for __APPLE__ and __LP64__ allow the build to succeed
(see attached).

Removing the --with-libiconv=gnu option also works on FreeBSD (which
seems to be the origin of the native libiconv build [1]). It's failing
on Ubuntu though, with exactly the same error as OSX before the patch.
I imagine we could just check for __LP64__, but I'm stuck now.

Cheers,

Tony

[1] http://hg.savannah.gnu.org/hgweb/mingw-cross-env/rev/3b1f34a06b12

osx-glib.diff
Description: Binary data