Discussion:
update on building Qt/Linux with clang?
(too old to reply)
René J.V. Bertin
2018-11-05 11:03:31 UTC
Permalink
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.

Thanks,
R.
Jean-Michaël Celerier
2018-11-05 11:10:15 UTC
Permalink
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.


Best,
-------
Jean-Michaël Celerier
http://www.jcelerier.name
Post by René J.V. Bertin
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.
Thanks,
R.
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
René J.V. Bertin
2018-11-05 11:36:41 UTC
Permalink
Post by Jean-Michaël Celerier
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.
Building with libc++ and the very latest Clang may just have been a bridge too far ;) I do build a number of KDE apps and QMPlay2 that way though, against a regular libstdc++ most-everything-else, and that works just fine despite premonitions about mixing C++ runtimes.

I'm going to try with Clang 6 myself (because WTH :)), but I did run an initial configure with GCC 8 before reconfiguring with clang. That way the build tools are still built with the known-to-work toolchain.

R
Allan Sandfeld Jensen
2018-11-05 15:38:04 UTC
Permalink
Post by Jean-Michaël Celerier
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
Jean-Michaël Celerier
2018-11-05 15:50:10 UTC
Permalink
Post by Allan Sandfeld Jensen
clang sometimes segfaults while compiling, the crash usually goes if I try
again.

in my case it's not clang which crashes but the qlalr that clang produces.
For some reason it works :
- 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.
Post by Allan Sandfeld Jensen
Post by Jean-Michaël Celerier
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
Post by Jean-Michaël Celerier
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
Thiago Macieira
2018-11-05 17:01:31 UTC
Permalink
Post by Jean-Michaël Celerier
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
René J.V. Bertin
2018-11-05 17:55:21 UTC
Permalink
Post by Jean-Michaël Celerier
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).
Post by Jean-Michaël Celerier
Post by Allan Sandfeld Jensen
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.
w***@analog.com
2018-11-05 15:58:14 UTC
Permalink
Post by Allan Sandfeld Jensen
Post by Jean-Michaël Celerier
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.
Post by Allan Sandfeld Jensen
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
Allan Sandfeld Jensen
2018-11-05 15:34:31 UTC
Permalink
Post by René J.V. Bertin
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
René J.V. Bertin
2018-11-06 08:40:04 UTC
Permalink
Post by Allan Sandfeld Jensen
I build all of Qt regularly with clang to make sure qtwebengine works like
that
Have you tried 5.9.x recently? I ran into an issue that appears to be known (and fixed upstream) where gn fails to link because of missing __atomic_bool_is_lock_free symbols. The fix is to link with -latomic on Linux and Android. I just linked the executable manually (copy/paste, add -latomic) and relaunched the QWE build. That was yesterday evening late, this morning the thing was still building.

R
René J.V. Bertin
2018-11-05 19:33:58 UTC
Permalink
Post by René J.V. Bertin
In my experience clang generates significantly more compact binaries
Quite: bzipped tarballs of everything except the examples, translations, QWE, QtWebView and Qt3D:

-rw-r--r-- 1 root root 363M Sep 8 13:22 qt5-kde-devel-5.9.6.linux_3.x86_64.tbz2 (1003Mb uncompressed tarball)
-rw-r--r-- 1 root root 199M Nov 5 19:22 qt5-kde-devel-5.9.7.linux_3.x86_64.tbz2 (710Mb uncompressed tarball)

The first built with GCC 8, the 2nd with clang 6.0; identical compiler options (release build, -O3, force_debug_info for qtbase).

R.
Allan Sandfeld Jensen
2018-11-05 19:53:05 UTC
Permalink
Post by René J.V. Bertin
Post by René J.V. Bertin
In my experience clang generates significantly more compact binaries
Quite: bzipped tarballs of everything except the examples, translations,
-rw-r--r-- 1 root root 363M Sep 8 13:22
qt5-kde-devel-5.9.6.linux_3.x86_64.tbz2 (1003Mb uncompressed tarball)
-rw-r--r-- 1 root root 199M Nov 5 19:22
qt5-kde-devel-5.9.7.linux_3.x86_64.tbz2 (710Mb uncompressed tarball)
The first built with GCC 8, the 2nd with clang 6.0; identical compiler
options (release build, -O3, force_debug_info for qtbase).
Enable -lto/ltcg if you want smaller binaries, and -optimize-size if you don't
mind losing a bit a performance for it.

