|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:22.214.171.124) 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:
usr/i686-pc-mingw32/include/Qt/qconfig.hWe want to see "QT_ARCH_WINDOWS" there like this:
#define Q_BYTE_ORDER Q_LITTLE_ENDIAN
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?
|[Prev in Thread]||Current Thread||[Next in Thread]|