[Development] 4.8 Build failing on Mac OS 10.7 / XCode 4.2

Tue Nov 1 15:18:21 CET 2011

On 1 Nov 2011, at 15:13, ext eike.ziller at nokia.com wrote:

> 
> On 31 Oct 2011, at 23:24, ext Alexis Menard wrote:
> 
>> On Mon, Oct 31, 2011 at 12:08 PM,  <eike.ziller at nokia.com> wrote:
>>> 
>>> On 30 Oct 2011, at 11:08, ext Alexis Menard wrote:
>>> 
>>>> 2011/10/30 Thiago Macieira <thiago at kde.org>:
>>>>> On Saturday, 29 de October de 2011 09:22:07 Chris Meyer wrote:
>>>>>> I would like to call attention to the following problem which is that
>>>>>> the Qt 4.8 build fails using the latest Mac OS 10.7 / Xcode 4.2 tools.
>>>> 
>>>> For *your* use case. Normal and default cases work as the CI and other
>>>> reports say.
>>>> 
>>>>>> 
>>>>>> https://bugreports.qt.nokia.com/browse/QTBUG-20619
>>>>>> 
>>>>>> Somehow the RC 1 candidates are being built... so there must be some
>>>>>> workaround. Is it possible to post the configure commands,
>>>>>> environment, and tools used to build the official 4.8 RC's?
>>>>>> 
>>>>>> Also, I would hope that unilaterally closing a bug that affects a
>>>>>> primary platform (the Mac is still a primary platform, right?) with a
>>>>>> 'Won't Fix'  and closing down all discussion on the issue is a trend
>>>>>> that won't continue.
>>>> 
>>>> It's a primary platform but an exotic build setup.
>>>> 
>>>>> 
>>>>> You're over-reacting. That just means he (the assignee) will not fix the bug.
>>>>> If he had the power to close down all discussion, your email wouldn't exist
>>>>> and I wouldn't be typing this reply right now.
>>>>> 
>>>>> Also do note that comments after the bug being closed are still received just
>>>>> as they were before. You can contribute more information to the report so that
>>>>> a solution can be found.
>>>>> 
>>>>>> Zeno Albisser (the one who closed the bug) made some suggestions, but
>>>>>> since the bug is closed, there is no place for developers to post
>>>>>> information about what works and what doesn't work. My first thought
>>>>>> is to turn off debug libs; but I'm guessing other developers have done
>>>>>> it already so it would be nice if the bug were to remain open so that
>>>>>> we could all benefit from trial and error until a solution is found.
>>>>> 
>>>>> Sure there is: the bug report. Comments are not disabled in closed bug
>>>>> reports. It just means Zeno is no longer looking for a solution. But if you
>>>>> provide one that works for everyone...
>>>> 
>>>> Which I believe it is hard to find. I would have close the bug myself.
>>>> The command line option that the test case passes -arch x86 -arch
>>>> x86_64 is part of the so called "combination of command lines we can't
>>>> support". It perhaps worked before but with WebCore growing everyday
>>>> that was pure luck.
>>> 
>>> Calling the abitlity to build 32+64bit fat binaries "pure luck" is a bit funny (and feels a bit offensive to me), since we always provided universal 32bit+64bit binary packages for Mac on qt.nokia.com/downloads, up to 4.7.4.
>> 
>> Was not meant to be be offensive. You have to keep in mind that what
>> ships in 4.7 is at least a good year old WebKit and it is much bigger
>> now.
>> 
>>> 
>>> Also, universal binaries are quite common on Mac. Btw, even Safari comes in the form of a universal 32+64bit binary (at least on snow leopard) ;)
>>> 
>>> Anyhow, it looks like the problem is not the combination of "-arch x86 -arch x86_64" but the combination of "-debug_and_release -arch x86 -arch x86_64". Which I think would be acceptable. (I just checked that "-release -arch x86 -arch x86_64" works for me.)
>> 
>> Debug build of WebKit are always problematic as it requires a lot of
>> RAM to link for example (read at least 8GB), on Linux it may kill the
>> linker sometimes because it runs out of memory.
> 
> 
>> Debug build of WebKit
>> are to use only if really needed.
> 
> That reminds me: Wasn't there a time where debug was off by default for QtWebKit even when doing a debug build of Qt? Where's that gone?
> I suppose the main problem is that doing the perceived trivial thing "./configure -arch x86 -arch x86_64 && make" fails to build.
> Afair Qt didn't build webkit in debug by default, and you could enable debug for webkit with a separate configure switch.
> Default compile/link time and disk space/RAM consumption would be much reduced too, in that case.

Actually I see now that there's the "-webkit-debug" configure switch.

 -webkit-debug ...... Build the WebKit module with debug symbols.

which is *not* supposed the default, so it looks like this is broken.

> Btw, here's a visualization of *how* big webkit actually got within Qt (debug): http://imagebin.org/181891
> 
> ++ Eike
> 
>>>> Splitting the build of WebCore into two pieces so
>>>> that ranlib could work and your test case work is just stupid because
>>>> it will add complexity for us to support/implement this, and we don't
>>>> want.  In the other hand if it's that important for you, you can try
>>>> to have two builds and make a mixture of the library in one of the
>>>> framework if that's possible.
>>> 
>>> 
>>> 
>>> --
>>> Eike Ziller
>>> Principal Software Engineer
>>> 
>>> Nokia, Qt Development Frameworks
>>> 
>>> Nokia gate5 GmbH
>>> Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany
>>> Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B
>>> Umsatzsteueridentifikationsnummer: DE 812 845 193
>>> Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori
>>> 
>>> 
>> 
>> 
>> 
>> -- 
>> Alexis Menard (darktears)
>> Software Engineer
>> INdT Recife Brazil
> 
> -- 
> Eike Ziller
> Principal Software Engineer
> 
> Nokia, Qt Development Frameworks
> 
> Nokia gate5 GmbH
> Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany
> Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B
> Umsatzsteueridentifikationsnummer: DE 812 845 193
> Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller
Principal Software Engineer

Nokia, Qt Development Frameworks

Nokia gate5 GmbH
Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany
Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B
Umsatzsteueridentifikationsnummer: DE 812 845 193
Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori