Re: [Development] Load debug symbol from Qt library in lldb

[Eike Ziller]

> 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

[Soroush Rabiei]

>
> 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

[Ben Lau]

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

[Frédéric Marchal]

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?

[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.
--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?

[Konstantin Podsvirov]

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

[Soroush Rabiei]

>
> 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