There is a warning in the OS X part of the build instructions (OS X builds with clang) not to do a parallel build (-J > 1) due to competing dependencies.
Send Interest mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.qt-project.org/mailman/listinfo/interest
or, via email, send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Interest digest..."
4. Re: Chasing a standard (Jason H)
5. Re: update on building Qt/Linux with clang?
(Allan Sandfeld Jensen)
6. Re: update on building Qt/Linux with clang?
(Allan Sandfeld Jensen)
7. Re: update on building Qt/Linux with clang?
(Jean-Micha?l Celerier)
9. Re: update on building Qt/Linux with clang?
10. Re: Chasing a standard (J?r?me Godbout)
12. Re: Chasing a standard (J?r?me Godbout)
13. Re: Qt 5.12 Beta 3 slows down ext Javascript library (RSA
encrypt) (Thiago Macieira)
14. Re: update on building Qt/Linux with clang? (Thiago Macieira)
15. Re: Interest Digest, Vol 86, Issue 5 (Giuseppe D'Angelo)
16. Re: update on building Qt/Linux with clang? (Ren? J.V. Bertin)
17. Re: Qt 5.12 Beta 3 slows down ext Javascript library (RSA
encrypt) (ekke)
Subject: Re: [Interest] Chasing a standard
Date: November 5, 2018 at 9:39:38 AM EST
We already lose droves of Qt developers every year when Qt keeps moving on but medical devices, border security systems like cargo x-ray, train control systems, etc. have to fork their own version of Qt because Qt keeps moving on without a 5-8 year LTS.
Yes, the Open source and standard commercial versions come with a maximum of 3 years for LTS releases. But you can get longer support for Qt versions from The Qt Company though.
Three years isn't a drop of water in Lake Michigan. A completely new
surgical robot will take a minimum of 4 years design and prototyping
followed by 1-3 years of development (which must also include the
_entire_ manufacturing process for certification.) Then it goes through
clinical trials which can last upwards of 7 years. Once released to the
field it will be in maintenance/minor enhancement mode for 10 years or
more. This entire time the tool set must be locked down.
Since the tool is locked down, then it does not matter if Qt has moved
on or not, right? You're not allowed to upgrade/ change it anyway, you
have to stick to what you deployed. So there is no reason to complain
about lack of support here. That's the reality of such big and long
term projects. NASA also still keeps operational their computers from
1970 to handle Voyager missions. It does not mean that the
manufacturers of these PC are somehow obligated to support them
anymore.
This would be a gross missunderstanding of how the FDA "lockdown" is actually applied. Minor bug fixes can have documentation generated via an FDA approved process with dramatically reduced testing cycle since it is mostly negative testing. (Negative testing being testing no changes to other existing functionality.) The definition of "minor" is totally within the purview of the FDA and argued case by case.
As far as manufacturers and obligations, see below.
Just this year a drug manufacturer in California fielded a job opening
looking for a PDP-11 systems manager familiar with hardware maintenance.
Some of you may recall that a PDP-11 was the machine C and UNIX were
developed on in the 1970s. It was _the_ midrange computer of its day but
hasn't been manufactured since the late 1980s.
And you bring this up because PDP-11 is still supported by its
(non-existing by since 20 years) manufacturer just like Qt should?
There are quite a few places still providing support for the PDP-11 line. Quite a few companies stock piled 11/24 and 11/44 machines as others moved to VAX, ALPHA, and ITANIUM. Ownership of the line moved from DEC to Compaq to HP.
Shortly after Compaq consumed Digital Equipment Corporation, Microsoft paid them a bunch of money to announce the death of OpenVMS in a bid to get feeble Windows servers running on Compaq PCs into data centers where they were previously barred. Some corporations started to make the move. The NSA and DOD paid Compaq a Microsoft a visit. They showed them the sales and support contracts making cessation of the platform an act of treason and informed the leaders of both companies just how lengthy their prison time would be. You see, Bill Gates could bribe Bill and Hillary Clinton to make the Janet Reno investigation go in a "don't put Bill in prison for wire and mail fraud" direction, but the DOD and NSA weren't smiling and given their budgets, no interested in any bribe either company could offer.
Compaq then announced they weren't killing off OpenVMS and Bill Gates stepped out of the go-to-prison hot seat as part of the apology. The other details I do not know. I do know there was much more than that involved.
NASA had, and probably still has similar contracts.
These long term support contracts are why we have $12 wooden pencils and $800 hammers. That __EXACT__ product has to remain available and replacable for many many decades. Even if every tree of that type dies on the planet, the vendor who signed the contract must still find a way to make that __EXACT__ pencil with that __EXACT__ wood and other components. There is still a vendor prodiving 8 inch floppies to the DOD because they are used to boot the nuclear missile launch systems. Given the short life of floppies, they aren' surviving on a eBay stockpile. They are actually making them every so often.
If Qt wishes to play in the embedded world, it has to come to grips with this reality. It's not a "chase the latest idiot phone trend" world. This is why you are starting to see various companies who would otherwise consider each other competitors banding together to maintain the now abandoned Qt releases. Most every year or at least every other year I get emails and calls about doing Qt 3 work on OS/2 from this Harman (sp?) consulting firm. Minor changes to an existing medical device whose systems were built using those tools.
One of my past clients had almost nothing to do with the DOD post WW-II, but, they still have all of the equipment to make torpedos for said boats and ships. They must keep it on site in good condition until the contract ends. I've been told that contract doesn't end until the last vessel of war capabile of firing said munitions is scuttled. I have not personally seen the contract, nor do I wish to. You will find every major manufacturer which existed during WW-II has a similar contract for something else. These contracts don't expire until the DOD deems what they manufactured non-strategic and disposes of it.
--
Roland Hughes, President
Logikal Solutions
(630) 205-1593
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us
Subject: Re: [Interest] Chasing a standard
Date: November 5, 2018 at 9:42:36 AM EST
As I said a couple of times, we do not intend to break APIs in any major
way when moving towards Qt 6. That also implies that our container API is
there to stay. But where we can streamline/align with standard C++ in good
ways, we probably should try to do that.
It's not only about breaking APIs but also breaking current observable
behaviour - i.e. performance. Currently if you're passing data across
threads - e.g. compute something in a thread and pass the result to the
main thread to display it - you generally pass a QVector / QList /
QWhatever that does implicit sharing, because the signal-slot mechanism
will do a copy of the object in any case across threads and doing two
atomic operations for a QVector copy is cheaper than creating a new
std::vector, calling malloc, and copying 500 ints however you look at it.
What is the option if Qt opts out from this ? put everything in shared_ptr
?
Very good catch.
Battery powered embedded systems in the medical and industrial world have wretched dynamic memory allocation. If the underlying implementation does away with shallow/no-copy passing between threads for some std:: version which requires giahugic (given 512 MEG total working RAM) data sets with sluggish allocation (if enough memory exists at all) this is an extreme price.
--
Roland Hughes, President
Logikal Solutions
(630) 205-1593
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us
Subject: Re: [Interest] Interest Digest, Vol 86, Issue 5
Date: November 5, 2018 at 10:07:04 AM EST
====
Hold on -- I don't think that anyone wants to make Qt containers NOT
implictly shared. In other words, Qt 6 containers will be implictly
shared just as today. It would be a gigantic break if we suddenly made
them not shared.
====
Well, there have been others on this list making statements about Qt no longer investing effort to do things std:: already does. I myself earlier this year was involved with an exchange where someone was telling people to use std::vector becase QVector was deprecated going forward.
That definitely would be a gigantic break.
Switching the containers to just be wrappers around std:: implementations would also be a dramatic break.
--
Roland Hughes, President
Logikal Solutions
(630) 205-1593
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us
Subject: Re: [Interest] Chasing a standard
Date: November 5, 2018 at 10:13:00 AM EST
Sent: Monday, November 05, 2018 at 9:42 AM
Subject: Re: [Interest] Chasing a standard
As I said a couple of times, we do not intend to break APIs in any major
way when moving towards Qt 6. That also implies that our container API is
there to stay. But where we can streamline/align with standard C++ in good
ways, we probably should try to do that.
It's not only about breaking APIs but also breaking current observable
behaviour - i.e. performance. Currently if you're passing data across
threads - e.g. compute something in a thread and pass the result to the
main thread to display it - you generally pass a QVector / QList /
QWhatever that does implicit sharing, because the signal-slot mechanism
will do a copy of the object in any case across threads and doing two
atomic operations for a QVector copy is cheaper than creating a new
std::vector, calling malloc, and copying 500 ints however you look at it.
What is the option if Qt opts out from this ? put everything in shared_ptr
?
Very good catch.
Battery powered embedded systems in the medical and industrial world
have wretched dynamic memory allocation. If the underlying
implementation does away with shallow/no-copy passing between threads
for some std:: version which requires giahugic (given 512 MEG total
working RAM) data sets with sluggish allocation (if enough memory
exists at all) this is an extreme price.
Medical and Space-based systems should use the NASA (JPL) coding standard. Chief of which is no dynamic memory after initialization. So all your container arguments are moot.
( https://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf ) (Unless of course you're using mysmic memory after initialization in a medical device (But then, WHY!?))
I've also attributed failures on long-running commodity hardware (RaspberryPis) to the memory fragmentation issue of dynamic memory. Interestingly, this is why other languages (C#, Java) have dynamic memory consolidation capability (i.e. Mark & Sweep, "Handles" (^) in the .NET C++ CLR). But as the JPL standard shows, you do not need to create non-deterministic garbage collection in your language. While I attributed this to failures on a Pi, I have actually researched and concluded that this indeed was the case on an embedded application on a PPC 860. Removing dynamic memory and reverting to fixed-arrays eliminated the crashes after months of run-time. Unfortunately this is nearly impossible on a Pi with it's much larger software ecosystem.
Subject: Re: [Interest] update on building Qt/Linux with clang?
Date: November 5, 2018 at 10:34:31 AM EST
Hi,
Last time I asked the advice was still not to bother with trying to build
(all of) Qt with clang on Linux. Is that still the case or is it now safe
to use clang (5 or 6)?
In my experience clang generates significantly more compact binaries, which
should reduce load times. Build time should be shorter too.
I build all of Qt regularly with clang to make sure qtwebengine works like
that, and I have never had any issues. You can even use clang-libc++ if you
make sure not to depend on any system C++ libraries.
'Allan
Subject: Re: [Interest] update on building Qt/Linux with clang?
Date: November 5, 2018 at 10:38:04 AM EST
I tried building everything with clang 7 and libc++ last week but hit a
qlalr segfault during build. I've been trying to debug it ever since to no
avail.
clang sometimes segfaults while compiling, the crash usually goes if I try
again. It seems to just randomly crash once for every ~10 thousand files
compiled for no reason. The fact the crashes are random and not stable doesn't
really raise my confidence in clang code quality though, but it is easy to
work around. Just keep calling make until it makes it.
'Allan
Subject: Re: [Interest] update on building Qt/Linux with clang?
Date: November 5, 2018 at 10:50:10 AM EST
clang sometimes segfaults while compiling, the crash usually goes if I try
again.
- when building in debug
- when building statically
it's just the release / dynamic configuration that crashes, and I don't know how to instruct Qt's configure to keep debug symbols for release builds of the tools in order to get a proper stacktrace.
I tried building everything with clang 7 and libc++ last week but hit a
qlalr segfault during build. I've been trying to debug it ever since to no
avail.
clang sometimes segfaults while compiling, the crash usually goes if I try
again. It seems to just randomly crash once for every ~10 thousand files
compiled for no reason. The fact the crashes are random and not stable doesn't
really raise my confidence in clang code quality though, but it is easy to
work around. Just keep calling make until it makes it.
'Allan
Subject: Re: [Interest] Chasing a standard
Date: November 5, 2018 at 10:54:36 AM EST
Very good catch.
Battery powered embedded systems in the medical and industrial world
have wretched dynamic memory allocation. If the underlying
implementation does away with shallow/no-copy passing between threads
for some std:: version which requires giahugic (given 512 MEG total
working RAM) data sets with sluggish allocation (if enough memory
exists at all) this is an extreme price.
Medical and Space-based systems should use the NASA (JPL) coding standard. Chief of which is no dynamic memory after initialization. So all your container arguments are moot.
( https://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf ) (Unless of course you're using mysmic memory after initialization in a medical device (But then, WHY!?))
I've never worked on a single medical device which utilized JPL. Not one. Not saying there isn't one somewhere in the world, but, I've never seen it. One could not use Qt in a medical device if strictly adhering to JPL. Something simple like an error message to syslog being built with a QString would violate such a standard. You couldn't fill in the values with .arg().
No, the container issue in medical device world isn't moot. It's a clear and present danger.
--
Roland Hughes, President
Logikal Solutions
(630) 205-1593
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us
Subject: Re: [Interest] update on building Qt/Linux with clang?
Date: November 5, 2018 at 10:58:14 AM EST
I tried building everything with clang 7 and libc++ last week but hit a
qlalr segfault during build. I've been trying to debug it ever since to no
avail.
clang sometimes segfaults while compiling, the crash usually goes if I try
again. It seems to just randomly crash once for every ~10 thousand files
compiled for no reason.
Sounds like a job for valgrind.
The fact the crashes are random and not stable doesn't
really raise my confidence in clang code quality though, but it is easy to
work around. Just keep calling make until it makes it.
'Allan
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
Subject: Re: [Interest] Chasing a standard
Date: November 5, 2018 at 11:07:36 AM EST
I did a few medical application for orthopedic surgery, the coding standard is not a requirement, but only a simplest way to validate your software. I did used Qt into all of them and we manage to certify them for surgery room. It always depend on the level or risk your software lies on. Also if you can proof your software is robust enough (yeah it take a lot of testing and safe guard everywhere) you can pass the certification. JPL only make it easier to pass those since you proof in a easy way that it cannot goes wrong, that's about it.
JPL would be a good thing if you were to make a peacemaker for example. It's more for embedded C software where dynamic alloc is not allowed (just like car industries). If you plan on running C++ on a MCU with very limited resource, you are looking for trouble (it's doable, but the tests time will inflate more then what you will save from C to C++) and will need to take very much great care of the object you create and destroy. In other word, it's a bad idea, stick to C for embedded or critical component.
-----Original Message-----
Sent: November 5, 2018 10:55 AM
Subject: Re: [Interest] Chasing a standard
Very good catch.
Battery powered embedded systems in the medical and industrial world
have wretched dynamic memory allocation. If the underlying
implementation does away with shallow/no-copy passing between threads
for some std:: version which requires giahugic (given 512 MEG total
working RAM) data sets with sluggish allocation (if enough memory
exists at all) this is an extreme price.
Medical and Space-based systems should use the NASA (JPL) coding
standard. Chief of which is no dynamic memory after initialization.
So all your container arguments are moot.
( https://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf ) (Unless of
course you're using mysmic memory after initialization in a medical
device (But then, WHY!?))
I've never worked on a single medical device which utilized JPL. Not one. Not saying there isn't one somewhere in the world, but, I've never seen it. One could not use Qt in a medical device if strictly adhering to JPL. Something simple like an error message to syslog being built with a QString would violate such a standard. You couldn't fill in the values with .arg().
No, the container issue in medical device world isn't moot. It's a clear and present danger.
--
Roland Hughes, President
Logikal Solutions
(630) 205-1593
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
Subject: Re: [Interest] Chasing a standard
Date: November 5, 2018 at 11:29:54 AM EST
JPL would be a good thing if you were to make a peacemaker for example. It's more for embedded C software where dynamic alloc is not allowed (just like car industries). If you plan on running C++ on a
Stupid question, but if dynamic memory allocation is not allowed in the automotive industry, how is it Ford is constantly looking for low wage Qt developers? More a curiosity than anything else. Those contracts pay less than 1/3 of my standard billing rate so the emails and phone calls about them land in the virtual bit bucket.
--
Roland Hughes, President
Logikal Solutions
(630) 205-1593
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us
Subject: Re: [Interest] Chasing a standard
Date: November 5, 2018 at 11:43:44 AM EST
Qt is probably only used into a part of the Dashboard or entertainment system, the controller chip or embedded MCU and other safety controller are probably not using Qt nor C++. They follow some MISRA, AUTOSAR, CERT standard. They have a C++ standard, but seriously it prevent a good chunk of the language usage. Like in the medical, it always on which system critical part your software going to run, the radio with BLE phone that crash is one thing, the wheel control is another matter. If you don't follow those standard (which is possible), the burden of the proof of reliability false on you and you have to prove how your software can NEVER be a life threat.
-----Original Message-----
Sent: November 5, 2018 11:30 AM
Subject: Re: [Interest] Chasing a standard
JPL would be a good thing if you were to make a peacemaker for
example. It's more for embedded C software where dynamic alloc is
not allowed (just like car industries). If you plan on running C++
on a
Stupid question, but if dynamic memory allocation is not allowed in
the automotive industry, how is it Ford is constantly looking for low
wage Qt developers? More a curiosity than anything else. Those
contracts pay less than 1/3 of my standard billing rate so the emails
and phone calls about them land in the virtual bit bucket.
--
Roland Hughes, President
Logikal Solutions
(630) 205-1593
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us
Subject: Re: [Interest] Qt 5.12 Beta 3 slows down ext Javascript library (RSA encrypt)
Date: November 5, 2018 at 11:59:46 AM EST
created a example app and now noticed, the app doesn't freeze,
but the exection of encrypt() slows down from
5 sec (Qt 5.11.2) to
92 sec (Qt 5.12 Beta3)
will open a bug report
How about you encrypt using C++ instead? OpenSSL probably has the encryption
you need.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Subject: Re: [Interest] update on building Qt/Linux with clang?
Date: November 5, 2018 at 12:01:31 PM EST
it's just the release / dynamic configuration that crashes, and I don't
know how to instruct Qt's configure to keep debug symbols for release
builds of the tools in order to get a proper stacktrace.
Edit the Makefile after generation and add -g to the CXXFLAGS of the relevant
builds.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Subject: Re: [Interest] Interest Digest, Vol 86, Issue 5
Date: November 5, 2018 at 12:21:02 PM EST
Hi,
implementations would also be a dramatic break.
Assuming by "wrappers" you mean "implicitly shared wrappers", why would it be a break?
Cheers,
--
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
Subject: Re: [Interest] update on building Qt/Linux with clang?
Date: November 5, 2018 at 12:55:21 PM EST
it's just the release / dynamic configuration that crashes, and I don't
know how to instruct Qt's configure to keep debug symbols for release
builds of the tools in order to get a proper stacktrace.
I use these arguments to configure: -no-strip -no-separate-debug-info --force-debug-info
Or skip the last, and just run `qmake -config force_debug_info /path/to/qtcomponent/qtcomponent.pro` in the build directory for the component(s) you want to have debug info for (useful if you only want it in qtbase).
Clang apparently also wants -fno-limit-debug-info if you really want to have useful debug info (though I can't tell if it really makes a difference).
clang sometimes segfaults while compiling, the crash usually goes if I try
again. It seems to just randomly crash once for every ~10 thousand files
compiled for no reason. The fact the crashes are random and not stable
doesn't
really raise my confidence in clang code quality though, but it is easy to
work around. Just keep calling make until it makes it.
My build with clang just completed fine, of all components except qt3d, qtwebengine and qtwebview. I've not seen clang crash when compiling Qt code on Mac for a long time, but there it uses a fully native libc++ which may make a difference.
I'd expect your build machine is probably much more powerful than mine, but what if those random crashes are due to some sort of resource depletion or contention? That's really the only thing that makes some kind of sense... and I'm almost certain I've already seen MacPorts ports that are built in non-parallel fashion because clang crashes otherwise.
R.
Subject: Re: [Interest] Qt 5.12 Beta 3 slows down ext Javascript library (RSA encrypt)
Date: November 5, 2018 at 2:32:03 PM EST
created a example app and now noticed, the app doesn't freeze,
but the exection of encrypt() slows down from
5 sec (Qt 5.11.2) to
92 sec (Qt 5.12 Beta3)
will open a bug report
How about you encrypt using C++ instead? OpenSSL probably has the encryption
you need.
Thanks, Thiago for the hint - that was the first thing I tried, but
couldn't figure out HowTo make it work on Android and iOS.
It's only used when password has changed and must be entered: then
password must be RSA encrypted and base64 sent to server
so I was happy to find a JS solution which was implemented easy for
function doEncrypt() {
var rsa = new MyRsa.RSAKey();
rsa.setPublic(dataServer.modulusHex(), "10001")
var res = rsa.encrypt(pwText.text)
if(res) {
return MyRsa.linebrk(res, 64)
} else {
return ""
}
}
unfortunately now with 5.12 Beta it slows down by 20x.
on Android per ex. from 80 ms to 1700 ms (acceptable for my customer)
but iOS now is too slow
ekke
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest