Hi, Yeah, the rhel 7.2 icu packages on download.qt.io should not contain the .so symlinks.
Iikka, is this something you could help us with? Simon > On 29. Apr 2017, at 11:22, Konstantin Tokarev <[email protected]> wrote: > > > > 28.04.2017, 18:58, "Thiago Macieira" <[email protected]>: >>> On Friday, 28 April 2017 11:54:53 -03 Konstantin Tokarev wrote: >>> Hello, >>> >>> There is a strange situation involving official Qt SDK (>=5.8.0) binaries >>> for Linux, ICU, cmake, and WebKit project files, I'm not sure which side >>> really needs to be fixed. >>> >>> (Qt)WebKit uses custom module to find ICU, you can see its code at [1]. >>> Module uses quite popular practise of invoking pkg-config first, and then >>> performing search of libs and headers by passing them as HINTS to >>> find_path() and find_library(). Doing so allows to have a meaningful >>> fallback if pkg-config is missing, misconfigured, or e.g. returns host libs >>> when cross-compilation is needed. >> >> qtwebkit is built using qmake, so any CMake modules are irrelevant at this >> point. CMake is only used for building user applications. >> >>> There are a few possible solutions: >>> >>> * Provide ICU headers as a part of Qt SDK too. This has a benefit that ICU >>> libraries, required for QtCore, can be reused in other projects that use Qt >>> and ICU, e.g. for building of experimental QtWebKit versions against binary >>> SDK. >> >> Out of scope and you should be using qmake. > > I understand your point, but it seems impractical to provide wrapper qmake > project > as an interface for packagers. They know know how to deal with qmake or cmake > packages, but dealing with cmake wrapped with qmake is a totally different > business, > and can easily double amount of issues to solve, especially when > cross-compiling. > That said, it works fine in Coin. > > Maintaining old qmake-based build was not considered because I don't have > resources to maintain a build system that duplicate's one maintained by > upstream. > If there are volunteers to do that I can reconsider, but note that you will > have to deal > with lots of custom code generators, that are changed over time, and it would > be > much harder to backport upsream patches (that already include necessary cmake > changes) > > As a side effect, having cmake build that is usable as a public build > interface helps > with IDE integration, e.g. I'm using existing cmake support in Qt Creator for > development. > >> >>> * Remove unversioned symlinks like libicuuc.so from SDK, so that they >>> are not found by FindICU.cmake, and also by linker if it's given -licuuc >> >> That seems like the right solution for me. If we're not supplying the headers >> (and it's not our business to), then we shouldn't supply the *.so symlinks >> either. > > Fine with me. Looks like the problem is that archive [1] contains only > necessary files, > but [2] contains all ICU libraries + unversioned links. Archive [2] is > unpacked into > SDK image since 5.8.0. > > [1] > http://download.qt.io/development_releases/prebuilt/icu/prebuilt/56.1/icu-linux-g++-Rhel6.6-x64.7z > > Files: > > Extracting libicudata.so.56 > Extracting libicui18n.so.56 > Extracting libicuuc.so.56 > Extracting libicudata.so.56.1 > Extracting libicui18n.so.56.1 > Extracting libicuuc.so.56.1 > > [2] > http://download.qt.io/development_releases/prebuilt/icu/prebuilt/56.1/icu-linux-g++-Rhel7.2-x64.7z > > Files: > > Extracting libicudata.so > Extracting libicui18n.so > Extracting libicuio.so > Extracting libicule.so > Extracting libiculx.so > Extracting libicutest.so > Extracting libicutu.so > Extracting libicuuc.so > Extracting libicudata.so.56 > Extracting libicui18n.so.56 > Extracting libicuio.so.56 > Extracting libicule.so.56 > Extracting libiculx.so.56 > Extracting libicutest.so.56 > Extracting libicutu.so.56 > Extracting libicuuc.so.56 > Extracting libicudata.so.56.1 > Extracting libicui18n.so.56.1 > Extracting libicuio.so.56.1 > Extracting libicule.so.56.1 > Extracting libiculx.so.56.1 > Extracting libicutest.so.56.1 > Extracting libicutu.so.56.1 > Extracting libicuuc.so.56.1 > >> >> -- >> Thiago Macieira - thiago.macieira (AT) intel.com >> Software Architect - Intel Open Source Technology Center >> >> _______________________________________________ >> Development mailing list >> [email protected] >> http://lists.qt-project.org/mailman/listinfo/development > > -- > Regards, > Konstantin > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
