Re: [Development] Should QVariant be doing fuzzy comparisons on doubles?

[Thiago Macieira]

On quarta-feira, 21 de setembro de 2016 12:00:15 PDT Marc Mutz wrote:
> We have a handful of classes in Qt which have a
> 'reserved' field that doesn't get initialized (so it better should be named
> 'unusable')

That depends on whether the copy constructors and destructor are inline or 
not.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Should QVariant be doing fuzzy comparisons on doubles?

[Mathias Hasselmann]

Am 22.09.2016 um 00:58 schrieb André Pönitz:

On Wed, Sep 21, 2016 at 08:57:01AM +0200, Olivier Goffart wrote:

No, it's not. It's changing undefined behavior into defined
behavior.


But in many case, we want to put something in a QVariant, and we
never compare this variant.  Forbidding types that do not have an
operator== to be in a QVariant might be to strict.


Forbidding types without operator== in QVariants is not needed,
not even if one wanted to use associative container with
QVariants as keys.

[Pseudocode]

bool operator(QVariant(Foo) a, QVariant(Bar) b)
{
if Foo != Bar:
return false
if Foo has no operator==():
return true
return (Foo)a == (Foo)b
}

establishes an equivalance relation by lumping all "uncomparable"
objects into a single equivalency class.


I rather was considering to return false. But indeed. Forcing all that 
types into a single equivalency class feels that unnatural, that users 
should notice that issue much quicker, than if we'd return false.


Would that be sufficient to warn Qt users, or would we also have to 
print a warning?


Ciao,
Mathias
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Should QVariant be doing fuzzy comparisons on doubles?

[Mathias Hasselmann]

Am 21.09.2016 um 12:00 schrieb Marc Mutz:

On Wednesday 21 September 2016 11:42:41 Mathias Hasselmann wrote:

No matter what order I use for config and value, the compiler will pad
and -Wpadded will complain. How am I supposed to fix this? This
solutions that come to my mind all are ugly, but most likely I am just
stupid.


Tabs? Seriously? :)


E-mail clients and their horrible text editors.



struct Sensor
{
enum Config { NotInitialized, PullUp, PullDown, Analog };

Config config;
char padding[alignof(QVariant) - sizeof(Config)];
QVariant value; //[1]
}

and pray for alignof(QVariant) - sizeof(Config) != 0.


Yup, one of solutions I had in mind and rejected for expected that 
prayer remaining unheard while juggling with 32 and 64 bit code.



I wasn't serious about -Wpadded, but incidentally, my example shows that type
traits also won't help. We have a handful of classes in Qt which have a
'reserved' field that doesn't get initialized (so it better should be named
'unusable'). A type trait cannot tell if a field called 'padding', 'reserved',
'unused' or 'unusable' is meant to be part of equality or not.


Q_DECLARE_TYPEINFO(QBar, Q_PADDED_TYPE) // :D

Ciao,
Mathias
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt5 Bearer: broken PPP support

[Thiago Macieira]

On quarta-feira, 21 de setembro de 2016 07:57:42 PDT Thiago Macieira wrote:
> I'll fix it when I'm back home tonight.

https://codereview.qt-project.org/171756

It was quite simple.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] linuxdeployqt

[Thiago Macieira]

On quarta-feira, 21 de setembro de 2016 18:16:53 PDT Thiago Macieira wrote:
> Unless we broke it with the new configure system. The commit by Ossi that
> fixed it is getting reverted in 5.8.

Sorry, reverted in dev.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] linuxdeployqt

[Thiago Macieira]

