Bug 243349 - converters/wkhtmltopdf: Fails to link: ld: error: unable to find library -lQtWebKit
Summary: converters/wkhtmltopdf: Fails to link: ld: error: unable to find library -lQt...
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Kurt Jaeger
Keywords: needs-qa
Depends on:
Reported: 2020-01-14 05:15 UTC by O. Hartmann
Modified: 2020-04-08 00:00 UTC (History)
3 users (show)

See Also:
bugzilla: maintainer-feedback? (pi)

stable-12 build patch (2.10 KB, patch)
2020-03-20 23:10 UTC, Jonathan Chen
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description O. Hartmann 2020-01-14 05:15:17 UTC
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---
UNAME_v=FreeBSD 12.1-STABLE 1201509
---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

make: stopped in /usr/ports/converters/wkhtmltopdf
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2020-01-14 05:22:48 UTC
The linker line includes -L/usr/local/lib and www/qt5-webkit installs shared libraries in (LOCALBASE/):


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:

Comment 2 Jonathan Chen 2020-03-07 23:43:48 UTC
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.
Comment 3 Jonathan Chen 2020-03-20 23:10:36 UTC
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.
Comment 4 Kurt Jaeger freebsd_committer 2020-03-21 17:10:17 UTC
Thanks, testbuilds@work
Comment 5 Kurt Jaeger freebsd_committer 2020-03-21 17:24:49 UTC
The build was successful on cur-amd64, but failed on cur-i386:


Any ideas ?
Comment 6 Jonathan Chen 2020-03-21 19:37:48 UTC
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...
Comment 7 Jonathan Chen 2020-03-21 19:46:44 UTC
Out of curiousity, why is "unsigned int" to "long" considered "narrowing"? I would understand the error if it was the other way round.
Comment 8 Justin Hibbits freebsd_committer 2020-04-01 01:59:04 UTC
(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.
Comment 9 Jonathan Chen 2020-04-01 02:04:39 UTC
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?
Comment 10 Justin Hibbits freebsd_committer 2020-04-07 19:53:56 UTC
(In reply to Jonathan Chen from comment #9)

It might suffice to add -Wno-c++11-narrowing to the CFLAGS for the port.
Comment 11 Jonathan Chen 2020-04-08 00:00:03 UTC
(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.