Also enable -separate-debug-info. The executable results of the two compilers
are very identical in size, or is mainly the debug-info that varies so much in
size.

'Allan
Thiago Macieira
2018-11-05 20:30:38 UTC
Permalink
Post by René J.V. Bertin
Post by René J.V. Bertin
In my experience clang generates significantly more compact binaries
Quite: bzipped tarballs of everything except the examples, translations,
Off-topic: no one uses bzip2 anymore. It's slow to compress, slow to
decompress and produces worse results than xz.
Post by René J.V. Bertin
-rw-r--r-- 1 root root 363M Sep 8 13:22
qt5-kde-devel-5.9.6.linux_3.x86_64.tbz2 (1003Mb uncompressed tarball)
-rw-r--r-- 1 root root 199M Nov 5 19:22
qt5-kde-devel-5.9.7.linux_3.x86_64.tbz2 (710Mb uncompressed tarball)
The first built with GCC 8, the 2nd with clang 6.0; identical compiler
options (release build, -O3, force_debug_info for qtbase).
Please compare debug-stripped binaries.

text data bss dec hex filename
7205857 200632 1714 7408203 710a4b lib/libQt5Widgets.so
6727027 197920 1576 6926523 69b0bb clang/libQt5Widgets.so

Both are -O3 -march=native -g1 builds. So yes, the Clang build is smaller, but
not significantly so. And since -O3 means "aggressively optimise, even if it
takes longer to compile or increases the size considerably", you don't really
care about size. Bigger code could indicate more optimisations applied (loop
unrolling, vectorisation).

Anyway, compare the debug sections of the two:

GCC:
Section Headers:
[Nr] Name Type Off Size ES Flags Lk Inf Al
[29] .debug_line PROGBITS 00710a80 002c360b 0 0 0 1
[30] .debug_info PROGBITS 009d408b 00567018 0 0 0 1
[31] .debug_abbrev PROGBITS 00f3b0a3 0002813a 0 0 0 1
[32] .debug_aranges PROGBITS 00f631e0 0000fd70 0 0 0 16
[33] .debug_str PROGBITS 00f72f50 001f84b5 1 MS 0 0 1
[34] .debug_ranges PROGBITS 0116b410 002f3a20 0 0 0 16

Clang:
[28] .debug_aranges PROGBITS 0069c0a0 00000080 0 0 0 16
[29] .debug_info PROGBITS 0069c120 004b52fc 0 0 0 1
[30] .debug_abbrev PROGBITS 00b5141c 00006dea 0 0 0 1
[31] .debug_line PROGBITS 00b58206 0032d586 0 0 0 1
[32] .debug_str PROGBITS 00e8578c 000377fb 1 MS 0 0 1
[33] .debug_macinfo PROGBITS 00ebcf87 000000b6 0 0 0 1
[34] .debug_ranges PROGBITS 00ebd040 00135ff0 0 0 0 16

Clang carries 9793421 bytes of debug information, while GCC produces 13951906.
That's a much bigger difference.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
René J. V. Bertin
2018-11-06 22:09:14 UTC
Permalink
Post by Thiago Macieira
Off-topic: no one uses bzip2 anymore. It's slow to compress, slow to
decompress and produces worse results than xz.
Xz is even slower, and on the machine these numbers came from that difference is
more important in this case.
Post by Thiago Macieira
Both are -O3 -march=native -g1 builds. So yes, the Clang build is smaller, but
not significantly so.
You know that significant is not a synonym for considerable, right? ;)
Post by Thiago Macieira
takes longer to compile or increases the size considerably", you don't really
care about size.
Off-topic, but if I can get the same performance with a smaller size, why opt
for the larger size?
Post by Thiago Macieira
Clang carries 9793421 bytes of debug information, while GCC produces 13951906.
That's a much bigger difference.
I know; most of my builds do have debug info so this is important to me.
I should look into using separate debug info sometime, but not if it gives
something comparable to the .dSYM folders that tend to litter my directories. I
hate that for some reason.

R
Thiago Macieira
2018-11-06 23:02:10 UTC
Permalink
Post by René J. V. Bertin
Post by Thiago Macieira
Off-topic: no one uses bzip2 anymore. It's slow to compress, slow to
decompress and produces worse results than xz.
Xz is even slower, and on the machine these numbers came from that
difference is more important in this case.
Don't use -9 then. Try using something between -3 and -6. In a test locally
with a 250 MB source (I believe it was qtbase's .tar file), I got the
following results:

gzip -9: 60.2 MB @ 22.16s
bzip2 -9: 50.2 MB @ 25.26s
xz -2: 49.4 MB @ 34.28s
zstd -14: 49.0 MB @ 20.16s
zstd -19: 45.9 MB @ 52.36s
xz -6: 44.4 MB @ 99.19s
xz -9: 42.5 MB @ 98.28s

More importantly, the decompression times: gzip took 0.84s, zstd 0.30s and xz
2.81s. But bzip2 needed 6.6s.

I'm adding Zstandard as an alternative to Zlib in Qt:
https://codereview.qt-project.org/244431
https://codereview.qt-project.org/244432
Post by René J. V. Bertin
Post by Thiago Macieira
Both are -O3 -march=native -g1 builds. So yes, the Clang build is smaller,
but not significantly so.
You know that significant is not a synonym for considerable, right? ;)
I know. But:
negligible < significant < considerable

I'm claiming that the size is less than what you claim to be a problem.
Post by René J. V. Bertin
Post by Thiago Macieira
takes longer to compile or increases the size considerably", you don't
really care about size.
Off-topic, but if I can get the same performance with a smaller size, why
opt for the larger size?
Because you can't.
Post by René J. V. Bertin
Post by Thiago Macieira
Clang carries 9793421 bytes of debug information, while GCC produces
13951906. That's a much bigger difference.
I know; most of my builds do have debug info so this is important to me.
I should look into using separate debug info sometime, but not if it gives
something comparable to the .dSYM folders that tend to litter my
directories. I hate that for some reason.
That's why you should strip them out and compress them. Store them where you
may need them (possibly never).
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
René J. V. Bertin
2018-11-07 10:20:53 UTC
Permalink
Post by Thiago Macieira
More importantly, the decompression times: gzip took 0.84s, zstd 0.30s and xz
2.81s. But bzip2 needed 6.6s.
I cannot reproduce those relative performance figures on neither of my machines.
On a 95Mb directory I'm getting on my Mac (tar -c dir | $compressor $opts >
/dev/null):
xz -c6: 40.2s (100%)
xz -c6 --threads=4: 16.3s (362%)
bzip2 -9: 10.3s (100%)
pbzip2 -9: 5s (392%)

Similar relative figures on my much slower Linux machine.

Interestingly parallelisation incurs about a 50% overhead on Mac. Also, pxz/xz
--threads=N doesn't always give a performance gain, either because of the input
size I'm testing with, or because I'm compressing stdin. I don't really want to
spend more time figuring that out.
Post by Thiago Macieira
negligible < significant < considerable
Nope, something can be highly significant but perfectly negligible.
Post by Thiago Macieira
I'm claiming that the size is less than what you claim to be a problem.
Who said anything about problems? I'm talking about trade-offs.
Post by Thiago Macieira
That's why you should strip them out and compress them. Store them where you
may need them (possibly never).
I need to be able to get useful post-mortem backtraces, and typically don't want
to have to figure out which debug information to get back online and how. That's
part of the trade-off. On my faster/bigger system I build all of Qt with
embedded debug info, elsewhere I only add debug info to QtBase.