On quarta-feira, 21 de setembro de 2016 22:09:05 PDT Konstantin Tokarev wrote:
> > $ ls /opt/poky/sysroots/*/etc/ld.so.conf
> > /opt/poky/sysroots/aarch64-poky-linux/etc/ld.so.conf
> > /opt/poky/sysroots/armv7a-neon-poky-linux-gnueabi/etc/ld.so.conf
> > /opt/poky/sysroots/mips32r2-poky-linux/etc/ld.so.conf
> > /opt/poky/sysroots/mips64-poky-linux/etc/ld.so.conf
> > /opt/poky/sysroots/ppc7400-poky-linux/etc/ld.so.conf
> > /opt/poky/sysroots/ppce500v2-poky-linux-gnuspe/etc/ld.so.conf
> > /opt/poky/sysroots/x86_64-pokysdk-linux/etc/ld.so.conf
> 
> Do these file have any content?
> 
> I have a few fully working toolchains from 2 vendors at my hands, one has
> empty ld.so.conf, others don't have any

And that's fine. Those files in my Poky sysroots are empty too. It just means 
that there are no additional directories to search, besides those reported by 
the compiler, which in turn were already detected by qmake & configure. 
Unfortunately, I don't have a cross-compilation built in my current laptop to 
prove it (it's only 5 months old).

Unless we broke it with the new configure system. The commit by Ossi that fixed 
it is getting reverted in 5.8.

See variable QMAKE_DEFAULT_LIBDIRS.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Should QVariant be doing fuzzy comparisons on doubles?

[André Pönitz]

On Wed, Sep 21, 2016 at 08:57:01AM +0200, Olivier Goffart wrote:
> > No, it's not. It's changing undefined behavior into defined
> > behavior.
> 
> But in many case, we want to put something in a QVariant, and we
> never compare this variant.  Forbidding types that do not have an
> operator== to be in a QVariant might be to strict.

Forbidding types without operator== in QVariants is not needed,
not even if one wanted to use associative container with 
QVariants as keys.

[Pseudocode]

bool operator(QVariant(Foo) a, QVariant(Bar) b)
{
if Foo != Bar:
return false
if Foo has no operator==():
return true
return (Foo)a == (Foo)b
}

establishes an equivalance relation by lumping all "uncomparable"
objects into a single equivalency class.

One might argue that considering all instances of classes without
operator== as equal makes associative containers of them not
exactly useful, but it is at least formally correct, defined
behaviour and can be easily turned into correct, defined and
useful behaviour by the user himself by providing some operator==
for his types.

This is certainly better than the current behaviour that is not
exactly useful[1], formally incorrect, undefined and unfixable from
the user side.

Andre'


[1] "Not exactly useful" e.g. as in "funny effects like the number
of elements in an associative container depending on the insertion
order":

int main()
{
QVariant v1('a'), v2(QChar('a')), v3(QString("a"));

QMap maps[] = {
{ {v1,1}, {v2,1}, {v3,1} }, { {v1,1}, {v3,1}, {v2,1} },
{ {v2,1}, {v1,1}, {v3,1} }, { {v2,1}, {v3,1}, {v1,1} },
{ {v3,1}, {v1,1}, {v2,1} }, { {v3,1}, {v2,1}, {v1,1} }
};

for (auto h : maps)
qDebug() << h.size();
}

-> 2 2 1 1 2 2


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] linuxdeployqt

[Konstantin Tokarev]

21.09.2016, 20:41, "Thiago Macieira" :
> On quarta-feira, 21 de setembro de 2016 19:24:34 PDT Oswald Buddenhagen wrote:
>>  > and you can then search the
>>  > paths from /etc/ld.so.conf & /etc/ld.so.conf.d/*.
>>
>>  that will suffer from x-build issues again.
>
> Hmm... if we're cross-compiling, we should have access to the path to the
> sysroot, so we can find ld.so.conf there.
>
> $ ls /opt/poky/sysroots/*/etc/ld.so.conf
> /opt/poky/sysroots/aarch64-poky-linux/etc/ld.so.conf
> /opt/poky/sysroots/armv7a-neon-poky-linux-gnueabi/etc/ld.so.conf
> /opt/poky/sysroots/mips32r2-poky-linux/etc/ld.so.conf
> /opt/poky/sysroots/mips64-poky-linux/etc/ld.so.conf
> /opt/poky/sysroots/ppc7400-poky-linux/etc/ld.so.conf
> /opt/poky/sysroots/ppce500v2-poky-linux-gnuspe/etc/ld.so.conf
> /opt/poky/sysroots/x86_64-pokysdk-linux/etc/ld.so.conf

Do these file have any content?

I have a few fully working toolchains from 2 vendors at my hands, one has empty 
ld.so.conf, others don't have any

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] linuxdeployqt

[Thiago Macieira]

