Re: [Development] Load debug symbol from Qt library in lldb
> On Dec 19, 2016, at 4:10 AM, Ben Lau wrote: > > Hi, > > I am tracking a crash problem in Qt library on Mac. First of all, I build a > Qt 5.7.1 library from git with : > > $ ./configure -confirm-license -developer-build -opensource -nomake examples > -nomake tests > > Then build an example program via the the qmake built > > $ qmake CONFIG+=debug > > Run it via lldb > > $ lldb ./lodashdemo.app/Contents/MacOS/lodashdemo > > $ run > > (then crash)$ image list > > ... > > [ 7] D6239705-2373-32D9-A1E9-E290DBA7CBAD 0x000101081000 > /Users/benlau/tmp/qt5/qt5/qtbase/lib/QtQml.framework/Versions/5/QtQml > > > > The QtQml is a shared library without debug symbol. The library that hold > debug symbol should be QtQml_debug located in the same folder > > $ file /Users/benlau/tmp/qt5/qt5/qtbase/lib/QtQml.framework/Versions/5/QtQml* > > /Users/benlau/tmp/qt5/qt5/qtbase/lib/QtQml.framework/Versions/5/QtQml: > Mach-O 64-bit dynamically linked shared library x86_64 > /Users/benlau/tmp/qt5/qt5/qtbase/lib/QtQml.framework/Versions/5/QtQml_debug: > Mach-O 64-bit dynamically linked shared library x86_64 > > My questions are : > > 1) can I turn qmake to link the QtQml_debug ? > or > > 2) can I build a QtQml library with debug symbol? The “macOS” way to handle frameworks and debug builds, is that the application links against the non-_debug libraries, and if you want to make it load the debug symbols you set DYLD_IMAGE_SUFFIX=_debug before running the application. http://doc.qt.io/qt-5/debug.html#debugging-in-macos-and-xcode Note that applications in /usr/bin (like /usr/bin/lldb) have an additional safe-guard that they reset the DYLD_* variables, so you need to set it in lldb for the application process: $ lldb $ settings set target.env-vars DYLD_IMAGE_SUFFIX=_debug $ run Br, -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.zil...@qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
> > If you change QDate's internals, you have to wait for Qt 6. > > You can add to its API before then, though. > Hmm... I'll think of something else then. I thought these changes are backward compatible (API only), though it seems I'm mistaken. Maybe missing something about ABI compatibility: Adding a member will change memory layout and eventually client apps will be forced to recompile I suppose... > No chance of that ever happening. QDate will continue to support Gregorian > day, month, year, as well as ISO weeks. Support for other calendaring > systems > (or maybe even other week systems) can be provided by a different class, > accessible from QDate and QLocale. > > It will support Gregorian day, month, year of course, adding calendaring system will not change default behavior. But it will change if calendar is set to something else. Nevertheless, it seems not possible for QDate to change in semantics in anyway, not for Qt6 nor any release. Following these rules, we need a new design, without changing QDate interface nor its internals. I'm thinking of some changes in viewer widgets and view classes to change their current calendar (utilizing calendar classes and QLocale) without breaking compatibility. Cheers, Soroush ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Load debug symbol from Qt library in lldb
On 19 December 2016 at 16:07, Eike Ziller wrote: > > > On Dec 19, 2016, at 4:10 AM, Ben Lau wrote: > > > > Hi, > > > > I am tracking a crash problem in Qt library on Mac. First of all, I > build a Qt 5.7.1 library from git with : > > > > $ ./configure -confirm-license -developer-build -opensource -nomake > examples -nomake tests > > > > Then build an example program via the the qmake built > > > > $ qmake CONFIG+=debug > > > > Run it via lldb > > > > $ lldb ./lodashdemo.app/Contents/MacOS/lodashdemo > > > > $ run > > > > (then crash)$ image list > > > > ... > > > > [ 7] D6239705-2373-32D9-A1E9-E290DBA7CBAD 0x000101081000 > /Users/benlau/tmp/qt5/qt5/qtbase/lib/QtQml.framework/Versions/5/QtQml > > > > > > > > The QtQml is a shared library without debug symbol. The library that > hold debug symbol should be QtQml_debug located in the same folder > > > > $ file /Users/benlau/tmp/qt5/qt5/qtbase/lib/QtQml.framework/ > Versions/5/QtQml* > > > > /Users/benlau/tmp/qt5/qt5/qtbase/lib/QtQml.framework/Versions/5/QtQml: > Mach-O 64-bit dynamically linked shared library x86_64 > > /Users/benlau/tmp/qt5/qt5/qtbase/lib/QtQml.framework/Versions/5/QtQml_debug: > Mach-O 64-bit dynamically linked shared library x86_64 > > > > My questions are : > > > > 1) can I turn qmake to link the QtQml_debug ? > > or > > > > 2) can I build a QtQml library with debug symbol? > > The “macOS” way to handle frameworks and debug builds, is that the > application links against the non-_debug libraries, and if you want to make > it load the debug symbols you set DYLD_IMAGE_SUFFIX=_debug before running > the application. > > http://doc.qt.io/qt-5/debug.html#debugging-in-macos-and-xcode > > Note that applications in /usr/bin (like /usr/bin/lldb) have an additional > safe-guard that they reset the DYLD_* variables, so you need to set it in > lldb for the application process: > $ lldb > $ settings set target.env-vars DYLD_IMAGE_SUFFIX=_debug > $ run > > Br, > Hi Eike, It works. Thank you! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
On Saturday 17 December 2016 11:16:24 Thiago Macieira wrote: > On sábado, 17 de dezembro de 2016 17:13:38 PST Soroush Rabiei wrote: > > The idea is to remove all calendar > > calculation code out of the QDate (into QCalendarSystem possibly). I think > > QDate already has been bloated and knows more that it needs. Consequently, > > there is no chance to add other calendaring API into QDate, and I think > > it's wrong to add such implementation to QDate. My view of QDate is this: > > QDate represents a day in time. So it only needs to know what day it is > > (how many days are to the day 0). > > No chance of that ever happening. QDate will continue to support Gregorian > day, month, year, as well as ISO weeks. Support for other calendaring > systems (or maybe even other week systems) can be provided by a different > class, accessible from QDate and QLocale. Can you elaborate on the reasons that prevent any change of that kind in QDate? Maybe they can be worked around? Soroush's purpose is to allow the use of other calendar systems with minimum application changes (i.e. simply telling QDate to use a different date computation algorithm). I find his idea very attractive and not at odds with some other Qt classes. Your solution implies developers have to know about those calendars and are willing to support them in their applications. That's very unlikely to happen if they have to change lot of code and replace QDate with another class. As a developer, I don't want to know about the gory details of date computation with calendars I have never heard of. Adding "one month" to a date should use the same code whatever the underlying calendar is. The correct calendar to use should be a simple configuration parameter to make it as universally available as retrieving the local time irrespective of the user's location or generating the plural of a message in any language my application could be translated to even without my knowledge. Frederic ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Fwd: [Interest] QtIFW 2.0.4 Release?
Hi Konstantin, It will happen earliest in the beginning of next year. Sorry but I don’t have exact time or week to give you. --Katja Hello again! 22:12, 13 december 2016 г., Konstantin Podsvirov mailto:konstan...@podsvirov.pro>>: Hello guys! QtSDK maintenance now based on 2.0.4 framework, but what about 2.0.4 tag and binaries for QtIFW? Ping. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Fwd: [Interest] QtIFW 2.0.4 Release?
Hello Katja! Your answer is enough.15:17, 19 december 2016 г., Katja Marttila :Hi Konstantin, It will happen earliest in the beginning of next year. Sorry but I don’t have exact time or week to give you. --KatjaHello again! 22:12, 13 december 2016 г., Konstantin Podsvirov: Hello guys! QtSDK maintenance now based on 2.0.4 framework, but what about 2.0.4 tag and binaries for QtIFW? Ping. Thank you for the development of a useful tool.This year, I'll try not to bother you.I wish you good holidays and Merry Christmas.--Regards,Konstantin Podsvirov(author of the CPack IFW generator:https://cmake.org/cmake/help/latest/module/CPackIFW.html) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calendar Systems proposal
> > Can you elaborate on the reasons that prevent any change of that kind in > QDate? Maybe they can be worked around? > > According to https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B#The_Do.27s_and_Don.27ts Adding a member to struct or class is not possible without breaking ABI. On the other hand https://wiki.qt.io/Qt-Version-Compatibility suggests that Qt minor releases are backwards binary and source compatible. So there is no chance of touching QDate in Qt5 series. I'm working on a solution to provide calendar functionality without breaking ABI, while considering possibilities for Qt6 (keep minimum effort for converting current, temporary solution to futures Qt6 one). This may fail of course, There are too many details that need to be discussed. How we are supposed to change underlying calendar without adding information to QDate? Can we add arguments to all methods with a default value? Something like: QDate d; qDebug() << d.year(); // prints 2016 qDebug() << d.year(QCalendar::Jalali); // prints 1395 And then force relevant widgets/views to show/edit date and time on a specific calendar system: QDateEdit de; de.setDate(d); de.setCalendarSystem(QCalendar::Hebrew); // Is this possible? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development