R.
Konstantin Tokarev
2018-11-07 02:03:52 UTC
Permalink
Post by René J. V. Bertin
 Off-topic: no one uses bzip2 anymore. It's slow to compress, slow to
 decompress and produces worse results than xz.
Xz is even slower, and on the machine these numbers came from that difference is
more important in this case.
Use pxz to utilize all cores when compressing
Post by René J. V. Bertin
 Both are -O3 -march=native -g1 builds. So yes, the Clang build is smaller, but
 not significantly so.
You know that significant is not a synonym for considerable, right? ;)
 takes longer to compile or increases the size considerably", you don't really
 care about size.
Off-topic, but if I can get the same performance with a smaller size, why opt
for the larger size?
 Clang carries 9793421 bytes of debug information, while GCC produces 13951906.
 That's a much bigger difference.
I know; most of my builds do have debug info so this is important to me.
I should look into using separate debug info sometime, but not if it gives
something comparable to the .dSYM folders that tend to litter my directories. I
hate that for some reason.
R
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
--
Regards,
Konstantin
Konstantin Tokarev
2018-11-07 02:05:43 UTC
Permalink
Post by Thiago Macieira
 >In my experience clang generates significantly more compact binaries
 Quite: bzipped tarballs of everything except the examples, translations,
Off-topic: no one uses bzip2 anymore. It's slow to compress, slow to
decompress and produces worse results than xz.
bzip2 still has one valid use case: it requires less memory for compression
Post by Thiago Macieira
 -rw-r--r-- 1 root root 363M Sep 8 13:22
 qt5-kde-devel-5.9.6.linux_3.x86_64.tbz2 (1003Mb uncompressed tarball)
 -rw-r--r-- 1 root root 199M Nov 5 19:22
 qt5-kde-devel-5.9.7.linux_3.x86_64.tbz2 (710Mb uncompressed tarball)
 The first built with GCC 8, the 2nd with clang 6.0; identical compiler
 options (release build, -O3, force_debug_info for qtbase).
Please compare debug-stripped binaries.
   text data bss dec hex filename
7205857 200632 1714 7408203 710a4b lib/libQt5Widgets.so
6727027 197920 1576 6926523 69b0bb clang/libQt5Widgets.so
Both are -O3 -march=native -g1 builds. So yes, the Clang build is smaller, but
not significantly so. And since -O3 means "aggressively optimise, even if it
takes longer to compile or increases the size considerably", you don't really
care about size. Bigger code could indicate more optimisations applied (loop
unrolling, vectorisation).
[Nr] Name Type Off Size ES Flags Lk Inf Al
[29] .debug_line PROGBITS 00710a80 002c360b 0 0 0 1
[30] .debug_info PROGBITS 009d408b 00567018 0 0 0 1
[31] .debug_abbrev PROGBITS 00f3b0a3 0002813a 0 0 0 1
[32] .debug_aranges PROGBITS 00f631e0 0000fd70 0 0 0 16
[33] .debug_str PROGBITS 00f72f50 001f84b5 1 MS 0 0 1
[34] .debug_ranges PROGBITS 0116b410 002f3a20 0 0 0 16
[28] .debug_aranges PROGBITS 0069c0a0 00000080 0 0 0 16
[29] .debug_info PROGBITS 0069c120 004b52fc 0 0 0 1
[30] .debug_abbrev PROGBITS 00b5141c 00006dea 0 0 0 1
[31] .debug_line PROGBITS 00b58206 0032d586 0 0 0 1
[32] .debug_str PROGBITS 00e8578c 000377fb 1 MS 0 0 1
[33] .debug_macinfo PROGBITS 00ebcf87 000000b6 0 0 0 1
[34] .debug_ranges PROGBITS 00ebd040 00135ff0 0 0 0 16
Clang carries 9793421 bytes of debug information, while GCC produces 13951906.
That's a much bigger difference.
--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
--
Regards,
Konstantin
Thiago Macieira
2018-11-07 07:17:52 UTC
Permalink
Post by Konstantin Tokarev
bzip2 still has one valid use case: it requires less memory for compression
Same test as the other email