On quarta-feira, 21 de setembro de 2016 19:24:34 PDT Oswald Buddenhagen wrote:
> > and you can then search the
> > paths from /etc/ld.so.conf & /etc/ld.so.conf.d/*.
> 
> that will suffer from x-build issues again.

Hmm... if we're cross-compiling, we should have access to the path to the 
sysroot, so we can find ld.so.conf there.

$ ls /opt/poky/sysroots/*/etc/ld.so.conf
/opt/poky/sysroots/aarch64-poky-linux/etc/ld.so.conf
/opt/poky/sysroots/armv7a-neon-poky-linux-gnueabi/etc/ld.so.conf
/opt/poky/sysroots/mips32r2-poky-linux/etc/ld.so.conf
/opt/poky/sysroots/mips64-poky-linux/etc/ld.so.conf
/opt/poky/sysroots/ppc7400-poky-linux/etc/ld.so.conf
/opt/poky/sysroots/ppce500v2-poky-linux-gnuspe/etc/ld.so.conf
/opt/poky/sysroots/x86_64-pokysdk-linux/etc/ld.so.conf


-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] linuxdeployqt

[Henry Skoglund]

On 2016-09-21 17:02, Thiago Macieira wrote:

On quarta-feira, 21 de setembro de 2016 11:06:59 PDT Konrad Rosenbaum wrote:

RPath may be a bit tricky: normally Qt compiles it's lib path into RPath,
but with a deploy script you do not want that RPath anymore, instead you'd
want to change it to $ORIGIN (literally, not the value of a variable).


Don't change. If you want $ORIGIN, you tell the linker you want it.

Also, RPATH is tricky, but for another reason:

- If DT_RUNPATH is present, check $LD_LIBRARY_PATH first and ignore DT_RPATH
- if only DT_RPATH is present, check it before $LD_LIBRARY_PATH



About paths, if we want linuxdeployqt to harmonize with windeployqt's 
behavior: since last year windeployqt unpatches (i.e. neuters) Qt's 
installation path in Qt5Core.dll, so that for example my Qt5Core.dll is 
patched from "qt_prfxpath=C:\Qt\5.7\msvc2013\" to "qt_prfxpath=.". This 
severes any pathological connections my app would have with my Qt 
installation (and shuts a small but possible backdoor).


(And, when I copy my app to a vanilla PC, I can either place the 
platforms subdirectory next to my .exe file, or I want to get fancy, 
copy the whole plugins tree and place it next my .exe file. Either works 
fine for loading qwindows.dll.)


So perhaps linuxdeployt could do the same, i.e. neuter the path to my Qt 
installation (e.g. change "prfxpath=/home/henry/Qt/5.7/gcc_64" to 
"prfxpath=." in libQt5Core.so.5.7.0?



In theory you could apply the same reasoning to RPATH, why let Qt's 
installation path remain artifacted in the .elf file? Perhaps $ORIGIN is 
a nicer default. (windeployqt does not do this step, as on Windows 
$ORIGIN is the "standard" anyway).


Rgrds Henry


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt5 Bearer: broken PPP support

[Thiago Macieira]

On quarta-feira, 21 de setembro de 2016 10:11:00 PDT Alexander Smirnov wrote:
> ppp0 interface is created by typical Linux pppd daemon.
> tun2 interface is created by openvpn.
> 
> > I'll fix it.
> 
> Please let me know, if you need additional information.

I thought I'd fixed the tun case, as I do have an openvpn VPN...

Anyway, that means it's that much easier for me to reproduce and fix. I've got 
this with tst_qnetworkinterface dump, for an openconnect VPN:

Interface:  "vpn0" 
index:  15
flags:  Up,Running,PointToPoint,Multicast
type:   QNetworkInterface::InterfaceType(Virtual)
hw address: 00:00:00:00:00:00
address  0: 10.255.92.115/19 (255.255.224.0) broadcast 10.255.95.255
Interface:  "vpn0" 
index:  15
flags:  Up,Running,PointToPoint,Multicast
type:   QNetworkInterface::InterfaceType(Virtual)
hw address: 00:00:00:00:00:00

I'll fix it when I'm back home tonight.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] linuxdeployqt

[Thiago Macieira]

On quarta-feira, 21 de setembro de 2016 11:06:59 PDT Konrad Rosenbaum wrote:
> RPath may be a bit tricky: normally Qt compiles it's lib path into RPath,
> but with a deploy script you do not want that RPath anymore, instead you'd
> want to change it to $ORIGIN (literally, not the value of a variable).

Don't change. If you want $ORIGIN, you tell the linker you want it.

