[Interest] building Qt 5.9 on Linux - clang or GCC?

[René J.V. Bertin]

Hi,

Not to start a flame war, but are there clear differences between building Qt (on Linux) with clang (5.0) vs. GCC (7.2) that make the one or the other a better choice for certain domains of application?

Link-time optimisation is out of the question (too costly on my hardware, which is also why I can't really do a comparison). I'm not expecting much performance difference, so build time (cum memory requirements) and installation size can tip the scales for me.

Thanks!
R.

[Allan Sandfeld Jensen]

Post by René J.V. Bertin
Hi,
Not to start a flame war, but are there clear differences between building
Qt (on Linux) with clang (5.0) vs. GCC (7.2) that make the one or the other
a better choice for certain domains of application?
Link-time optimisation is out of the question (too costly on my hardware,
which is also why I can't really do a comparison). I'm not expecting much
performance difference, so build time (cum memory requirements) and
installation size can tip the scales for me.

It is pretty much the same. I would recommend gcc because that is default on
Linux and the most likely to compile warning free and support most
configurations. Clang works almost entirely the same everywhere, but sometimes
it has different warnings that breaks developer builds or peculiar bugs on in
some obscure corner-case that causes a compile error in one late module
somewhere (not that gcc don't have those too, but being default, we have
already had to work around those).

Btw. LTO isn't that insane these days, In shared Qt builds we don't not let
the LTO work across shared libraries, so it is only performed within each
library, which gives almost all the benefits and none of the problems.
Especially if you want smaller binaries ltcg + optimize_size gives great
results.

'Allan

[René J. V. Bertin]

Allan Sandfeld Jensen wrote:

Hi,

Post by Allan Sandfeld Jensen
It is pretty much the same. I would recommend gcc because that is default on
Linux and the most likely to compile warning free and support most
configurations.

That's more or less what I expected. The only mostly systematic difference I see
(on all platforms) is that GCC generates debug information that takes much more
space. No idea if that means there's more information but the difference is
large enough that I wonder if it doesn't increase load times.

Post by Allan Sandfeld Jensen
Btw. LTO isn't that insane these days, In shared Qt builds we don't not let

...

Post by Allan Sandfeld Jensen
Especially if you want smaller binaries ltcg + optimize_size gives great
results.

I know, but it still basically doubles the build time because almost everything
is actually built a second time during the link step. A regular build already
stresses my Linux system to a point where I can barely do anything else on it.
And on Mac, well, using LTO means you give up debugging, for some reason (the
information is still there AFAICT, but the debugger acts as if it isn't). Not
that I do a lot of Qt debugging, but it's useful to be able to trace application
crashes into Qt code, and to be able to inspect QObjects, QWidgets etc.

R.

[Thiago Macieira]

Post by René J. V. Bertin
That's more or less what I expected. The only mostly systematic difference I
see (on all platforms) is that GCC generates debug information that takes
much more space. No idea if that means there's more information but the
difference is large enough that I wonder if it doesn't increase load times.

It doesn't, because the debug information is not loaded in the first place.
When using readelf, note how the "A" flag is missing for those sections.

Post by René J. V. Bertin
I know, but it still basically doubles the build time because almost
everything is actually built a second time during the link step. A regular
build already stresses my Linux system to a point where I can barely do
anything else on it. And on Mac, well, using LTO means you give up
debugging, for some reason (the information is still there AFAICT, but the
debugger acts as if it isn't). Not that I do a lot of Qt debugging, but
it's useful to be able to trace application crashes into Qt code, and to be
able to inspect QObjects, QWidgets etc.

One more reason to use GCC. It only builds once, even under LTO, unless you
specifically ask for the fat LTO objects.

qmake -config ltcg -config fat-lto

[René J. V. Bertin]

Post by Thiago Macieira
It doesn't, because the debug information is not loaded in the first place.
When using readelf, note how the "A" flag is missing for those sections.

So it has to skip certain, possibly considerable parts of the file while loading
it, rather than simply doing some efficient operation to copy the whole file into
memory. That should affect load times somewhat, no?

Post by Thiago Macieira
One more reason to use GCC. It only builds once, even under LTO, unless you
specifically ask for the fat LTO objects.

Yet even with GCC the build times and memory requirements are larger with LTO
than without. How can it not do certain things twice?

[Konstantin Tokarev]

Post by René J. V. Bertin

 It doesn't, because the debug information is not loaded in the first place.
 When using readelf, note how the "A" flag is missing for those sections.

So it has to skip certain, possibly considerable parts of the file while loading
it, rather than simply doing some efficient operation to copy the whole file into
memory. That should affect load times somewhat, no?

ELF is loaded into memory by using file mappings, separate mapping for different
sections.

Post by René J. V. Bertin

 One more reason to use GCC. It only builds once, even under LTO, unless you
 specifically ask for the fat LTO objects.

Yet even with GCC the build times and memory requirements are larger with LTO
than without. How can it not do certain things twice?
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest

[Sérgio Martins]

Post by René J. V. Bertin

Post by Thiago Macieira
It doesn't, because the debug information is not loaded in the first place.
When using readelf, note how the "A" flag is missing for those sections.

So it has to skip certain, possibly considerable parts of the file while loading
it, rather than simply doing some efficient operation to copy the whole file into
memory. That should affect load times somewhat, no?

Damn, how old is your computer ? :)

Jumping back on topic: if you have a super important project, you
probably should compile with both, as each compiler has warnings not
implemented in the other.
Otherwise, just choose one, it won't make much difference.


Regards,
Sergio Martins

[Thiago Macieira]

Post by René J. V. Bertin

Post by Thiago Macieira
It doesn't, because the debug information is not loaded in the first place.
When using readelf, note how the "A" flag is missing for those sections.

So it has to skip certain, possibly considerable parts of the file while
loading it, rather than simply doing some efficient operation to copy the
whole file into memory. That should affect load times somewhat, no?

No, that's not how ELF works.

First of all, the dynamic linker doesn't actually read the section table. It
reads the segment table, found in the ELF program headers (readelf -l):

$ readelf -l /lib/libm.so.6

Elf file type is DYN (Shared object file)
Entry point 0x6200
There are 7 program headers, starting at offset 52

Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x00000000 0x00000000 0xf9264 0xf9264 R E 0x1000
LOAD 0x0f9eb4 0x000faeb4 0x000faeb4 0x003cc 0x003d4 RW 0x1000
DYNAMIC 0x0f9ebc 0x000faebc 0x000faebc 0x00118 0x00118 RW 0x4
NOTE 0x000114 0x00000114 0x00000114 0x00044 0x00044 R 0x4
GNU_EH_FRAME 0x0dda54 0x000dda54 0x000dda54 0x016bc 0x016bc R 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10
GNU_RELRO 0x0f9eb4 0x000faeb4 0x000faeb4 0x0014c 0x0014c R 0x1

Section to Segment mapping:
Segment Sections...
00 .note.gnu.build-id .note.ABI-tag .gnu.hash .dynsym .dynstr
.gnu.version .gnu.version_d .gnu.version_r .rel.dyn .rel.plt .init .plt
.plt.got .text .fini .rodata .eh_frame_hdr .eh_frame .hash
01 .init_array .fini_array .dynamic .got .got.plt .data .bss
02 .dynamic
03 .note.gnu.build-id .note.ABI-tag
04 .eh_frame_hdr
05
06 .init_array .fini_array .dynamic .got

(I've pasted libm only for column width, try it on a Qt library with debugging
list yourself)

Note the LOAD commands. That's what matters to the dynamic linker and what it
will load. Note also how the debug sections are not in the first or second
entries of the section-to-segment mapping list. That means the debugging
sections are beyond the load regions and won't be present in memory.

Second, file binary is loaded via mmap(), which means the actual file contents
aren't faulted into memory unless needed or unless there's an madvise() system
call to tell the kernel to load. So even if the debug sections included in the
LOAD regions, they wouldn't occupy core memory nor would affect the load time,
unless something actually tried to access them.

Post by René J. V. Bertin

Post by Thiago Macieira
One more reason to use GCC. It only builds once, even under LTO, unless you
specifically ask for the fat LTO objects.

Yet even with GCC the build times and memory requirements are larger with
LTO than without. How can it not do certain things twice?

The build time has nothing to do with doing things twice. It has to do with
the amount of work.

Even with LTO, the compiler must start and process each translation unit. The
difference between LTO and a normal build is that in the former, it needs to
do less work since it doesn't actually run the optimiser. It just needs to
dump some intermediary information.

The difference is with the linker. In a regular build, even with -Wl,-O1, the
linker does very little and its job is to basically concatenate sections of
each input file. In an LTO build, the linker calls the compiler again and that
will need to reload all the intermediary information and perform the
optimisation, now with a much larger dataset.

In my experience, a thin LTO build is actually faster (and produces better
code) than an equivalent non-LTO build, but that doesn't apply to all cases.

Regular, optimised (-O3 -g1) build of qmake:
Time to build: 268,00s user 11,28s system 368% cpu 1:15,87 total
Total object sizes (kB): 69596
Binary size (after stripping):
text data bss dec hex filename
3008485 2080 6361 3016926 2e08de ../bin/qmake

Simple LTO build (-O3 -g1 -flto -fno-fat-lto-objects, linking* -flto=4):
Time: 208,01s user 10,36s system 365% cpu 59,731 total
Total object sizes: 32476
Binary:
text data bss dec hex filename
2427597 1972 6217 2435786 252aca ../bin/qmake

Fat LTO build (-O3 -g1 -flto -ffat-lto-objects, linking* -flto=4):
Time: 371,19s user 13,49s system 369% cpu 1:44,11 total
Sizes: 101928
Binary:
text data bss dec hex filename
2427597 1972 6217 2435786 252aca ../bin/qmake

*: Don't forget to pass -O3 -g1 to the linker too, otherwise the LTO step
won't optimise!

[Allan Sandfeld Jensen]

Post by René J. V. Bertin

Post by Thiago Macieira
It doesn't, because the debug information is not loaded in the first place.
When using readelf, note how the "A" flag is missing for those sections.

So it has to skip certain, possibly considerable parts of the file while
loading it, rather than simply doing some efficient operation to copy the
whole file into memory. That should affect load times somewhat, no?

Post by Thiago Macieira
One more reason to use GCC. It only builds once, even under LTO, unless you
specifically ask for the fat LTO objects.

Yet even with GCC the build times and memory requirements are larger with
LTO than without. How can it not do certain things twice?

It uses more memory because the compiler effectively works on all the source
files at once during the linking phase, so it needs to hold all of files
decoded in memory at the same time. It is not really much slower anymore
though. It used to be slower because the final compilation was all in a single
process and single threaded, but that part is now multithreaded. Now it is
only slower if you dont have enough memory.

'Allan

[Thiago Macieira]

Post by Allan Sandfeld Jensen
It is not really much slower anymore
though. It used to be slower because the final compilation was all in a
single process and single threaded, but that part is now multithreaded.

From experience, it's *not* slower.

It's only slower if you forget to pass the number of threads to use during
linking. When I was creating the numbers for my other email, I had forgotten
that (I was modifying the Makefile manually), leading to increased build
times. Once corrected, the build times were faster.

The drawback is that if you have 4 processors and link two libraries at the
same time with -flto=4, they'll both compete for resources. CPU time is not
the issue, but it could lead to swapping to keep both optimisers in memory.
That could happen for QtNetwork and QtGui, for example, since they are built
soon after QtCore.

There's -flto=observer to work with the GNU make jobserver, but that requires
changes to the Makefile itself and that causes a lot use-cases with make to
break, so it's not an option.

[Thiago Macieira]

Post by René J.V. Bertin
Hi,
Not to start a flame war, but are there clear differences between building
Qt (on Linux) with clang (5.0) vs. GCC (7.2) that make the one or the other
a better choice for certain domains of application?
Link-time optimisation is out of the question (too costly on my hardware,
which is also why I can't really do a comparison). I'm not expecting much
performance difference, so build time (cum memory requirements) and
installation size can tip the scales for me.

Use GCC.

[René J. V. Bertin]

Talking about keeping the binaries compact: is there a way to build or strip
specific components from most debug information, let's say except that which is
needed to get backtraces with line numbers (and function names)?

R.

[Konstantin Tokarev]

Post by René J. V. Bertin
Talking about keeping the binaries compact: is there a way to build or strip
specific components from most debug information, let's say except that which is
needed to get backtraces with line numbers (and function names)?

Use -g1 instead of -g.

You may also want to split debug info and use dwz utility to reduce redundancy.

Post by René J. V. Bertin
R.
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest

[Thiago Macieira]

Post by René J. V. Bertin
Talking about keeping the binaries compact: is there a way to build or strip
specific components from most debug information, let's say except that
which is needed to get backtraces with line numbers (and function names)?

Not with the standard tools.

A Qt release build builds with -g1 instead of -g, which should be sufficient
for backtraces but not for debugging.

But you can't strip the info once created. So you will have big debug symbols
if you build with either -debug or with -release -force-debug-info.

You need a specialised stripper tool. I remember some colleagues had proposed
to do that for Clear Linux, but I don't know if they actually accomplished it.
I can ask in the new year, if you remind me.

[René J. V. Bertin]

Post by Thiago Macieira
A Qt release build builds with -g1 instead of -g, which should be sufficient
for backtraces but not for debugging.

That's interesting, the option doesn't show up in g++ --verbose --help so I
wasn't aware it existed. There's also -gz I see now, which could be useful for
those components for which I do want more complete debug info. I don't know if
dwz converts to that format but it certainly seems effective (so thanks for the
tip, Konstantin!).

Post by Thiago Macieira
You need a specialised stripper tool. I remember some colleagues had proposed
to do that for Clear Linux, but I don't know if they actually accomplished it.
I can ask in the new year, if you remind me.

Great, I'll try to remember!

[Konstantin Tokarev]

Post by René J. V. Bertin

 A Qt release build builds with -g1 instead of -g, which should be sufficient
 for backtraces but not for debugging.

That's interesting, the option doesn't show up in g++ --verbose --help so I
wasn't aware it existed.

With GCC, you should better read man.
With Clang you should better read --help :)

Post by René J. V. Bertin
There's also -gz I see now, which could be useful for those components for

which I do want more complete debug info.

It will increase compilation time and may cause compatiility problems

Post by René J. V. Bertin
I don't know if dwz converts to that format

No it doesn't

Post by René J. V. Bertin
but it certainly seems effective (so thanks for the
tip, Konstantin!).

 You need a specialised stripper tool. I remember some colleagues had proposed
 to do that for Clear Linux, but I don't know if they actually accomplished it.
 I can ask in the new year, if you remind me.

Great, I'll try to remember!

FWIW, normal strip utility can remove data per-symbol

Post by René J. V. Bertin
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest

[tomek]

Since you have started such a discussion I want to ask you if you have
tried to compile latest Qt releases with clang on linux?
I'm having some problems with I've described in more details on qt's forum:

https://forum.qt.io/topic/86052/qt-5-10-0-compile-with-clang-on-ubuntu-17-10

Hope you are tolerating links to qt's forum here.
To make long story short it looks like there might be some errors in build
scripts, but it's also possible I've done something wrong.
So if anybody has compiled latest release with clang please take a look
into this thread.

BR/
Tomek

Post by Thiago Macieira

Post by René J. V. Bertin

Post by Thiago Macieira
A Qt release build builds with -g1 instead of -g, which should be

sufficient

Post by René J. V. Bertin

Post by Thiago Macieira
for backtraces but not for debugging.

That's interesting, the option doesn't show up in g++ --verbose --help

so I

Post by René J. V. Bertin
wasn't aware it existed.

With GCC, you should better read man.
With Clang you should better read --help :)

Post by René J. V. Bertin
There's also -gz I see now, which could be useful for those components for

which I do want more complete debug info.
It will increase compilation time and may cause compatiility problems

Post by René J. V. Bertin
I don't know if dwz converts to that format

No it doesn't

Post by René J. V. Bertin
but it certainly seems effective (so thanks for the
tip, Konstantin!).

Post by Thiago Macieira
You need a specialised stripper tool. I remember some colleagues had

proposed

Post by René J. V. Bertin

Post by Thiago Macieira
to do that for Clear Linux, but I don't know if they actually

accomplished it.

Post by René J. V. Bertin

Post by Thiago Macieira
I can ask in the new year, if you remind me.

Great, I'll try to remember!

FWIW, normal strip utility can remove data per-symbol

Post by René J. V. Bertin
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest

--
Regards,
Konstantin
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest

[René J.V. Bertin]

Post by tomek
Since you have started such a discussion I want to ask you if you have
tried to compile latest Qt releases with clang on linux?

No, I haven't myself. Sometimes I do follow the advice I get when I ask for it and in this case I didn't have any trouble doing that at all :)

One observation though: clang 5.0.1 is going to come out in a matter of days. It may fix some of the things you're seeing.

R

[Thiago Macieira]

Post by tomek
Since you have started such a discussion I want to ask you if you have
tried to compile latest Qt releases with clang on linux?

I have. It compiles just fine.

I haven't *run* anything with it for ages, though.

Post by tomek
https://forum.qt.io/topic/86052/qt-5-10-0-compile-with-clang-on-ubuntu-17-10
Hope you are tolerating links to qt's forum here.

Links are fine. But in the interest of expediency, you should post the actual
information in the mail. In order to answer you, I need to wait for the
website to load, which it hasn't in the last minute since I clicked the link
in the airport wifi.

So I can't help you. Maybe in 15 hours when I get to where I'm going.

Post by tomek
To make long story short it looks like there might be some errors in build
scripts, but it's also possible I've done something wrong.
So if anybody has compiled latest release with clang please take a look
into this thread.

[Thiago Macieira]

Post by Thiago Macieira

https://forum.qt.io/topic/86052/qt-5-10-0-compile-with-clang-on-ubuntu-17-> > 10
Hope you are tolerating links to qt's forum here.

Links are fine. But in the interest of expediency, you should post the
actual information in the mail. In order to answer you, I need to wait for
the website to load, which it hasn't in the last minute since I clicked the
link in the airport wifi.
So I can't help you. Maybe in 15 hours when I get to where I'm going.

Ok, it loaded.

Don't pass -c++11, -c++14 or -c++1z. Just let Qt choose the best one. That's
valid for EVERY platform, every compiler. I wanted to get rid of that option
altogether since users should not choose, but was overruled.

Anyway, for Clang on Linux, that's C++14, because Clang on Linux can't compile
the C++17 headers from libstdc++. As you've discovered.

[tomek]

I should think about airports and hotels... sorry for that.

But getting back to the topic, I've started build configuration as usually
using GCC - without passing this flag at all. But it failed with this error:

ERROR: C++11 <random> is required and is missing or failed to compile.

So I've started experimenting. Nothing changed no matter which standard I'm
trying to use.

Post by Thiago Macieira

Post by tomek
https://forum.qt.io/topic/86052/qt-5-10-0-compile-with-

clang-on-ubuntu-17-> > 10

Post by Thiago Macieira

Post by tomek
Hope you are tolerating links to qt's forum here.

Links are fine. But in the interest of expediency, you should post the
actual information in the mail. In order to answer you, I need to wait

for

Post by Thiago Macieira
the website to load, which it hasn't in the last minute since I clicked

the

Post by Thiago Macieira
link in the airport wifi.
So I can't help you. Maybe in 15 hours when I get to where I'm going.

Ok, it loaded.
Don't pass -c++11, -c++14 or -c++1z. Just let Qt choose the best one. That's
valid for EVERY platform, every compiler. I wanted to get rid of that option
altogether since users should not choose, but was overruled.
Anyway, for Clang on Linux, that's C++14, because Clang on Linux can't compile
the C++17 headers from libstdc++. As you've discovered.
--
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

[Thiago Macieira]

Post by tomek
I should think about airports and hotels... sorry for that.
But getting back to the topic, I've started build configuration as usually
ERROR: C++11 <random> is required and is missing or failed to compile.

You need to fix this error before compiling Qt. As the message says, C++11
<random> is required for Qt.

In the qtbase sources, you'll find
config.tests/unix/cxx11_random/cxx11_random.cpp

Fix your compiler so it compiles that file.

It works just fine with Clang on Linux for me.

$ clang -std=c++11 -fsyntax-only config.tests/unix/cxx11_random/
cxx11_random.cpp

$ clang -v
clang version 5.0.0 (tags/RELEASE_500/final 312548)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/tjmaciei/bin
Found candidate GCC installation: /usr/lib64/gcc/x86_64-suse-linux/7
Selected GCC installation: /usr/lib64/gcc/x86_64-suse-linux/7
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64

[tomek]

Post by tomek

Post by tomek
I should think about airports and hotels... sorry for that.
But getting back to the topic, I've started build configuration as

usually

Post by tomek
using GCC - without passing this flag at all. But it failed with this
ERROR: C++11 <random> is required and is missing or failed to compile.

You need to fix this error before compiling Qt. As the message says, C++11
<random> is required for Qt.
In the qtbase sources, you'll find
config.tests/unix/cxx11_random/cxx11_random.cpp
Fix your compiler so it compiles that file.
It works just fine with Clang on Linux for me.
$ clang -std=c++11 -fsyntax-only config.tests/unix/cxx11_random/
cxx11_random.cpp

And it works also for me too, but command executed during 'configure'
script execution lacks -std=c++11 flag:

$ clang++ -c -pipe -O2 -w -fPIC
-I/home/tomek/workspace/qt-dev/qt5/qtbase/config.tests/unix/cxx11_random
-I. -I/home/tomek/workspace/qt-dev/qt5/qtbase/mkspecs/linux-clang -o
cxx11_random.o
/home/tomek/workspace/qt-dev/qt5/qtbase/config.tests/unix/cxx11_random
/cxx11_random.cpp

Executing:

$ clang -fsyntax-only config.tests/unix/cxx11_random/cxx11_random.cpp

also fails - which is obvious but that's the case I'm trying to explain.
It looks like there might be an issue in build system since it is not
passing those flags.
But if it works for you it must be something wrong in my configuration.

I've updated my sources, switched to dev branch and run:

../configure -platform linux-clang -opensource -nomake examples -nomake
tests

and still having:

ERROR: C++11 <random> is required and is missing or failed to compile.

$ clang -v

Post by tomek
clang version 5.0.0 (tags/RELEASE_500/final 312548)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/tjmaciei/bin
Found candidate GCC installation: /usr/lib64/gcc/x86_64-suse-linux/7
Selected GCC installation: /usr/lib64/gcc/x86_64-suse-linux/7

Post by tomek
clang++ -v

clang version 5.0.0-3 (tags/RELEASE_500/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/7
Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/7.2.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.4.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/7.2.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.2.0
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0

Post by tomek
--
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

[Thiago Macieira]

Post by tomek
And it works also for me too, but command executed during 'configure'

Ah, so that is the problem.

It's passing -std=gnu++11 here, for me.

Can you attach the entire config.log? Make sure config.cache is empty (or
doesn't exist) before running configure. The problem may be the detection of
what C++ the compiler defaults to.

[tomek]

Ok, so the build directory is being cleaned up before I'm running configure
script:
***@tomek-pc:~/workspace/qt-dev/qt5/build-5.10.0_x86_64_clang (dev) > rm
-rf *
***@tomek-pc:~/workspace/qt-dev/qt5/build-5.10.0_x86_64_clang (dev) > ls
***@tomek-pc:~/workspace/qt-dev/qt5/build-5.10.0_x86_64_clang (dev) >
../configure -platform linux-clang -opensource -nomake examples -nomake
tests

C++ releated features tests output:
Checking for C++14 support...
yes

Checking for C++1z support... yes
Checking for C++11 <future>... no
Checking for C++11 <random>... no

Configure summary:

Build type: linux-clang (x86_64, CPU features: mmx sse sse2)
Configuration: use_gold_linker sse2 aesni sse3 ssse3 sse4_1 sse4_2 avx avx2
avx512f avx512bw avx512cd avx512dq avx512er avx512ifma avx512pf avx512vbmi
avx512vl compile_examples enable_new_dtags f16c largefile precompile_header
rdrnd shani x86SimdAlways shared rpath
release c++11 c++14 c++1z concurrent dbus reduce_exports
reduce_relocations stl
Using C++ standard ..................... C++1z

ERROR: C++11 <random> is required and is missing or failed to compile.

Hope it's enough, attaching config.log file with details.

BTW. Thanks for your help Thiago.

BR/

Post by Thiago Macieira

Post by tomek
And it works also for me too, but command executed during 'configure'

Ah, so that is the problem.
It's passing -std=gnu++11 here, for me.
Can you attach the entire config.log? Make sure config.cache is empty (or
doesn't exist) before running configure. The problem may be the detection of
what C++ the compiler defaults to.
--
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

[Allan Sandfeld Jensen]

Post by Konstantin Tokarev

Post by René J. V. Bertin

Post by Thiago Macieira
A Qt release build builds with -g1 instead of -g, which should be
sufficient for backtraces but not for debugging.

That's interesting, the option doesn't show up in g++ --verbose --help so I
wasn't aware it existed.

With GCC, you should better read man.
With Clang you should better read --help :)

With gcc either use "info", or google "gcc manual" and read the online manual
which is the same as the info pages. ;)

'Allan

[René J.V. Bertin]

On Wednesday December 20 2017 18:43:51 Allan Sandfeld Jensen wrote:

Another interesting one in this context: -gtoggle . I'm going to try that one with QWE which so far has proven to be very resilient to preventing debug info from being generated (it QtBase was built with -g?). That should really make a sh*load of difference on the build dir size (roughly 25Gb with clang on Mac....)

R.