Skip to contentSkip to conversation

Qt5 fails to compile with gcc 6.1.0

Buildroot Marco Trapanese 3 participants 9 messages May 7, 2016

lore
Share & tools
lore
#0 lore raw

Same environment of the previous email. Qt5 fails with this error:

Quoted 6 lines

In file included from /home/femtotech/dev/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/include/c++/6.1.0/bits/stl_algo.h:59:0,
from
/home/femtotech/dev/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/include/c++/6.1.0/algorithm:62,
from
../../include/QtCore/../../src/corelib/global/qglobal.h:85,

Quoted 6 lines
                 from ../../include/QtCore/qglobal.h:1,
                 from accessible/qaccessible.h:34,
                 from accessible/qaccessible.cpp:34:

/home/femtotech/dev/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/include/c++/6.1.0/cstdlib:75:25:
fatal error: stdlib.h: File o directory non esistente
#include_next <stdlib.h>

which means: "file or directory not found".
stdlib.h is in sysroot/usr/include:

Quoted 1 line

/host/usr/arm-buildroot-linux-gnueabihf/sysroot/usr/include/stdlib.h

It seems the same behavior reported here:

https://bugs.musicpd.org/view.php?id=4524

Right now I'm rebuilding once again with an older version of gcc, hoping this won't trigger the kernel-panic as in gcc 4.8.

#3 lore raw
In reply to Marco Trapanese

Hello,

Quoted 2 lines · Marco Trapanese

I don't know how to configure a working environment with Qt5 and bluez5. I will try with musl, but I confess I really don't understand what's happening.

Every time you do such tests, please make sure you do a complete rebuild, i.e:

make clean all

If it still doesn't work for you after a "make clean all", then please report the version of Buildroot being used, as well as the .config file that reproduces the problem.

Best regards,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#4 lore raw

Il 07/05/2016 14:11, Thomas Petazzoni ha scritto:

Quoted 4 lines

Every time you do such tests, please make sure you do a complete rebuild, i.e: make clean all If it still doesn't work for you after a "make clean all", then please report the version of Buildroot being used, as well as the .config file that reproduces the problem.

Yes, I always "make clean all".

Attached there is the .config file.
The version is Buildroot 2016.05-git-01197-gda433d6-dirty

-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config
Type: application/xml
Size: 94390 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160507/0586e04f/attachment.wsdl>

#5 lore raw

Hello,

Quoted 4 lines · Marco Trapanese

Yes, I always "make clean all".

Attached there is the .config file.
The version is Buildroot 2016.05-git-01197-gda433d6-dirty

However your version is "-dirty" which means you have modified Buildroot. But we have no idea which modifications you have made. Maybe those modifications are the reason for the failure?

Also, please don't use gcc 6.x for now, and stay with gcc 4.9, so please test with gcc 4.9.

Please disable LTO support for the moment. It isn't enabled by default, and we don't test it that often, so please disable it for now.

Please stay with the default of binutils 2.25 instead of selecting binutils 2.26.

Once you have changed those configuration options and removed your local Buildroot modifications, please try again a complete build "make clean all" and see if it works or not. If it doesn't, I'll try to reproduce here.

Thanks!

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
#6 lore raw

Il 07/05/2016 14:28, Thomas Petazzoni ha scritto:

Quoted 3 lines

However your version is "-dirty" which means you have modified Buildroot. But we have no idea which modifications you have made. Maybe those modifications are the reason for the failure?

I did the following:

git clone git://git.buildroot.net/buildroot
git pull

then I applied the patches you suggested for Qt5 and bluez5:
https://patchwork.ozlabs.org/patch/612072/
Of course I changed the post-build script and the genimage commands in the boards directory, but I think I'm allowed to do this.

Quoted 6 lines

Also, please don't use gcc 6.x for now, and stay with gcc 4.9, so please test with gcc 4.9.

Please disable LTO support for the moment. It isn't enabled by default, and we don't test it that often, so please disable it for now.

Quoted 7 lines

Please stay with the default of binutils 2.25 instead of selecting binutils 2.26.

Once you have changed those configuration options and removed your local Buildroot modifications, please try again a complete build "make clean all" and see if it works or not. If it doesn't, I'll try to reproduce here.

Well, I've downloaded buildroot from scratch to be sure. I confirm the "dirty" flag appears after applying the patches for Qt5/bluez5.

Attached there is the new .config file.
It's compiling right now. I will inform you of the results.

Thanks
Marco

-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config
Type: application/xml
Size: 92413 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160507/08754f04/attachment-0001.wsdl>

#7 lore raw

[Buildroot] Kernel panic with glibc

In reply to Thomas Petazzoni

Il 07/05/2016 14:28, Thomas Petazzoni ha scritto:

Quoted 4 lines

Once you have changed those configuration options and removed your local Buildroot modifications, please try again a complete build "make clean all" and see if it works or not. If it doesn't, I'll try to reproduce here.

I'm very sorry, the building was successful, but it still doesn't boot due to the kernel panic. I attach again the .config.

Please, would you help me to fix this? I don't know how to go ahead with my work. I need glibc mainly to support bluez5:

http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/137079

I also found this old message:

https://patchwork.ozlabs.org/patch/208855/

do you think I can enable wordexp also in the latest release? In the meanwhile I'm going to try to use bluez 5.27 which should not have the dependency of regexp as you written.

I haven't enough knowledge to fully understand how to solve these issues, thus I'm afraid I'm not contributing to the buildroot community.

Best regards
Marco

-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config
Type: application/xml
Size: 92413 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20160507/c2ea4140/attachment-0001.wsdl>

#8 lore raw
In reply to Marco Trapanese
Quoted 16 lines · Marco Trapanese

Same environment of the previous email. Qt5 fails with this error:

Quoted 6 lines

In file included from /home/femtotech/dev/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/include/c++/6.1.0/bits/stl_algo.h:59:0,

from
/home/femtotech/dev/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/include/c++/6.1.0/algorithm:62,

Quoted 7 lines
                 from ../../include/QtCore/../../src/corelib/global/qglobal.h:85,
                 from ../../include/QtCore/qglobal.h:1,
                 from accessible/qaccessible.h:34,
                 from accessible/qaccessible.cpp:34:

/home/femtotech/dev/buildroot/output/host/usr/arm-buildroot-linux-gnueabihf/include/c++/6.1.0/cstdlib:75:25:
fatal error: stdlib.h: File o directory non esistente
#include_next <stdlib.h>

Quoted 8 lines

which means: "file or directory not found".
stdlib.h is in sysroot/usr/include:

Quoted 1 line

/host/usr/arm-buildroot-linux-gnueabihf/sysroot/usr/include/stdlib.h

It seems the same behavior reported here:

https://bugs.musicpd.org/view.php?id=4524

It's also been reported for Fedora [1]. The problem is that qt5 adds a
completely redundant -isystem <system-include-path> to the gcc command line. I guess in gcc6 the include path for the standard C++ headers has changed which makes the #include_next <stdlib.h> fail.

I couldn't find anything in the qt bugtracker, so we should probably report it
there.

Regards,
Arnout

[1]
https://lists.fedoraproject.org/archives/list/devel at lists.fedoraproject.org/thread/Q5SWCUUMWQ4EMS7CU2CBOZHV3WZYOOTT/

Signature · 6 lines
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF