On 1 Nov 2011, at 15:13, ext [email protected] wrote: > > On 31 Oct 2011, at 23:24, ext Alexis Menard wrote: > >> On Mon, Oct 31, 2011 at 12:08 PM, <[email protected]> wrote: >>> >>> On 30 Oct 2011, at 11:08, ext Alexis Menard wrote: >>> >>>> 2011/10/30 Thiago Macieira <[email protected]>: >>>>> 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 > [email protected] > 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