gzip -9: 6272 kB RAM RSS
bzip2 -9: 8616 kB
xz -2: 113988 kB
zstd -14: 154684 kB
zstd -19: 198300 kB
xz -6: 517672 kB
xz -9: 691856 kB

So, yes, it does. But you usually do have enough RAM to use better
compression.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Colin Worth
2018-11-06 03:09:37 UTC
Permalink
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
Sérgio Martins
2018-11-07 11:13:29 UTC
Permalink
Post by René J.V. Bertin
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)?
Can you share a link to a LLVM or Qt bug report where you're expecting
improvements ? We can't discuss it without knowing which problems
we're addressing.

I only know of the LTO problem when building Qt with clang (closed as
WONTFIX in both Qt and Clang trackers IIRC)

Regards,
Sergio
René J.V. Bertin
2018-11-07 12:14:10 UTC
Permalink
Post by Sérgio Martins
Can you share a link to a LLVM or Qt bug report where you're expecting
improvements ?
It was on this mailing list.

I haven't tried with Qt but I manage to use -flto with clang on Linux by making sure a recent enough ld (and not the gold one) is used. On the whole I find that the performance and compactness gains don't justify the increased build time, though.

R
Sérgio Martins
2018-11-08 11:47:51 UTC
Permalink
Post by René J.V. Bertin
Post by Sérgio Martins
Can you share a link to a LLVM or Qt bug report where you're expecting
improvements ?
It was on this mailing list.
I haven't tried with Qt but I manage to use -flto with clang on Linux by making sure a recent enough ld (and not the gold one) is used. On the whole I find that the performance and compactness gains don't justify the increased build time, though.
FWIW, I just tried -flto with clang-7.0 and gold-1.16 and can't
reproduce QTBUG-43556 anymore.

Regards,
Sergio M.
René J. V. Bertin
2018-11-09 09:01:09 UTC
Permalink
Post by Sérgio Martins
FWIW, I just tried -flto with clang-7.0 and gold-1.16 and can't
reproduce QTBUG-43556 anymore.
Good to know, I use the "regular" ld v2.3.0 (~gold for other reasons I cannot
really remember).

In the FWIW register: does clang 7 continue the trend of being noticeably slower
that its predecessor (about 15% for clang 6)?

R.
Jean-Michaël Celerier
2018-11-29 14:28:39 UTC
Permalink
Here's my stacktrace (finally had some time to do a rebuild)

#0 QString::QString (this=0x23dda0, other=...) at
../../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qstring.h:958
#1 QLinkedListNode<QString>::QLinkedListNode (this=0x23dd90, arg=...) at
../../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qlinkedlist.h:71
#2 QLinkedList<QString>::detach_helper2 (this=0x7fffffffdad8, orgite=...)
at
../../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qlinkedlist.h:303
#3 0x00000000002153ad in QLinkedList<QString>::detach (this=0x23dd90) at
../../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qlinkedlist.h:106
#4 QLinkedList<QString>::end (this=0x23dd90) at
../../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qlinkedlist.h:209
#5 Grammar::Grammar (this=<optimized out>) at
/opt/build-sdk/qt5/qtbase/src/tools/qlalr/lalr.cpp:188
#6 main (argc=4, argv=<optimized out>) at
/opt/build-sdk/qt5/qtbase/src/tools/qlalr/main.cpp:103

I've only glanced quickly (read, less than 15 seconds) at the code but I
don't understand how it can work in any reasonable fashion: it seems that
it tries to construct a string (`QString Grammar::start` ) with the `end()`
of a container in lalr.cpp:188. But since it works in so many other
configurations I must be missing something somewhere.

Best,