Also, RPATH is tricky, but for another reason:

- If DT_RUNPATH is present, check $LD_LIBRARY_PATH first and ignore DT_RPATH
- if only DT_RPATH is present, check it before $LD_LIBRARY_PATH

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] linuxdeployqt

[Thiago Macieira]

On quarta-feira, 21 de setembro de 2016 10:11:01 PDT probono wrote:
> ldd not only provides the name of the libraries to be loaded, but also
> the paths to the locations where they are loaded from. How would I get
> this information without using ldd?

Manually.

First, use the environment variable $LD_LIBRARY_PATH. The default search path 
is known to qmake (variable QMAKE_DEFAULT_LIBDIRS) and you can then search the 
paths from /etc/ld.so.conf & /etc/ld.so.conf.d/*.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Konstantin Tokarev]

21.09.2016, 12:34, "Friedemann Kleint" :
> Hi,
>
> technically speaking: is using the .rst format set in stone? I find this
> difficult to handle; one needs a local web server to view it AFAIK. .md
> comes to mind as alternative?

Are you implying that you need local web server to view HTML? :)

>
> Regards,
> Friedemann
>
> --
> Friedemann Kleint
> The Qt Company GmbH
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Thiago Macieira]

On quarta-feira, 21 de setembro de 2016 11:34:02 PDT Friedemann Kleint wrote:
> Hi,
> 
> technically speaking: is using the .rst format set in stone? I find this
> difficult to handle; one needs a local web server to view it AFAIK. .md
> comes to mind as alternative?

How is that different from .md? Don't you need a tool that converts it from 
the source format to HTML?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Иван Комиссаров]

I was using CMake for several years (and still forced to use it now),
however i moved all my projects to QBS for one reason - CMake is too
complex. It has great documentation, but it can't be used without it; on
the contrary, qbs is very intuitive. I don't have to remember tons of
variables like CMAKE_CURRENT_SOURCE_DIR, CMAKE_SOURCE_DIR (there is also
PROJECT_SOURCE_DIR!) with qbs, property names are simple. Every complex
task lead to tons of code with CMake, it's hard to maintain those scripts.
I don't want to do that complex job maintaining buildsystem, i want to
write code.
Yes, if a project will use both CMake and QBS build systems, all the
variables and logic will be almost the same; however qbs is much clearer
and easier.
I tried to create a simple project with typical usecases - libraries,
tests, app bundles that uses both CMake and QBS, but i didn't have time to
finish the cmake part https://github.com/ABBAPOH/qbsfish (not sure if it
even works).
For now, cmake scripts looks much easier, but adding new features is rather
painful - i have to use the docs all the time.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Andrew Knight]

Hi,


On 09/21/16 12:34, Friedemann Kleint wrote:
> Hi,
>
> technically speaking: is using the .rst format set in stone? I find
> this difficult to handle; one needs a local web server to view it
> AFAIK. .md comes to mind as alternative?
>

We discussed this at QtCon and settled on ReStructured Text because it
results in a cleaner plaintext document (i.e. more document-like, less
markup-like) than markdown. It's also the format PIP uses, but note that
it doesn't necessarily matter: each QUIP can declare its MIME type in
the header.

Anyway, I don't think you need a web server to view the formatted RST
result. Docutils has examples on how to convert to HTML using Python:
http://docutils.sourceforge.net/docs/user/tools.html#rst2html-py

--
Andrew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Should QVariant be doing fuzzy comparisons on doubles?

[Marc Mutz]

On Wednesday 21 September 2016 11:42:41 Mathias Hasselmann wrote:
> Am 21.09.2016 um 09:52 schrieb Marc Mutz:
> > On Wednesday 21 September 2016 09:23:35 Mathias Hasselmann wrote:
> >> Maybe some clever use of type traits can tell us if your structs contain
> >> alignment wholes?
> > 
> > -Werror=padded :)
> 
> Yes, but how is it supposed to help? Let me show a real world example:
> 
>   struct Sensor
>   {
>   enum Config { NotInitialized, PullUp, PullDown, Analog };
> 
>   Config config;
>   QVariant value; //[1]
>   }
> 
> No matter what order I use for config and value, the compiler will pad
> and -Wpadded will complain. How am I supposed to fix this? This
> solutions that come to my mind all are ugly, but most likely I am just
> stupid.

Tabs? Seriously? :)

struct Sensor
{
enum Config { NotInitialized, PullUp, PullDown, Analog };
 
Config config;
char padding[alignof(QVariant) - sizeof(Config)];
QVariant value; //[1]
}

and pray for alignof(QVariant) - sizeof(Config) != 0.

I wasn't serious about -Wpadded, but incidentally, my example shows that type 
traits also won't help. We have a handful of classes in Qt which have a 
'reserved' field that doesn't get initialized (so it better should be named 
'unusable'). A type trait cannot tell if a field called 'padding', 'reserved', 
'unused' or 'unusable' is meant to be part of equality or not.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.8 API review (vs 5.7.0)

[Edward Welbourne]

On 2016 September 9 I announced:

> It's that time in the release cycle again - API review time.
> If you can catch a moment when Gerrit isn't hiding, please
> take a look at any modules you care for:

> https://codereview.qt-project.org/170634 -- qtbase
> https://codereview.qt-project.org/170635 -- qtdeclarative
> https://codereview.qt-project.org/170636 -- qtactiveqt
> https://codereview.qt-project.org/170637 -- qtmultimedia
> https://codereview.qt-project.org/170638 -- qttools
> https://codereview.qt-project.org/170639 -- qtlocation
> https://codereview.qt-project.org/170640 -- qtconnectivity
> https://codereview.qt-project.org/170641 -- qtwayland
> https://codereview.qt-project.org/170642 -- qt3d
> https://codereview.qt-project.org/170643 -- qtserialbus
> https://codereview.qt-project.org/170644 -- qtserialport
> https://codereview.qt-project.org/170645 -- qtandroidextras
> https://codereview.qt-project.org/170646 -- qtwebsockets
> https://codereview.qt-project.org/170647 -- qtwebengine
> https://codereview.qt-project.org/170648 -- qtcanvas3d
> https://codereview.qt-project.org/170649 -- qtcharts
> https://codereview.qt-project.org/170650 -- qtdatavis3d
> https://codereview.qt-project.org/170651 -- qtvirtualkeyboard
> https://codereview.qt-project.org/170652 -- qtscxml

I've today done an update to pick up fixes to issues found there, plus
on-going changes to 5.8; and the review scripts are a bit smarter now,
so have refined some details.  In particular, they now find (possibly
recent) changes also in:

https://codereview.qt-project.org/171662 -- qtquickcontrols2

... and I seem to need to kick a few where the update landed in a new
review; somehow I failed at amending :-(

In any case, if you grumbled about one of these reviews, you should have
mail about its update (if it got one - or you'll get one shortly when I
fix the failed amends).

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Should QVariant be doing fuzzy comparisons on doubles?

[Mathias Hasselmann]

Am 21.09.2016 um 09:52 schrieb Marc Mutz:

On Wednesday 21 September 2016 09:23:35 Mathias Hasselmann wrote:

Maybe some clever use of type traits can tell us if your structs contain
alignment wholes?


-Werror=padded :)



Yes, but how is it supposed to help? Let me show a real world example:

struct Sensor
{
enum Config { NotInitialized, PullUp, PullDown, Analog };

Config config;
QVariant value; //[1]
}

No matter what order I use for config and value, the compiler will pad 
and -Wpadded will complain. How am I supposed to fix this? This 
solutions that come to my mind all are ugly, but most likely I am just 
stupid.


[1] Yes, the use of QVariant in this case is questionable,
but that's not the point.

Ciao,
Mathias

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Friedemann Kleint]

Hi,

technically speaking: is using the .rst format set in stone? I find this 
difficult to handle; one needs a local web server to view it AFAIK. .md 
comes to mind as alternative?


Regards,
Friedemann

--
Friedemann Kleint
The Qt Company GmbH

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] linuxdeployqt

[Konrad Rosenbaum]

Hi,

On Wed, September 21, 2016 10:11, probono wrote:
> 2016-09-19 16:45 GMT+02:00 Louai Al-Khanji :
>> From a quick look it seems to be mostly well written. I do wonder
>> whether it might be better to use a tool other than ldd to find the
>> library dependencies. objdump -p provides the same information, and also
>> works for cross-compiles.
>
> ldd not only provides the name of the libraries to be loaded, but also
> the paths to the locations where they are loaded from. How would I get
> this information without using ldd?

By implementing the same algorithm?

It's pretty simple actually:

* go through $LD_LIBRARY_PATH
* go through RPath
* go through /etc/ld.so.config
(I think there are 1 or 2 more, look it up, it's documented)

RPath may be a bit tricky: normally Qt compiles it's lib path into RPath,
but with a deploy script you do not want that RPath anymore, instead you'd
want to change it to $ORIGIN (literally, not the value of a variable). So
you may have to check the location of linuxdeployqt and derive the
original lib path from there.

For each path that is being checked: find a file that matches the name,
check that it has the correct ELF platform (x86, amd64, x32, arm, etc.) -
if it matches, take it and add its dependencies to the list.

Ldd has several downsides:

* it may not be available on some platforms (e.g. some embedded devices)
* its output format may change without warning
* it cannot check programs for platforms that do not run on your host
(anything that is cross-compiled, or if the binary loader is missing or
broken)
* it is unsafe (although we'll assume that you will not compile and deploy
a program that sabotages your own System)


Konrad


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt 5.6.2 packages for testing

[Jani Heikkinen]

Hi all,


We have final Qt 5.6.2 packages for your testing available:

Windows:http://download.qt.io/snapshots/qt/5.6/5.6.2/569/

Linux: http://download.qt.io/snapshots/qt/5.6/5.6.2/503/

Mac:http://download.qt.io/snapshots/qt/5.6/5.6.2/436/

src: http://download.qt.io/snapshots/qt/5.6/5.6.2/latest_src/


Please check the packages to be sure those are still Ok. We are planning to 
release these packages as Qt 5.6.2 at the beginning of next week so please 
inform me immediately if there is something badly broken. Packages are based on 
https://codereview.qt-project.org/#/c/170236/


Please update Qt 5.6.2 known issues page as well: 
https://wiki.qt.io/Qt_5.6.2_Known_Issues


br,

Jani


Jani Heikkinen
Release Manager

The Qt Company
Elektroniikkatie 13
90590 Oulu Finland
jani.heikki...@qt.io
+358 50 4873735
http://qt.io


[http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png]
[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png]
 [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] 
   
[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] 
  
[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] 
   
[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] 


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] linuxdeployqt

[probono]

2016-09-19 16:45 GMT+02:00 Louai Al-Khanji :
> From a quick look it seems to be mostly well written. I do wonder whether it 
> might be better to use a tool other than ldd to find the library 
> dependencies. objdump -p provides the same information, and also works for 
> cross-compiles.

ldd not only provides the name of the libraries to be loaded, but also
the paths to the locations where they are loaded from. How would I get
this information without using ldd?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Should QVariant be doing fuzzy comparisons on doubles?

[Marc Mutz]

On Wednesday 21 September 2016 09:23:35 Mathias Hasselmann wrote:
> Maybe some clever use of type traits can tell us if your structs contain 
> alignment wholes?

-Werror=padded :)

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Should QVariant be doing fuzzy comparisons on doubles?

[Mathias Hasselmann]

Am 21.09.2016 um 08:57 schrieb Olivier Goffart:

On Mittwoch, 21. September 2016 08:01:22 CEST Mathias Hasselmann wrote:

As much as I'd like to debug this code now to prove me right, I sadly
have deadlines to meet this week. So I have to behave myself to not dig
up the code right now. Maybe later. Or someone else.


Turns out you are right. If there is no registered comparison function, we do
a memcmp in 'customCompare' in qvariant.cpp:
https://code.woboq.org/qt5/qtbase/src/corelib/kernel/qvariant.cpp.html#1079

That is indeed an undefined behavior!


Cool. Or rather not. Anyway: Thank you for looking this up!


It is easy to forget registering comparator functions and currently Qt
doesn't help in debugging such issues. So I wonder if QVariant should
forbid comparison of custom types without having a comparator function
registered.


That's a source incompatible change.


No, it's not. It's changing undefined behavior into defined behavior.


But in many case, we want to put something in a QVariant, and we never compare
this variant.
Forbidding types that do not have an operator== to be in a QVariant might be
to strict.


I fear balance has changed dramatically since we switched from 32 bit to 
64 bit. In the old 32 bit days our structs tended to be densely packed 
with our enums and ints. Many structs were well defined as they 
contained no padding wholes. Memcmp was working. World was good.


These days with compilers often defaulting to sizeof(int) == 4 while 
using a memory alignment of 8 we usually end up with horrible 
inefficient, very sparse structs where often half of the bytes are 
undefined. Actually the compiler gurus' decision to use stay with 32 
bits for ints feels slightly stupid now that I think about it: No 
improvement in memory efficiency, but lots of undefined behavior.


Maybe some clever use of type traits can tell us if your structs contain 
alignment wholes?


Ciao,
Mathias
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt5 Bearer: broken PPP support

[Alexander Smirnov]

Hi Thiago,


On terça-feira, 20 de setembro de 2016 22:48:42 PDT Alexander Smirnov wrote:

After debugging I figured out, that the problem is in commit:

043f5d3eb52587831f643bc52c95079c36d984c7

This commit allows to add to list:

QList interfaces;

interfaces with no address field (ifa_addr == NULL).

Then, I've checked the output from 'getifaddrs()' syscall on my board,
and it returns 2! instances of ppp0:

   - one with AF_INET family
   - one with ifa_addr == NULL

[cut]

So, is it a bug? :-)


Probably. Can you give me a full dump of what getifaddrs gave you along with

ip -d link show dev ppp0
ip -d addr show dev ppp0



So, I've attached the following:

[ifconfig.log] - output from 'ifconfig -a'

[getifaddrs.c] - test app to show getifaddrs() output, derived from man 
page, but fixed to not to skip null addresses


[getifaddrs.log] - output from test app

[ip.log] - output from ip command as you requested

NOTE: I've also observed the same behavior for tun devices.

ppp0 interface is created by typical Linux pppd daemon.
tun2 interface is created by openvpn.


I'll fix it.



Please let me know, if you need additional information.

--
With best regards,
Alexander Smirnov

ilbers GmbH
Baierbrunner Str. 28c
D-81379 München
+49 (89) 122 67 24-0
http://ilbers.de/
Commercial register Munich, HRB 214197
General manager: Baurzhan Ismagulov
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main(int argc, char** argv)
{
struct ifaddrs *ifaddr, *ifa;
int family, s;
char host[NI_MAXHOST];

if (getifaddrs() == -1) {
perror("getifaddrs");
exit(EXIT_FAILURE);
}

/* Walk through linked list, maintaining head pointer so we
 * can free list later
 */
