On (recent) CURRENT running 11.3-RELENG, 12-STABLE and CURRENT jails for poudriere, port converters/wkhtmltopdf fails to compile due to a linker error complaining about missing library QtWebKit, see below. Environment is: Poudriere version: 3.3.3 Host OSVERSION: 1300076 Jail OSVERSION: 1201509 Job Id: 03 ---Begin Environment--- SHELL=/bin/csh OSVERSION=1201509 UNAME_v=FreeBSD 12.1-STABLE 1201509 UNAME_r=12.1-STABLE BLOCKSIZE=K MAIL=/var/mail/root STATUS=1 HOME=/root PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin LOCALBASE=/usr/local USER=root LIBEXECPREFIX=/usr/local/libexec/poudriere POUDRIERE_VERSION=3.3.3 MAKEOBJDIRPREFIX=/pool/sources/12-STABLE/obj MASTERMNT=/pool/poudriere/data/.m/12amd64-head-default/ref POUDRIERE_BUILD_TYPE=bulk PACKAGE_BUILDING=yes SAVED_TERM=screen PWD=/pool/poudriere/data/.m/12amd64-head-default/ref/.p/pool P_PORTS_FEATURES=FLAVORS SELECTED_OPTIONS MASTERNAME=12amd64-head-default SCRIPTPREFIX=/usr/local/share/poudriere OLDPWD=/pool/poudriere/data/.m/12amd64-head-default/ref/.p SCRIPTPATH=/usr/local/share/poudriere/bulk.sh POUDRIEREPATH=/usr/local/bin/poudriere ---End Environment--- [...] c++ -Wl,-rpath=/usr/local/lib/gcc9 -Wl,-O1 -pthread -shared -Wl,-soname,libwkhtmltox.so.0 -o libwkhtmltox.so.0.12.5 loadsettings.o logging.o multipageloader.o tempfile.o converter.o websettings.o reflect.o utilities.o pdfsettings.o pdfconverter.o outline.o tocstylesheet.o imagesettings.o imageconverter.o pdf_c_bindings.o image_c_bindings.o moc_multipageloader_p.o moc_converter_p.o moc_pdfconverter_p.o moc_imageconverter_p.o moc_pdf_c_bindings_p.o moc_image_c_bindings_p.o moc_converter.o moc_multipageloader.o moc_utilities.o moc_pdfconverter.o moc_imageconverter.o qrc_wkhtmltopdf.o -L/usr/local/lib -L/wrkdirs/usr/ports/converters/wkhtmltopdf/work/wkhtmltopdf-0.12.5/build/qt/lib -L/wrkdirs/usr/ports/converters/wkhtmltopdf/work/wkhtmltopdf-0.12.5/build/qt/plugins/codecs -lqcncodecs -L/wrkdirs/usr/ports/converters/wkhtmltopdf/work/wkhtmltopdf-0.12.5/build/qt/lib -L/usr/local/lib -lqjpcodecs -lqkrcodecs -lqtwcodecs -lQtWebKit -lQtSvg -lQtXmlPatterns -lQtGui -ljpeg -lpng -lXrender -lfontconfig -lfreetype -lXext -lX11 -lQtNetwork -lssl -lcrypto -lQtCore -lz -lm ld: error: unable to find library -lQtWebKit c++: error: linker command failed with exit code 1 (use -v to see invocation) gmake[2]: *** [Makefile:164: ../../bin/libwkhtmltox.so.0.12.5] Error 1 gmake[2]: Leaving directory '/wrkdirs/usr/ports/converters/wkhtmltopdf/work/wkhtmltopdf-0.12.5/build/app/src/lib' gmake[1]: *** [Makefile:49: sub-src-lib-all-ordered] Error 2 gmake[1]: Leaving directory '/wrkdirs/usr/ports/converters/wkhtmltopdf/work/wkhtmltopdf-0.12.5/build/app' *** Error code 2 Stop. make: stopped in /usr/ports/converters/wkhtmltopdf
The linker line includes -L/usr/local/lib and www/qt5-webkit installs shared libraries in (LOCALBASE/): lib/qt5/libQt5WebKit.so lib/qt5/libQt5WebKit.so.5 lib/qt5/libQt5WebKit.so.5.212.0 Are the above libraries installed on the system? Or rather, do they get installed in the poudriere jail? (use testport -i to inspect jail) The last build on the official package builder (120amd64default) was also successful: http://beefy6.nyi.freebsd.org/data/120amd64-default/522623/logs/wkhtmltopdf-0.12.5_5.log
The problem is that qt5-webkit installs libQt5WebKit, but the link-path is looking for -lQtWebKit. I think the update to qt5-webkit 5.13.2 removed the compatibility symlink.
Created attachment 212561 [details] stable-12 build patch Looking at this more closely, it appears that wkhtmldopdf builds a local (patched) copy of Qt. The libQt5WebKit.so:www/qt5-webkit line in the Makefile is not required and has been removed. The configure script does not recognise *-g++*=9 from the USE_CXXSTD=gnu++98 directive. I've added "patch-configure" for this. On later versions of 12-STABLE, the base-system's compiler is used instead, and this makes "patch-mkspecs_common_gcc-base.conf" irrelevant, and is removed in this attachment. I am unsure what needs to be done on older versions of 12-STABLE and 11.
Thanks, testbuilds@work
The build was successful on cur-amd64, but failed on cur-i386: https://people.freebsd.org/~pi/logs/wkhtmltopdf-on-cur-i386.txt Any ideas ?
There's an error buried in there: /wrkdirs/usr/ports/converters/wkhtmltopdf/work/qt-5db36ec/src/gui/kernel/qx11embed_x11.cpp:486:20: error: non-constant-expression cannot be narrowed from type 'unsigned int' to 'long' in initializer list [-Wc++11-narrowing] long data[] = {XEMBED_VERSION, XEMBED_MAPPED}; ^~~~~~~~~~~~~~ /wrkdirs/usr/ports/converters/wkhtmltopdf/work/qt-5db36ec/src/gui/kernel/qx11embed_x11.cpp:486:20: note: insert an explicit cast to silence this issue which is I suspect is 32-bit vs 64-bit issue. I wonder if it's safe to remove the [-Wc++11-narrowing] flag...
Out of curiousity, why is "unsigned int" to "long" considered "narrowing"? I would understand the error if it was the other way round.
(In reply to Jonathan Chen from comment #7) On i386, and all other 32-bit platforms we support, sizeof(long) is sizeof(int), so unsigned int is the same as unsigned long, and int is the same as long. So unsigned int to long is, in fact, narrowing.
I'm reluctant to add patches for explicit casts in what could be possibly quite a few places in the code-base. Is it time to mark this port BROKEN_i386 as well?
(In reply to Jonathan Chen from comment #9) It might suffice to add -Wno-c++11-narrowing to the CFLAGS for the port.
(In reply to Justin Hibbits from comment #10) Kurt, you want to try this? I don't have access to i386 machines for a test-build.
The build with poudriere still fails on the same error as reported initially. =>> Building converters/wkhtmltopdf build started at Sun Apr 12 15:42:52 UTC 2020 port directory: /usr/ports/converters/wkhtmltopdf package name: wkhtmltopdf-0.12.5_5 building for: FreeBSD phost.name 12.1-STABLE FreeBSD 12.1-STABLE 1201512 amd64 maintained by: pi@FreeBSD.org Makefile ident: $FreeBSD: head/converters/wkhtmltopdf/Makefile 516745 2019-11-04 21:35:46Z zeising $ Poudriere version: 3.3.4 Host OSVERSION: 1300088 Jail OSVERSION: 1201512 Job Id: 04
You need to apply the patch first to overcome the basic build problem. The flag suggestion is _additional_ for i386 builds.
(In reply to O. Hartmann from comment #12) FYI, I still fail to find a combination of patches that fixes build on 13, 12 and 11.3, both amd and i386. The latest test is: https://people.freebsd.org/~pi/logs/wkhtmltopdf-curi.txt with 13-i386. Jonathan is trying to find solutions, but I fail to reproduce them 8-(
Any news on this? Fail's for FBSD 11.4 too now.
No progress, sorry - I'm not familiar enough with the compilers etc to propose a fix. I tried Jonathan's fixes, but they either failed on one or the other version of FreeBSD.
Created attachment 216445 [details] patch Update to 0.12.6, builds on current with a specific set of default versions: perl5=5.32 python=3.7 python3=3.7 ruby=2.7 pgsql=12 php=7.4 mysql=10.4m gcc=11 samba=4.11 lua=5.3 java=11 llvm=10 TODO: test if gcc=11 helps on other versions as well.
Comment on attachment 216445 [details] patch Solved by using GCC8 vs. current GCC9 My experience with wkhtmltopdf is that FreeBSD 11.3 i386 with clang 8 was the only version that compiled and ran fine. Short live helas. Mostly it did compile but produced 0Kb output files, so I always used GCC for it. I will explain all options I tried here that failed, so someone perhaps might know how to fix the issue under clang 10.0.0 I first looked at the release notes on the diff. between clang8 and 9 & 10. tried al possible -f and -W switches to emulate clang8 but failed. Then switched to gcc9 (current), came further and with all -f -W switches as permissive as possible incl. -fpermissive and -fabi-version=2 -fabi-compat-version=2 but still errored out on src/gui/dialogs/qpagesetupdialog_unix.cpp class 'Ui::QPageSetupWidget' has no member named etc. With -mMAKE_JOBS_UNSAFE=yes it ended in qprintdialog_unix.cpp Then found that someone running Linux had the same issue with gcc9 and could build it with gcc8. And presto, it works! Note: if you receive errors about Iconv not being installed or other dependencies, compile them as well under gcc. In fact I built my entire ports-tree under gcc now.
Comment on attachment 216445 [details] patch Solved by using GCC8 vs. current GCC9 My experience with wkhtmltopdf is that FreeBSD 11.3 i386 with clang 8 was the only version that compiled and ran fine. Short lived helas. Mostly it did compile but produced 0Kb output files, so I always used GCC for it. I will explain all options I tried here that failed, so someone perhaps might know how to fix the issue under clang 10.0.0 I first looked at the release notes on the diff. between clang8 and 9 & 10. tried al possible -f and -W switches to emulate clang8 but failed. Then switched to gcc9 (current), came further and with all -f -W switches as permissive as possible incl. -fpermissive and -fabi-version=2 -fabi-compat-version=2 but still errored out on src/gui/dialogs/qpagesetupdialog_unix.cpp class 'Ui::QPageSetupWidget' has no member named etc. With -mMAKE_JOBS_UNSAFE=yes it ended in qprintdialog_unix.cpp Then found that someone running Linux had the same issue with gcc9 and could build it with gcc8. And presto, it works! Note: if you receive errors about Iconv not being installed or other dependencies, compile them as well under gcc. In fact I built my entire ports-tree under gcc now.
Forgot to mention all my basic switches used: CFLAGS+=-fms-extensions -fcond-mismatch -flax-vector-conversions -Wall -Wextra -Wno-deprecated -Wno-deprecated-declarations -Wno-format -w CXXFLAGS+=-fvisibility-ms-compat -fpermissive also with and without the mentioned -fabi-* and also -fno-default-inline Note: I thougt that when I changed sentence "Short live helas" to "Short lived helas" and submitted it would change comment 18, not create a new comment 19 and I cannot find a delete button...
Final note, for compilation with gcc8 CFLAGS and CXXFLAGS are left at their default values. The mentioned custom values were used solely in the failed attempts with gcc9.
(In reply to Raymond Quakkelaar from comment #18) Can you elaborate ? Maybe with a patch ? How did you suceed to build it on every platform ?
(In reply to Kurt Jaeger from comment #22) I only tried and succeeded in compiling on FreeBSD 11.4 i386 with GCC-8 and the standard makefile without any changes! All other mentioned attempts with both clang-10 and GCC-9 (current) failed! And there have been many attempts with all sorts of combinations of CFLAGS, CXXFLAGS, USES_CXXSTD= and uses= compiler:(gcc-)c++(03|11|14|17)-(lib|lang) The reason I tried GCC-8 in the first place, was because I read someone experienced exactly the same problems running a Linux distro. 64-bit does compile and run normally with clang10 so I gather?
*** Bug 248171 has been marked as a duplicate of this bug. ***
Thanks for the point to gcc-8. I've testbuilt on 11.4i, 12.1a, cur-a and cur-i, and it looks promising. Testing on 11.3a and 12.1i still pending.
A commit references this bug: Author: pi Date: Thu Jul 23 01:34:05 UTC 2020 New revision: 542904 URL: https://svnweb.freebsd.org/changeset/ports/542904 Log: converters/wkhtmltopdf: update 0.12.5 -> 0.12.6, fix build - remove dependency on www/qt5-webkit - BREAKING CHANGE: block local filesystem access by default - pet portlint PR: 243349, 248039, 247556, 241397 Submitted by: r.quakkelaar@quaras.nl Reported by: ohartmann@walstatt.org, rs@bytecamp.net Reviewed by: jonc@chen.org.nz, jhibbits Relnotes: https://github.com/wkhtmltopdf/wkhtmltopdf/releases/tag/0.12.6 Changes: head/converters/wkhtmltopdf/Makefile head/converters/wkhtmltopdf/distinfo head/converters/wkhtmltopdf/files/patch-config.tests_unix_compile.test head/converters/wkhtmltopdf/files/patch-configure head/converters/wkhtmltopdf/files/patch-libcxx head/converters/wkhtmltopdf/files/patch-mkspecs_common_gcc-base.conf head/converters/wkhtmltopdf/files/patch-src__3rdparty__webkit__Source__JavaScriptCore__runtime__JSValueInlineMethods.h head/converters/wkhtmltopdf/files/patch-src__3rdparty__webkit__Source__JavaScriptCore__wtf__Atomics.h head/converters/wkhtmltopdf/files/patch-src__3rdparty__webkit__Source__WebKit__qt__QtWebKit.pro head/converters/wkhtmltopdf/pkg-plist
Committed, thanks!
A commit references this bug: Author: pi Date: Thu Jul 23 01:39:03 UTC 2020 New revision: 542905 URL: https://svnweb.freebsd.org/changeset/ports/542905 Log: MFH: r542904 converters/wkhtmltopdf: update 0.12.5 -> 0.12.6, fix build - remove dependency on www/qt5-webkit - BREAKING CHANGE: block local filesystem access by default - pet portlint PR: 243349, 248039, 247556, 241397 Submitted by: r.quakkelaar@quaras.nl Reported by: ohartmann@walstatt.org, rs@bytecamp.net Reviewed by: jonc@chen.org.nz, jhibbits Relnotes: https://github.com/wkhtmltopdf/wkhtmltopdf/releases/tag/0.12.6 Approved by: portmgr (build fix blanket) Changes: _U branches/2020Q3/ branches/2020Q3/converters/wkhtmltopdf/Makefile branches/2020Q3/converters/wkhtmltopdf/distinfo branches/2020Q3/converters/wkhtmltopdf/files/patch-config.tests_unix_compile.test branches/2020Q3/converters/wkhtmltopdf/files/patch-configure branches/2020Q3/converters/wkhtmltopdf/files/patch-libcxx branches/2020Q3/converters/wkhtmltopdf/files/patch-mkspecs_common_gcc-base.conf branches/2020Q3/converters/wkhtmltopdf/files/patch-src__3rdparty__webkit__Source__JavaScriptCore__runtime__JSValueInlineMethods.h branches/2020Q3/converters/wkhtmltopdf/files/patch-src__3rdparty__webkit__Source__JavaScriptCore__wtf__Atomics.h branches/2020Q3/converters/wkhtmltopdf/files/patch-src__3rdparty__webkit__Source__WebKit__qt__QtWebKit.pro branches/2020Q3/converters/wkhtmltopdf/pkg-plist
Created attachment 226276 [details] Solution for compile fail on 32-bit i386 combined with GCC9+! (In reply to commit-hook from comment #28) Found a solution for compile fail on 32-bit i386 combined with GCC9+! Tested on 11.4-STABLE i386 with GCC11. Basically I found a solution on Debian for the this problem: https://salsa.debian.org/qt-kde-team/qt/qt4-x11/commit/0d4a3dd61ccb156dee556c214dbe91c04d44a717 1. So I created a new patch file with the correct line numbers for the FreeBSD entries and named it: patch-gcc9-qforeach-qglobal.h (find attached) 2. I also deleted patch file patch-mkspecs_common_gcc-base.conf which contains a superfluous hard rpath link to gcc8 3. changed in Makefile: .if ${ARCH} == "i386" || ${ARCH} == "powerpc" || ${CHOSEN_COMPILER_TYPE} == gcc -USE_GCC= 8 +USE_GCC= yes .endif HAVE NOT VERIFIED EFFECTS ON COMPILE WITH CLANG OR 64-BIT!
(In reply to Raymond Quakkelaar from comment #29) testbuilds@work Please, for future patches for wkhtmltopdf, please create a new PR.