-------
Jean-Michaël Celerier
http://www.jcelerier.name
Post by René J. V. Bertin
Post by Sérgio Martins
FWIW, I just tried -flto with clang-7.0 and gold-1.16 and can't
reproduce QTBUG-43556 anymore.
Good to know, I use the "regular" ld v2.3.0 (~gold for other reasons I cannot
really remember).
In the FWIW register: does clang 7 continue the trend of being noticeably slower
that its predecessor (about 15% for clang 6)?
R.
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
Jean-Michaël Celerier
2018-11-29 14:30:16 UTC
Permalink
I'm on clang 7.0.1-rc2 and a freshly-cloned qt 5.12.0 ; it does the same on
centos 7 and archlinux.


Best


On Thu, Nov 29, 2018 at 3:28 PM Jean-Michaël Celerier <
Post by Jean-Michaël Celerier
Here's my stacktrace (finally had some time to do a rebuild)
#0 QString::QString (this=0x23dda0, other=...) at
../../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qstring.h:958
#1 QLinkedListNode<QString>::QLinkedListNode (this=0x23dd90, arg=...) at
../../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qlinkedlist.h:71
#2 QLinkedList<QString>::detach_helper2 (this=0x7fffffffdad8, orgite=...)
at
../../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qlinkedlist.h:303
#3 0x00000000002153ad in QLinkedList<QString>::detach (this=0x23dd90) at
../../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qlinkedlist.h:106
#4 QLinkedList<QString>::end (this=0x23dd90) at
../../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qlinkedlist.h:209
#5 Grammar::Grammar (this=<optimized out>) at
/opt/build-sdk/qt5/qtbase/src/tools/qlalr/lalr.cpp:188
#6 main (argc=4, argv=<optimized out>) at
/opt/build-sdk/qt5/qtbase/src/tools/qlalr/main.cpp:103
I've only glanced quickly (read, less than 15 seconds) at the code but I
don't understand how it can work in any reasonable fashion: it seems that
it tries to construct a string (`QString Grammar::start` ) with the `end()`
of a container in lalr.cpp:188. But since it works in so many other
configurations I must be missing something somewhere.
Best,
-------
Jean-Michaël Celerier
http://www.jcelerier.name
Post by René J. V. Bertin
Post by Sérgio Martins
FWIW, I just tried -flto with clang-7.0 and gold-1.16 and can't
reproduce QTBUG-43556 anymore.
Good to know, I use the "regular" ld v2.3.0 (~gold for other reasons I cannot
really remember).
In the FWIW register: does clang 7 continue the trend of being noticeably slower
that its predecessor (about 15% for clang 6)?
R.
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest
Jean-Michaël Celerier
2018-11-29 17:33:45 UTC
Permalink
../qt5/configure -release \
-opensource \
-confirm-license \
-nomake examples \
-nomake tests \
-no-compile-examples \
-no-qml-debug \
-qt-zlib \
-no-mtdev \
-no-journald \
-no-syslog \
-no-gif \
-qt-libpng \
-qt-libjpeg \
-qt-zlib \
-qt-freetype \
-qt-harfbuzz \
-qt-pcre \
-qt-xcb \
-qt-xkbcommon-x11 \
-glib \
-no-cups \
-no-iconv \
-no-tslib \
-no-icu \
-no-pch \
-ltcg \
-openssl-linked \
-dbus-linked \
-no-system-proxies \
-platform linux-clang-libc++

I also changed a few things in the buildscripts to link with lld instead of
gold:

sed -i 's/fuse-ld=gold/fuse-ld=lld/g' \
qtbase/mkspecs/common/gcc-base-unix.conf \
qtbase/mkspecs/features/qt_configure.prf \
qtbase/configure.json

(I'm not using arch's native clang, but the one I compiled myself though)