for (ifa = ifaddr; ifa != NULL; ifa = ifa->ifa_next) {
if (ifa->ifa_addr == NULL) {
printf("%s \taddress: NULL\n", ifa->ifa_name);
continue;
}

family = ifa->ifa_addr->sa_family;

/* Display interface name and family (including symbolic
 * form of the latter for the common families)
 */
printf("%s \tfamily: %d%s\n",
   ifa->ifa_name, family,
   (family == AF_PACKET) ? " (AF_PACKET)" :
   (family == AF_INET) ?   " (AF_INET)" :
   (family == AF_INET6) ?  " (AF_INET6)" : "");

/* For an AF_INET* interface address, display the address */

if (family == AF_INET || family == AF_INET6) {
s = getnameinfo(ifa->ifa_addr,
(family == AF_INET) ? sizeof(struct sockaddr_in) :
sizeof(struct sockaddr_in6),
host, NI_MAXHOST, NULL, 0, NI_NUMERICHOST);
if (s != 0) {
printf("getnameinfo() failed: %s\n", gai_strerror(s));
exit(EXIT_FAILURE);
}

printf("\taddress: <%s>\n", host);
}
}

freeifaddrs(ifaddr);
exit(EXIT_SUCCESS);
}
# getifaddrs
 
lo  family: 17 (AF_PACKET)
can0address: NULL
eth0family: 17 (AF_PACKET)
wlan0   family: 17 (AF_PACKET)
sit0family: 17 (AF_PACKET)
ppp0address: NULL
tun2address: NULL
lo  family: 2 (AF_INET)
address: <127.0.0.1>
eth0family: 2 (AF_INET)
address: <192.168.178.110>
ppp0family: 2 (AF_INET)
address: <10.142.173.66>
tun2family: 2 (AF_INET)
address: <10.0.0.1>
lo  family: 10 (AF_INET6)
address: <::1>
eth0family: 10 (AF_INET6)
address: 
# ifconfig -a
can0  Link encap:UNSPEC  HWaddr 
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
  NOARP  MTU:16  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:10 
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
  Interrupt:30 

