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. 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.) > 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
