Bug 212859 - www/webkit-qt5: fails to build in presence of leveldb
Summary: www/webkit-qt5: fails to build in presence of leveldb
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-kde (group)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-20 16:01 UTC by Dmitry Marakasov
Modified: 2016-09-27 07:57 UTC (History)
1 user (show)

See Also:
rakuco: maintainer-feedback+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry Marakasov freebsd_committer freebsd_triage 2016-09-20 16:01:43 UTC
In presence of databases/leveldb:

c++ -Wl,--as-needed -fstack-protector -Wl,--no-undefined -Wl,--enable-new-dtags -pthread -Wl,-rpath,/usr/local/lib -shared -Wl,-Bsymbolic-functions -Wl,-soname,libQt5WebKit.so.5 -o libQt5WebKit.so.5.6.1   -L/usr/local/lib -lQt5Gui -L/usr/local/lib -lQt5Core -lQt5Network -L/usr/local/lib -lQt5Core -lQt5Core -L/usr/local/lib -Wl,-whole-archive -lWebKit1 -Wl,-no-whole-archive -L/wrkdirs/usr/ports/www/webkit-qt5/work/.build/Source/WebKit/release -Wl,-whole-archive -lWebKit2 -Wl,-no-whole-archive -L/wrkdirs/usr/ports/www/webkit-qt5/work/.build/Source/WebKit2/release -Wl,-whole-archive -lWebCore -Wl,-no-whole-archive -L/wrkdirs/usr/ports/www/webkit-qt5/work/.build/Source/WebCore/release -lz -lXrender -ljpeg -lpng -lwebp -Wl,-whole-archive -lANGLE -Wl,-no-whole-archive -L/wrkdirs/usr/ports/www/webkit-qt5/work/.build/Source/ThirdParty/ANGLE/release -Wl,-whole-archive -lleveldb -Wl,-no-whole-archive -L/wrkdirs/usr/ports/www/webkit-qt5/work/.build/Source/ThirdParty/leveldb/release -Wl,-whole-archive -lJavaScriptCore -Wl,-no-whole-archive -L/wrkdirs/usr/ports/www/webkit-qt5/work/.build/Source/JavaScriptCore/release -Wl,-whole-archive -lWTF -Wl,-no-whole-archive -L/wrkdirs/usr/ports/www/webkit-qt5/work/.build/Source/WTF/release -lpthread -lXext -lX11 -lm -lX11 -lxslt -lz -llzma -lm -lxml2 -lxml2 -lglib-2.0 -lintl -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lintl -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0 -lintl -lgstapp-1.0 -lgstbase-1.0 -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0 -lintl -lgstbase-1.0 -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0 -lintl -lgstpbutils-1.0 -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0 -lintl -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0 -lintl -lgstvideo-1.0 -lgstbase-1.0 -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0 -lintl -lgstaudio-1.0 -lgstbase-1.0 -lgstreamer-1.0 -lgobject-2.0 -lglib-2.0 -lintl -lsqlite3 -licui18n -licuuc -licudata -lQt5Quick -L/usr/local/lib -lQt5Qml -lQt5Gui -lQt5Network -lQt5Core -lQt5Qml -L/usr/local/lib -lQt5Network -lQt5Core -lQt5Network -L/usr/local/lib -lQt5Core -lQt5Gui -L/usr/local/lib -lQt5Core -lQt5Sql -L/usr/local/lib -lQt5Core -lQt5Core -L/usr/local/lib -lGL 
/wrkdirs/usr/ports/www/webkit-qt5/work/.build/Source/WebCore/release/libWebCore.a(LevelDBDatabase.o): In function `WebCore::LevelDBDatabase::openInMemory(WebCore::LevelDBComparator const*)':
/wrkdirs/usr/ports/www/webkit-qt5/work/qtwebkit-opensource-src-5.6.1/Source/WebCore/platform/leveldb/LevelDBDatabase.cpp:(.text+0x499): undefined reference to `leveldb::NewMemEnv(leveldb::Env*)'
c++: error: linker command failed with exit code 1 (use -v to see invocation)

Full log: https://people.freebsd.org/~amdmi3/webkit-qt5.log.bz2
Comment 1 Dmitry Marakasov freebsd_committer freebsd_triage 2016-09-20 17:09:35 UTC
You've probably already noticed, but the cause is likely -L${LOCALBASE}/lib before local -L's, so system libleveldb is linked instead of bundled one.
Comment 2 Raphael Kubo da Costa freebsd_committer freebsd_triage 2016-09-25 17:52:45 UTC
There are separate issues at play here:
* Our .qmake.cache hack in bsd.qt.mk doesn't work correctly with USES=qmake:outsource, as it uses ${WRKSRC} instead of ${BUILD_WRKSRC}, so it's creating the file in the wrong directly and passing the wrong value in -L.
* Even after that's fixed, the way leveldb is referenced when linking libQt5WebKit.so (-L/path/to/qt/libleveldb.a's/location -Wl,-whole-archive -lleveldb -Wl,-no-whole-archive) makes ld use liblevel.so if it's available.
* We should actually  be using the system's leveldb anyway instead of using a bundled dependency. However, the databases/leveldb port installs memenv.h into ${LOCALBASE}/include/memenv/memenv.h instead of ${LOCALBASE}/include/leveldb/memenv/memenv.h. Qt's configuration code expects the latter, not the former, so it's never able to detect leveldb is installed.
Comment 3 commit-hook freebsd_committer freebsd_triage 2016-09-26 17:44:38 UTC
A commit references this bug:

Author: rakuco
Date: Mon Sep 26 17:44:09 UTC 2016
New revision: 422785
URL: https://svnweb.freebsd.org/changeset/ports/422785

Log:
  bsd.qt.mk: Use CONFIGURE_WRKSRC instead of WRKSRC in the .qmake.cache hack

  WRKSRC is not what we want here: when USES=qmake:outsource is used (such as
  in www/webkit-qt5), the build actually takes place in ${WRKDIR}/.build, so
  we were creating .qmake.cache in the wrong location and passing the wrong
  directory to the linker via -L. With CONFIGURE_WRKSRC, we get the right
  value regardless of whether :outsource is used or not.

  PR:		212859
  Reviewed by:    tcberner
  MFH:            2016Q3

Changes:
  head/Mk/bsd.qt.mk
Comment 4 commit-hook freebsd_committer freebsd_triage 2016-09-27 07:08:38 UTC
A commit references this bug:

Author: rakuco
Date: Tue Sep 27 07:08:20 UTC 2016
New revision: 422803
URL: https://svnweb.freebsd.org/changeset/ports/422803

Log:
  Fix some configuration test failures and use the system LevelDB port

  These are fixes for two separate issues (even though fixing the latter
  depends on fixing the former), but they are being landed together to avoid
  having to bump PORTREVISION twice.

  1. r411689 ("Drop USES=gmake") caused a regression where several
     configuration tests (glx, libXcomposite, libXrender and leveldb) were
     failing even though they should not.
     The .pro files for those tests all have "OBJECTS_DIR = obj", which causes
     qmake to create this subdirectory when generating the test's Makefile and
     put object files there. The problem is that make(1) always tries to cd
     into this directory (among others in case MAKEOBJDIRPREFIX or MAKEOBJDIR
     are set), so the compiler was being invoked like this:

         c++ -o obj/foo.o /path/to/foo.cpp

     from _within_ obj/ itself, causing the compiler to fail. Readding
     USES=gmake is an option, but it causes the build to take a lot longer, so
     the approach I ended up adopting is to patch the .pro files and remove
     the OBJECTS_DIR lines.
     Fixing this enables a few more graphics-related configuration options
     ("graphics_surface" and "glx").

  2. The port was always failing to build if databases/leveldb was installed.
     Because we were not depending on databases/leveldb and also because of
     the item above, we were always building WebKit's bundled LevelDB copy as
     a static library and linking it into libQt5WebKit.so. However, the way
     the linker was invoked was always causing the system-wide libleveldb.so
     to be used instead:

         c++ -o libQt5WebKit.so -Wl,-whole-archive -lleveldb -Wl,-no-whole-archive -L/path/to/static/leveldb [...]

     Since there is no reason to use a bundled dependency anyway, it is easier
     to just make the build use the system-wide LevelDB. Doing so does require
     some patching though, as the LevelDB port installs the memenv.h header
     into a location that differs from the one WebKit expects.

  PR:		212859
  Reviewed by:	tcberner
  MFH:		2016Q3

Changes:
  head/www/webkit-qt5/Makefile
  head/www/webkit-qt5/files/patch-Source_WebCore_platform_leveldb_LevelDBDatabase.cpp
  head/www/webkit-qt5/files/patch-Tools_qmake_config.tests_glx_glx.pro
  head/www/webkit-qt5/files/patch-Tools_qmake_config.tests_leveldb_leveldb.cpp
  head/www/webkit-qt5/files/patch-Tools_qmake_config.tests_leveldb_leveldb.pro
  head/www/webkit-qt5/files/patch-Tools_qmake_config.tests_libXcomposite_libXcomposite.pro
  head/www/webkit-qt5/files/patch-Tools_qmake_config.tests_libXrender_libXrender.pro