eth0  Link encap:Ethernet  HWaddr 00:01:C0:19:6C:24  
  inet addr:192.168.178.110  Bcast:192.168.178.255  Mask:255.255.255.0
  inet6 addr: fe80::201:c0ff:fe19:6c24%1996412624/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:361871 errors:9529 dropped:60 overruns:9529 frame:9529
  TX packets:169960 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:511238273 (487.5 MiB)  TX bytes:11817634 (11.2 MiB)

loLink encap:Local Loopback  
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1%1996412624/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:65536  Metric:1
  RX packets:8 errors:0 dropped:0 overruns:0 frame:0
  TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0 
  RX bytes:512 (512.0 B)  TX bytes:512 (512.0 B)

ppp0  Link encap:Point-to-Point Protocol  
  inet addr:10.142.173.66  P-t-P:10.142.173.66  

Re: [Development] Should QVariant be doing fuzzy comparisons on doubles?

[Olivier Goffart]

On Mittwoch, 21. September 2016 08:01:22 CEST Mathias Hasselmann wrote:
> Am 20.09.2016 um 12:44 schrieb Olivier Goffart:
> > On Dienstag, 20. September 2016 12:21:11 CEST Mathias Hasselmann wrote:
> >> Am 19.09.2016 um 23:27 schrieb Olivier Goffart:
> >>> We really cannot have a qHash for QVariant anyway, because that would
> >>> imply
> >>> that ALL QVariant can be hashed, and compared. Which is not the case.
> >>> Most
> >>> custom types don't even register comparator function.
> >> 
> >> Which actually is quite a serious issue, as we do a simply memcmp() on
> >> such custom types, which simply won't work if your custom data structure
> >> contains uninitialized memory from alignment padding.
> > 
> > We don't do that. We just return false in that case.
> 
> Valgrind is telling a different story. It blames uninitialized memory
> access via memcpy() when comparing custom types without registered
> compare operator. Those types are gadgets, maybe that's making the
> difference.
> 
> As much as I'd like to debug this code now to prove me right, I sadly
> have deadlines to meet this week. So I have to behave myself to not dig
> up the code right now. Maybe later. Or someone else.

