[Top][All Lists]

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

Re: [Mingw-cross-env-list] [patch] fix for building Qt on Mac with "-arc

From: Mark Brand
Subject: Re: [Mingw-cross-env-list] [patch] fix for building Qt on Mac with "-arch windows"
Date: Fri, 21 May 2010 22:43:16 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100520 SUSE/3.1rc1-1.1 Thunderbird/3.1

It's also now in the attached patch for the current development
mingw-cross-env with Qt 4.6.2.

It's possible that the solution will expose new issues, so please try it
before applying! :)
Tony, are you able to confirm that this patch solves the Mac issue?
It seems to be the only thing that holds up the release.
It doesn't fix the issue, I sent a message earlier (twice since the
first had a large attachment), but it may have been blocked.

However, I just had a thought. Mark, can you check my logic.

For qt 4.6 (current dev version), this patch won't actually achieve
the desired native "bitness" of the build tools, since they are built
from unpatched sources.

This patch is not about the "endian" of the build tools.  You are right that this patch has nothing to do with the native build of the qt tools. (You said "bitness", but it's really about byte order, isn't it?)

 The native tools will still be built with
whatever the default is. Adding "-arch windows" to the native build
seems contradictory - even if it does achieve a desired result.

The patch uses "-arch windows" *only* on the 2nd step where the target is win32.

If the above is right, then the patch may not be applicable to 4.6. We
can keep working on the 4.7 issues without holding up the release.

It's hard to answer this completely without going into some detail, so I offer you this for your reading pleasure

Just to avoid any misunderstanding, this is about this patch for Qt 4.6.2 in current mingw-cross-env development:
   posted earlier today, 21 May

The problem it fixes is that all -arch values (-arch may appear more than once) get assigned to CFG_MAC_ARCHS when the Mac platform is detected. (Not a bug since the configure script was not originally intended to support cross building for windows. This is a new feature we are adding.)

We were not bothered by this problem until we started specifying "-arch windows" and stopped specifying "-host-, that is since:

This problem affects precisely the "2nd stage" of the build process, not the "native" build. Configure aborts when it decides later that "windows" is not a valid Mac architecture. Also, perhaps less apparently, the "arch" of the target will be wrong.

What we want is for the -arch value (only one in our case, and that is "windows") to get assigned to CFG_ARCH and not to CFG_MAC_ARCHS. Here is the original code of "configure" where "$VAL" is the value passed with -arch:

    if [ "$PLATFORM_MAC" = "yes" ]; then

The patch changes it to this:

     if [ "$PLATFORM_MAC" = "yes" ] && [ "$VAL" != "windows" ]; then

By the way, this "windows" value ends up in the (identical) installed headers:
We want to see "QT_ARCH_WINDOWS" there like this:
#define Q_BYTE_ORDER Q_LITTLE_ENDIAN                                                                                                                                                                                                                                      
#define Q_BYTE_ORDER Q_LITTLE_ENDIAN                                                                                                                                                                                                                                      
/* Machine Architecture */                                                                                                                                                                                                                                                
#ifndef QT_BOOTSTRAPPED                                                                                                                                                                                                                                                   
# define QT_ARCH_WINDOWS                                                                                                                                                                                                                                                  
# define QT_ARCH_X86_64                                                                                                                                                                                                                                                   
/* Compile time features */                                                                                                                                                                                                                                               

That was 4.7, 4.6 seems to already have the -little-endian enabled.

Did you see my last message? I don't think these changes are
applicable to 4.6 where the native and cross builds are separate.

Now, back to the "endian" problem: After the patch just discussed is applied to Qt 4.7-beta1, a new problem becomes visible. This is the "which endian" of the Mac host, which we also now know how to fix. This problem does not affect Qt 4.6.2 in mingw-cross-env because the "native build" is completely distinct, as you observed.

In conclusion, I think that this patch must be necessary for Qt 4.6.2 currently in mingw-cross-env development. Can you confirm that it is both necessary and sufficient?



reply via email to

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