Best,
Jean-Michaël
Post by Jean-Michaël Celerier
I'm on clang 7.0.1-rc2 and a freshly-cloned qt 5.12.0 ; it does the same on
centos 7 and archlinux.
It works for me on Archlinux.
What's your configure line ?
Regards,
--
KlarÀlvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts
Thiago Macieira
2018-11-29 23:15:53 UTC
Permalink
Post by Jean-Michaël Celerier
I also changed a few things in the buildscripts to link with lld instead of
sed -i 's/fuse-ld=gold/fuse-ld=lld/g' \
qtbase/mkspecs/common/gcc-base-unix.conf \
qtbase/mkspecs/features/qt_configure.prf \
qtbase/configure.json
(I'm not using arch's native clang, but the one I compiled myself though)
lld might be the issue. QLinkedListData::shared_null has pointers back to
itself:

const QLinkedListData QLinkedListData::shared_null = {
const_cast<QLinkedListData *>(&QLinkedListData::shared_null),
const_cast<QLinkedListData *>(&QLinkedListData::shared_null),
Q_REFCOUNT_INITIALIZE_STATIC, 0, true
};

If those pointers are incorrect, it would cause the error you're seeing.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Jean-Michaël Celerier
2018-11-30 10:39:20 UTC
Permalink
Building without LTO fixed it. Sorry for the bother. I'll see if I can send
a test case to LLVM...

Best,
Jean-Michaël
Post by Thiago Macieira
Post by Jean-Michaël Celerier
I also changed a few things in the buildscripts to link with lld instead
of
Post by Jean-Michaël Celerier
sed -i 's/fuse-ld=gold/fuse-ld=lld/g' \
qtbase/mkspecs/common/gcc-base-unix.conf \
qtbase/mkspecs/features/qt_configure.prf \
qtbase/configure.json
(I'm not using arch's native clang, but the one I compiled myself though)
lld might be the issue. QLinkedListData::shared_null has pointers back to
const QLinkedListData QLinkedListData::shared_null = {
const_cast<QLinkedListData *>(&QLinkedListData::shared_null),
const_cast<QLinkedListData *>(&QLinkedListData::shared_null),
Q_REFCOUNT_INITIALIZE_STATIC, 0, true
};
If those pointers are incorrect, it would cause the error you're seeing.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
_______________________________________________
Interest mailing list
https://lists.qt-project.org/listinfo/interest
Thiago Macieira
2018-11-30 16:51:52 UTC
Permalink
Post by Jean-Michaël Celerier
Building without LTO fixed it. Sorry for the bother. I'll see if I can send
a test case to LLVM...
I wish you luck. Tracking down LTO or PCH bugs is very hard...
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
René J.V. Bertin
2018-11-29 18:42:33 UTC
Permalink
Jean-Michaël Celerier wrote on 20181129::15:30:16 re: "Re: [Interest] update on building Qt/Linux with clang?"
Post by Jean-Michaël Celerier
I'm on clang 7.0.1-rc2 and a freshly-cloned qt 5.12.0 ; it does the same on
centos 7 and archlinux.
Have you tried with a release version of the compiler? And if this is still in the context of using LTO, have you tried -flto=thin instead of -flto?
Thiago Macieira
2018-11-29 16:24:21 UTC
Permalink
Post by Jean-Michaël Celerier
#4 QLinkedList<QString>::end (this=0x23dd90) at
../../../include/QtCore/../../../../qt5/qtbase/src/corelib/tools/qlinkedlist
.h:209 #5 Grammar::Grammar (this=<optimized out>) at
/opt/build-sdk/qt5/qtbase/src/tools/qlalr/lalr.cpp:188
#6 main (argc=4, argv=<optimized out>) at
/opt/build-sdk/qt5/qtbase/src/tools/qlalr/main.cpp:103
I've only glanced quickly (read, less than 15 seconds) at the code but I
don't understand how it can work in any reasonable fashion: it seems that
it tries to construct a string (`QString Grammar::start` ) with the `end()`
of a container in lalr.cpp:188. But since it works in so many other
configurations I must be missing something somewhere.
Most definitely a compiler bug. The qlalr.cpp:187-188 is:

Grammar::Grammar ():
start (names.end ())

start is an iterator and names is a member variable (orderd before start). So
the QLinkedList should have just been created and still be empty. detach()
shouldn't have anything to do.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Continue reading on narkive:
Loading...