Turns out you are right. If there is no registered comparison function, we do 
a memcmp in 'customCompare' in qvariant.cpp:
https://code.woboq.org/qt5/qtbase/src/corelib/kernel/qvariant.cpp.html#1079

That is indeed an undefined behavior!

> 
> >> It is easy to forget registering comparator functions and currently Qt
> >> doesn't help in debugging such issues. So I wonder if QVariant should
> >> forbid comparison of custom types without having a comparator function
> >> registered.
> > 
> > That's a source incompatible change.
> 
> No, it's not. It's changing undefined behavior into defined behavior.

But in many case, we want to put something in a QVariant, and we never compare 
this variant. 
Forbidding types that do not have an operator== to be in a QVariant might be 
to strict.


-- 
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Should QVariant be doing fuzzy comparisons on doubles?

[Mathias Hasselmann]

Am 20.09.2016 um 12:44 schrieb Olivier Goffart:

On Dienstag, 20. September 2016 12:21:11 CEST Mathias Hasselmann wrote:

Am 19.09.2016 um 23:27 schrieb Olivier Goffart:

We really cannot have a qHash for QVariant anyway, because that would
imply
that ALL QVariant can be hashed, and compared. Which is not the case. Most
custom types don't even register comparator function.


Which actually is quite a serious issue, as we do a simply memcmp() on
such custom types, which simply won't work if your custom data structure
contains uninitialized memory from alignment padding.


We don't do that. We just return false in that case.


Valgrind is telling a different story. It blames uninitialized memory 
access via memcpy() when comparing custom types without registered 
compare operator. Those types are gadgets, maybe that's making the 
difference.


As much as I'd like to debug this code now to prove me right, I sadly 
have deadlines to meet this week. So I have to behave myself to not dig 
up the code right now. Maybe later. Or someone else.



It is easy to forget registering comparator functions and currently Qt
doesn't help in debugging such issues. So I wonder if QVariant should
forbid comparison of custom types without having a comparator function
registered.


That's a source incompatible change.


No, it's not. It's changing undefined behavior into defined behavior.

Ciao,
Mathias
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development