qt5webkit: fix build issue using system leveldb
cover qt5webkit: fix build issue using system leveldb
Hi all,
This patchset fixes the build issue reported by autobuilder [0].
The issue happens when the package leveldb is enabled.
QtWebKit builds its own copy of leveldb [1] if it is not provided by the system (i.e. buildroot). It builds it differently and this is the origin of that issue. Instead of using the Makefile provided by leveldb [2], QtWebKit uses qmake to build that library [3].
/home/naourr/work/instance-2/output/build/qt5webkit-5.9.1/Source/WebCore//.obj/platform/leveldb/LevelDBDatabase.o: In function `WebCore::LevelDBDatabase::openInMemory(WebCore::LevelDBComparator const*)':LevelDBDatabase.cpp.text._ZN7WebCore15LevelDBDatabase12openInMemoryEPKNS_17LevelDBComparatorE+0x34): undefined reference to `leveldb::NewMemEnv(leveldb::Env*)'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile.api:97: ../lib/libQt5WebKit.so.5.9.1] Error 1
The missing symbol issue happens because the symbol leveldb::NewMemEnv is shipped in a static library named libmemenv.a (aside libleveldb.so) and that static library is *NOT* installed in the staging directory. Unfortunatly, that symbol is required latter by WebCore [4].
Note that the copy built by QtWebKit is an all-in-one library including both libleveldb and libmemenv *AND* thus QtWebKit links against libleveldb only. Also, note that the linker finds the buildroot's copy first; not its internal copy. That explains why it is complaining about a missing symbol.
Fortunatly, QtWebKit provides a facility to link against the system leveldb package. The qmake flag WEBKIT_CONFIG+=use_system_leveldb tells Qt5WebKit to link against libleveldb *AND* libmemenv [5].
To fix that issue, this patchset builds the leveldb package and tells QtWebKit to use it instead of building its own copy.
The first two patches concern the leveldb package.
The first one adds installation of headers and the missing static library in the staging directory.
The second one patches leveldb to generate position independant code for the static library libmemenv.a; in order let it linkable by the Qt5WebKit module. Without that patch, the build raises the error below:
/home/gportay/src/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-amd-linux-gnu/6.2.0/../../../../x86_64-amd-linux-gnu/bin/ld: /home/gportay/src/buildroot/output/host/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libmemenv.a(memenv.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC /home/gportay/src/buildroot/output/host/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libmemenv.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
It it not relevant to upstream that patch since the project has already moved to cmake [6] for the (upcoming?) version 1.21. Backporting the upstreamed patches was way too complicated.
The last patch selects the leveldb package in qt5webkit package and sets the appropriate qmake flag to tell it to use the package provided by buildroot.
[0]: http://autobuild.buildroot.net/results/8afc8771741f62da3b2117d2124d1c6f2d941903/
[1]: https://github.com/qt/qtwebkit/tree/5.9/Source/ThirdParty/leveldb
[2]: https://github.com/qt/qtwebkit/blob/5.9/Source/ThirdParty/leveldb/Makefile#L167-L169
[3]: https://github.com/qt/qtwebkit/blob/5.9/Source/ThirdParty/leveldb/Target.pri#L80
[4]: https://github.com/qt/qtwebkit/blob/5.9/Source/WebCore/platform/leveldb/LevelDBDatabase.cpp#L185
[5]: https://github.com/qt/qtwebkit/blob/5.9/Source/WebCore/WebCore.pri#L254
[6]: https://github.com/google/leveldb/commit/739c25100e46576cdcdfff2d6f43f9f7008103c7
Regards,
Ga?l PORTAY (3):
leveldb: install memenv static library and headers
leveldb: generate pic for static libraries
qt5webkit: select leveldb package
...sition-independant-code-for-static-librar.patch | 52 ++++++++++++++++++++++ package/leveldb/leveldb.mk | 2 + package/qt5/qt5webkit/Config.in | 3 ++ package/qt5/qt5webkit/qt5webkit.mk | 4 +- 4 files changed, 59 insertions(+), 2 deletions(-) create mode 100644 package/leveldb/0001-Generate-position-independant-code-for-static-librar.patch
Signature · 1 line
2.11.0
PATCH 1/3 leveldb: install memenv static library and headers
--- package/leveldb/leveldb.mk | 2 ++ 1 file changed, 2 insertions(+)
package/leveldb/leveldb.mk +2 -0
@@ -25,6 +25,8 @@ define LEVELDB_INSTALL_STAGING_CMDS $(TARGET_MAKE_ENV) $(MAKE) \ INSTALL_ROOT=$(STAGING_DIR) INSTALL_PREFIX=/usr \ $(LEVELDB_MAKE_ARGS) -C $(@D) install + $(INSTALL) -m 0644 $(@D)/out-static/libmemenv.a $(STAGING_DIR)/usr/lib + cp -dpfr $(@D)/helpers $(STAGING_DIR)/usr/include endef define LEVELDB_INSTALL_TARGET_CMDS
Signature · 1 line
2.11.0
PATCH 2/3 leveldb: generate pic for static libraries
In reply to Gaël PORTAY--- ...sition-independant-code-for-static-librar.patch | 52 ++++++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 package/leveldb/0001-Generate-position-independant-code-for-static-librar.patch
package/leveldb/0001-Generate-position-independant-code-for-static-librar.patch new file +52 -0
@@ -0,0 +1,52 @@ +From 6ed1b57ef6bcee0d497c181730710b2b0fafbfb3 Mon Sep 17 00:00:00 2001 +From: =?utf-8?q?Ga=C3=ABl=20PORTAY?= <[email protected]> +Date: Fri, 31 Aug 2018 12:23:46 -0400 +Subject: [PATCH] Generate position independant code for static library +MIME-Version: 1.0 +Content-Type: text/plain; charset=utf-8 +Content-Transfer-Encoding: 8bit + +Currently, only shared libraries are using the PIC flag. + +Generalize this flag for static libraries in order to let them linkable +by dynamic libraries. + +Fixes: + + /home/gportay/src/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-amd-linux-gnu/6.2.0/../../../../x86_64-amd-linux-gnu/bin/ld: /home/gportay/src/buildroot/output/host/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libmemenv.a(memenv.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC + /home/gportay/src/buildroot/output/host/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libmemenv.a: error adding symbols: Bad value + collect2: error: ld returned 1 exit status + +Upstream-Status: Inappropriate [upstream has migrated to cmake] +Signed-off-by: Ga?l PORTAY <[email protected]> +--- + build_detect_platform | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +diff --git a/build_detect_platform b/build_detect_platform +index d2a20ce..4839444 100755 +--- a/build_detect_platform ++++ b/build_detect_platform +@@ -55,8 +55,8 @@ fi + + COMMON_FLAGS= + CROSS_COMPILE= +-PLATFORM_CCFLAGS= +-PLATFORM_CXXFLAGS= ++PLATFORM_CCFLAGS="-fPIC" ++PLATFORM_CXXFLAGS="-fPIC" + PLATFORM_LDFLAGS= + PLATFORM_LIBS= + PLATFORM_SHARED_EXT="so" +@@ -197,7 +197,7 @@ else + EOF + if [ "$?" = 0 ]; then + COMMON_FLAGS="$COMMON_FLAGS -DLEVELDB_PLATFORM_POSIX -DLEVELDB_ATOMIC_PRESENT" +- PLATFORM_CXXFLAGS="-std=c++0x" ++ PLATFORM_CXXFLAGS="$PLATFORM_CXXFLAGS -std=c++0x" + else + COMMON_FLAGS="$COMMON_FLAGS -DLEVELDB_PLATFORM_POSIX" + fi +-- +2.18.0 +
Signature · 1 line
2.11.0
PATCH 3/3 qt5webkit: select leveldb package
In reply to Gaël PORTAYQtWebKit may build its own copy of leveldb.
Select leveldb package and build the buildroot's copy instead.
--- package/qt5/qt5webkit/Config.in | 3 +++ package/qt5/qt5webkit/qt5webkit.mk | 4 ++-- 2 files changed, 5 insertions(+), 2 deletions(-)
package/qt5/qt5webkit/Config.in +3 -0
@@ -3,10 +3,13 @@ config BR2_PACKAGE_QT5WEBKIT depends on !BR2_STATIC_LIBS depends on BR2_PACKAGE_QT5_JSCORE_AVAILABLE depends on BR2_HOST_GCC_AT_LEAST_4_8 # icu + depends on BR2_INSTALL_LIBSTDCPP # leveldb depends on BR2_TOOLCHAIN_GCC_AT_LEAST_4_8 # icu + depends on BR2_TOOLCHAIN_HAS_THREADS # leveldb depends on !BR2_BINFMT_FLAT # icu # assumes a FPU is available on MIPS depends on !BR2_MIPS_SOFT_FLOAT + select BR2_PACKAGE_LEVELDB select BR2_PACKAGE_QT5BASE select BR2_PACKAGE_QT5BASE_ICU select BR2_PACKAGE_QT5BASE_GUI
package/qt5/qt5webkit/qt5webkit.mk +2 -2
@@ -16,7 +16,7 @@ endif QT5WEBKIT_SOURCE = qtwebkit-opensource-src-$(QT5WEBKIT_VERSION).tar.xz QT5WEBKIT_DEPENDENCIES = \ host-bison host-flex host-gperf host-python host-ruby \ - qt5base sqlite + leveldb qt5base sqlite QT5WEBKIT_INSTALL_STAGING = YES QT5WEBKIT_LICENSE_FILES = Source/WebCore/LICENSE-LGPL-2 Source/WebCore/LICENSE-LGPL-2.1
@@ -45,7 +45,7 @@ endef QT5WEBKIT_PRE_CONFIGURE_HOOKS += QT5WEBKIT_PYTHON2_SYMLINK define QT5WEBKIT_CONFIGURE_CMDS - (cd $(@D); $(TARGET_MAKE_ENV) $(QT5WEBKIT_ENV) $(HOST_DIR)/bin/qmake) + (cd $(@D); $(TARGET_MAKE_ENV) $(QT5WEBKIT_ENV) $(HOST_DIR)/bin/qmake WEBKIT_CONFIG+=use_system_leveldb) endef define QT5WEBKIT_BUILD_CMDS
Signature · 1 line
2.11.0
PATCH 3/3 qt5webkit: select leveldb package
package/qt5/qt5webkit/Config.in config BR2_PACKAGE_QT5WEBKIT · line 6
Quoted 1 line · Ga?l PORTAY
package/qt5/qt5webkit/Config.in +1
-0+ depends on BR2_INSTALL_LIBSTDCPP # leveldb
I don't think we need to propagate this particular dependency - qt5webkit
already depends on libstdcpp indirectly through Qt5.
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 3/3 qt5webkit: select leveldb package
Hello,
Quoted 5 lines · Arnout Vandecappelle
package/qt5/qt5webkit/Config.in config BR2_PACKAGE_QT5WEBKIT · line 6
Quoted 1 line · Ga?l PORTAY
package/qt5/qt5webkit/Config.in +1
-0+ depends on BR2_INSTALL_LIBSTDCPP # leveldbI don't think we need to propagate this particular dependency - qt5webkit
already depends on libstdcpp indirectly through Qt5.
I think we need at some point to define a real policy for this. When a dependency is redundant, should we:
(1) Avoid duplicating it, to simplify things, but with the risk that if we remove the dependency at a higher-level, we forget to re-add back to the sub-options.
(2) Always duplicate them, even if they are useless right now, so that we don't forget them in the future if the higher-level option drops this dependency. Drawback of this solution is that such dependencies don't get "exercised" by autobuilder testing so they are often wrong.
I don't have a strong opinion, but we're doing (1) or (2) depending on the package developer and/or situation, and this isn't really nice.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
cover qt5webkit: fix build issue using system leveldb
In reply to Gaël PORTAYHello,
First of all: there are a *lot* of explanations in the cover letter, but your commit logs are almost empty. The cover letter is lost in the mailing list archives, while the commit logs are nicely preserved in the Git history. Therefore, we want more explanations in the commit logs!
Quoted 2 lines · Ga?l PORTAY
QtWebKit builds its own copy of leveldb [1] if it is not provided by the system (i.e. buildroot).
And indeed, using the leveldb library built by the leveldb Buildroot package is better.
Quoted 9 lines
It builds it differently and this is the origin of that
issue. Instead of using theMakefileprovided by leveldb [2], QtWebKit uses qmake to build that library [3].
/home/naourr/work/instance-2/output/build/qt5webkit-5.9.1/Source/WebCore//.obj/platform/leveldb/LevelDBDatabase.o: In function `WebCore::LevelDBDatabase::openInMemory(WebCore::LevelDBComparator const*)':LevelDBDatabase.cpp.text._ZN7WebCore15LevelDBDatabase12openInMemoryEPKNS_17LevelDBComparatorE+0x34): undefined reference to `leveldb::NewMemEnv(leveldb::Env*)'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile.api:97: ../lib/libQt5WebKit.so.5.9.1] Error 1
Quoted 4 lines
The missing symbol issue happens because the symbol
leveldb::NewMemEnvis shipped in a static library named libmemenv.a (aside libleveldb.so) and that static library is *NOT* installed in the staging directory. Unfortunatly, that symbol is required latter by WebCore [4].
latter -> later.
Is it libleveldb.so itself that uses this symbol, or a separate part of WebCore that directly uses some leveldb internals ?
Quoted 9 lines
Note that the copy built by QtWebKit is an all-in-one library including both libleveldb and libmemenv *AND* thus QtWebKit links against libleveldb only. Also, note that the linker finds the buildroot's copy first; not its internal copy. That explains why it is complaining about a missing symbol.
Fortunatly, QtWebKit provides a facility to link against the system leveldb package. The qmake flag WEBKIT_CONFIG+=use_system_leveldb tells Qt5WebKit to link against libleveldb *AND* libmemenv [5].
Quoted 7 lines
To fix that issue, this patchset builds the leveldb package and tells QtWebKit to use it instead of building its own copy.
The first two patches concern the leveldb package.
The first one adds installation of headers and the missing static library in the staging directory.
I am a bit uneasy about this one, it seems to install "internal" stuff of leveldb that are normally not meant to be installed. Do you/we understand what this internal stuff, beyond just "it fixes qt5webkit" ?
Quoted 2 lines
The second one patches leveldb to generate position independant code for the static library libmemenv.a; in order let it linkable by the Qt5WebKit module.
OK, I guess this is reasonable. We don't really build twice the object files so that the .a object files are non-PIC and the .so object files are PIC.
All in all, I'm just worried by the installation of what looks like some internal library/headers of leveldb. Could you comment on this ?
Thanks!
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
cover qt5webkit: fix build issue using system leveldb
Thomas,
Quoted 8 lines · Thomas Petazzoni
Hello,
First of all: there are a *lot* of explanations in the cover letter, but your commit logs are almost empty. The cover letter is lost in the mailing list archives, while the commit logs are nicely preserved in the Git history. Therefore, we want more explanations in the commit logs!
I knew you would says something about that. I sent the patch serie as soon as possible for a review. I think you may want it for the upcoming release.
The thing is, I did not know how to properly arrange my commits :/ I did not want to mention something about qt5webkit in patches related to leveldb.
Maybe, I can add the content of the coverletter in the commit message of the last patch and reword a bit.
Quoted 7 lines · Ga?l PORTAY
(...)
Is it libleveldb.so itself that uses this symbol, or a separate part of WebCore that directly uses some leveldb internals ?
It is WebCore that use directly that symbol; libleveldb does not.
Quoted 12 lines
Quoted 12 lines
Note that the copy built by QtWebKit is an all-in-one library including both libleveldb and libmemenv *AND* thus QtWebKit links against libleveldb only. Also, note that the linker finds the buildroot's copy first; not its internal copy. That explains why it is complaining about a missing symbol.
Fortunatly, QtWebKit provides a facility to link against the system leveldb package. The qmake flag WEBKIT_CONFIG+=use_system_leveldb tells Qt5WebKit to link against libleveldb *AND* libmemenv [5].
To fix that issue, this patchset builds the leveldb package and tells QtWebKit to use it instead of building its own copy.
Quoted 9 lines
Quoted 4 lines
The first two patches concern the leveldb package.
The first one adds installation of headers and the missing static library in the staging directory.
I am a bit uneasy about this one, it seems to install "internal" stuff of leveldb that are normally not meant to be installed. Do you/we understand what this internal stuff, beyond just "it fixes qt5webkit" ?
This static library consists of this *VERY SINGLE* symbol which is like an extra that is not shipped at installation.
Apparently WebKit see value in that function and has decided to use it [1].
As QtWebKit bundled the leveldb third-party to build WebKit, it rewrote the way how to build it (i.e. not using Makefile) in order to use qmake build system.
As that "Makefile" has been rewritten, QtWebKit has included this symbol directly to libleveldb.so to link against this library *ONLY* (which looks an error to me).
Later, QtWebKit has provided a configure option to use the libleveldb.so provided by the system (i.e. to disable the included third-party). This option links Qt5WebKit.so with both libleveldb.so and libmemenv.a libraries.
Is it more clear?
Note: Also, since leveldb has moved to cmake, this symbol is now a part of libleveldb.so and there is not more libmemenv.a [2] :/
Quoted 5 lines
(...)
All in all, I'm just worried by the installation of what looks like some internal library/headers of leveldb. Could you comment on this ?
We can consider memenv as an option of leveldb which installs the memenv development files (static library and header).
Then, QtWebKit will select that option because it requires memenv to be installed to successfully build itself.
Which probably looks like:
if BR2_PACKAGE_LEVELDB
config BR2_PACKAGE_LEVELDB_MEMENV
bool "memenv"
default n
help
Installs memenv static library and header to create in-memory LevelDB database.
endif
Quoted 3 lines
Thanks!
Thomas
[1]: https://github.com/qt/qtwebkit/blob/5.6/Source/WebCore/platform/leveldb/LevelDBDatabase.cpp#185
[2]: https://github.com/google/leveldb/blob/739c25100e46576cdcdfff2d6f43f9f7008103c7/CMakeLists.txt#L181-L186
Regards,
Ga?l
cover qt5webkit: fix build issue using system leveldb
Quoted 3 lines · Ga?l PORTAY
Thomas,
On Fri, Aug 31, 2018 at 11:19:30PM +0200, Thomas Petazzoni wrote:
[snip]
Quoted 24 lines
Quoted 4 lines
I am a bit uneasy about this one, it seems to install "internal" stuff of leveldb that are normally not meant to be installed. Do you/we understand what this internal stuff, beyond just "it fixes qt5webkit" ?
This static library consists of this *VERY SINGLE* symbol which is like an extra that is not shipped at installation.
Apparently WebKit see value in that function and has decided to use it [1].
As QtWebKit bundled the leveldb third-party to build WebKit, it rewrote the way how to build it (i.e. not using
Makefile) in order to use qmake build system.As that "
Makefile" has been rewritten, QtWebKit has included this symbol directly to libleveldb.so to link against this library *ONLY* (which looks an error to me).Later, QtWebKit has provided a configure option to use the libleveldb.so provided by the system (i.e. to disable the included third-party). This option links Qt5WebKit.so with both libleveldb.so and libmemenv.a libraries.
Quoted 4 lines
Is it more clear?
Note: Also, since leveldb has moved to cmake, this symbol is now a part of libleveldb.so and there is not more libmemenv.a [2] :/
So, wouldn't a bump of leveldb which moves to cmake solve the issue entirely?
Quoted 9 lines
Quoted 6 lines
(...)
All in all, I'm just worried by the installation of what looks like some internal library/headers of leveldb. Could you comment on this ?
We can consider memenv as an option of leveldb which installs the memenv development files (static library and header).
Since it's only a static library and a header, it only gets installed to
staging, not target, so there is no reason to make it optional.
Regards,
Arnout
[snip]
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
cover qt5webkit: fix build issue using system leveldb
Arnout,
Quoted 7 lines · Arnout Vandecappelle
(...)
Quoted 2 lines
Note: Also, since leveldb has moved to cmake, this symbol is now a part of libleveldb.so and there is not more libmemenv.a [2] :/
So, wouldn't a bump of leveldb which moves to cmake solve the issue entirely?
First of all, the version is not yet out (1.21).
I think, the bump will partially solve that issue (not tested, but I can give it a try).
With the bump, QtWebKit would compile it as a third-party (fair but not wanted) and would link against libleveldb.so which will be provided by buildroot (1.21 with the missing symbol). In that situation, the third-party is compiled but not used and the build will succeed.
If the configure flag WEBKIT_CONFIG+=use_system_leveldb is added, QtWebKit would not compile leveldb as a third-party (wanted) but it would try to link against libraries liblevel.db (okay) *AND* libmemenv.a from buildroot's staging. But the last one will not exist and the compilation would fail.
Even with the bump, (and if the configure flag is added) QtWebKit needs to be patched to remove the -lmemenv from the compilation line; because the libmemenv will disappear.
A good fix consists in to force QtWebKit to use its third-party library (giving the full path?) so it will not link against the copy from buildroot's staging.
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
(...)
All in all, I'm just worried by the installation of what looks like some internal library/headers of leveldb. Could you comment on this ?
Quoted 6 lines
Quoted 2 lines
We can consider memenv as an option of leveldb which installs the memenv development files (static library and header).
Since it's only a static library and a header, it only gets installed to
staging, not target, so there is no reason to make it optional.
Okay, I will drop the option and respin a new version.
Quoted 4 lines
Regards,
Arnout
Quoted 9 lines
[snip]
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
Regards,
Ga?l
cover qt5webkit: fix build issue using system leveldb
Quoted 5 lines · Ga?l PORTAY
Arnout,
Quoted 2 lines · Arnout Vandecappelle
(...)
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
Note: Also, since leveldb has moved to cmake, this symbol is now a part of libleveldb.so and there is not more libmemenv.a [2] :/
So, wouldn't a bump of leveldb which moves to cmake solve the issue entirely?
First of all, the version is not yet out (1.21).
OK, so we will not bump as a way to solve this issue. But the patch may be
reverted (or changed) after a leveldb bump.
Quoted 9 lines
I think, the bump will partially solve that issue (not tested, but I can give it a try).
With the bump, QtWebKit would compile it as a third-party (fair but not wanted) and would link against libleveldb.so which will be provided by buildroot (1.21 with the missing symbol). In that situation, the third-party is compiled but not used and the build will succeed.
Quoted 5 lines
If the configure flag WEBKIT_CONFIG+=use_system_leveldb is added, QtWebKit would not compile leveldb as a third-party (wanted) but it would try to link against libraries liblevel.db (okay) *AND* libmemenv.a from buildroot's staging. But the last one will not exist and the compilation would fail.
In other words, after the leveldb bump, we'll still need patch 3/3 to avoid
building the bundled leveldb, *and* we need to add a patch to QtWebKit to avoid linking with libmemenv. Gee...
Quoted 7 lines
Even with the bump, (and if the configure flag is added) QtWebKit needs to be patched to remove the -lmemenv from the compilation line; because the libmemenv will disappear.
A good fix consists in to force QtWebKit to use its third-party library (giving the full path?) so it will not link against the copy from buildroot's staging.
Ugh no we want to avoid bundled libraries.
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
(...)
All in all, I'm just worried by the installation of what looks like some internal library/headers of leveldb. Could you comment on this ?
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
We can consider memenv as an option of leveldb which installs the memenv development files (static library and header).
Since it's only a static library and a header, it only gets installed to
staging, not target, so there is no reason to make it optional.Okay, I will drop the option and respin a new version.
Er, your current iteration doesn't have it as an option...
Regards,
Arnout
Quoted 18 lines
Quoted 14 lines
Regards,
Arnout[snip]
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDFRegards,
Ga?l
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF