-
Bug
-
Resolution: Done
-
P3: Somewhat important
-
5.9
-
None
-
RHEL 6.x
-
ea9429ec78a3a40f8a7aa5d2f3a523f14f9cc6e1 (qt/qtconnectivity/dev)
We have hacked our RHEL 6.6 to include newer headers than actually is provided by RH. Due to this we can actually build qtconnectivity succesfully. But that's not acceptable. We state that Qt is supported in RHEL 6.6, so it should at least compile there.
I tried building with RHEL 6.10 and stumbled upon this error https://testresults.qt.io/coin/logview/qt/qtconnectivity/cb43a4f16075cb161cf25f41a69cb8e5f4e626fe/LinuxRHEL_6_10x86_64LinuxRHEL_6_10x86_64GCCqtci-linux-RHEL-6.10-x86_64-15b79fRelease_ForceDebugInfo/d355510facd59767267407078c5d0db45c819132/build_1553073412 :
agent:2019/03/20 10:41:42 build.go:192: g++ -c -pipe -O2 -g -std=c++1z -fvisibility=hidden -fvisibility-inlines-hidden -fno-exceptions -Wall -W -Wvla -Wdate-time -Wshift-overflow=2 -Wduplicated-cond -D_REENTRANT -fPIC -DQT_DISABLE_DEPRECATED_BEFORE=0 -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_PLUGIN -DQT_BLUETOOTH_LIB -DQT_QUICK_LIB -DQT_GUI_LIB -DQT_QML_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -I. -I../../../include -I../../../include/QtBluetooth -I/home/qt/work/install/include -I/home/qt/work/install/include/QtQuick -I/home/qt/work/install/include/QtGui -I/home/qt/work/install/include/QtQml -I/home/qt/work/install/include/QtNetwork -I/home/qt/work/install/include/QtCore -I.moc -isystem /usr/include/libdrm -I/home/qt/work/install/mkspecs/linux-g++ -o .obj/qdeclarativebluetoothservice.o qdeclarativebluetoothservice.cpp agent:2019/03/20 10:41:43 build.go:192: main.cpp: In function ‘int main(int, char**)’: agent:2019/03/20 10:41:43 build.go:192: main.cpp:327:30: error: ‘htonl’ was not declared in this scope agent:2019/03/20 10:41:43 build.go:192: field0 = htonl(field0); agent:2019/03/20 10:41:43 build.go:192: ^ agent:2019/03/20 10:41:43 build.go:192: main.cpp:329:30: error: ‘htons’ was not declared in this scope agent:2019/03/20 10:41:43 build.go:192: field1 = htons(field1);
Now the configure with the original RHEL headers say:
agent:2019/03/20 10:40:50 build.go:192: BlueZ .................................. yes agent:2019/03/20 10:40:50 build.go:192: BlueZ Low Energy ....................... no agent:2019/03/20 10:40:50 build.go:192: Linux Crypto API ....................... no
Perhaps it should just bail out to 'no, no, no' and quit building if it doesn't work. The newer manually set headers clainm yes, yes, no to those.