[v2] libsolv: don't pick up bundled db from host rpm

Submitted by Max Krummenacher on May 26, 2017, 8:35 p.m. | Patch ID: 140225

Details

Message ID 20170526203537.30721-1-max.krummenacher@toradex.com
State New
Headers show

Commit Message

Max Krummenacher May 26, 2017, 8:35 p.m.
With rpm v4 in openembedded but on a host with existing /usr/include/rpm/db.h
the native build fails to compile.

Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
---
 ...01-don-t-pick-up-bundled-db-from-host-rpm.patch | 43 ++++++++++++++++++++++
 meta/recipes-extended/libsolv/libsolv_0.6.27.bb    |  3 +-
 2 files changed, 45 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-extended/libsolv/libsolv/0001-don-t-pick-up-bundled-db-from-host-rpm.patch

Patch hide | download patch | download mbox

diff --git a/meta/recipes-extended/libsolv/libsolv/0001-don-t-pick-up-bundled-db-from-host-rpm.patch b/meta/recipes-extended/libsolv/libsolv/0001-don-t-pick-up-bundled-db-from-host-rpm.patch
new file mode 100644
index 0000000..41656fa
--- /dev/null
+++ b/meta/recipes-extended/libsolv/libsolv/0001-don-t-pick-up-bundled-db-from-host-rpm.patch
@@ -0,0 +1,43 @@ 
+From d5ff23ec64bc8b79d5335a2e0cd4b481b63fd95f Mon Sep 17 00:00:00 2001
+From: Max Krummenacher <max.krummenacher@toradex.com>
+Date: Sun, 7 May 2017 20:28:11 +0100
+Subject: [PATCH] don't pick up bundled db from host rpm
+
+For libsolv-native with rpm v4 in openembedded but on a host with
+existing /usr/include/rpm/db.h the build is configured to have
+HAVE_RPM_DB_H because of the existing header file from the host,
+but linking against the librpm.so in recipe-sysroot-native fails.
+
+Skip the check for rpm/db.h and assume that rpm is provided without
+a bundled berkley db.
+
+Fixes the following link errors:
+| ../ext/libsolvext.so.0: undefined reference to `db_create_rpmdb'
+| ../ext/libsolvext.so.0: undefined reference to `db_env_create_rpmdb'
+
+Observed on a openSUSE Leap 42.1 build host with rpm-devel installed.
+
+Upstream-Status: Inappropriate [oe build specific]
+
+Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
+---
+ CMakeLists.txt | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index bcdeee6..1ca7b41 100644
+--- a/CMakeLists.txt
++++ b/CMakeLists.txt
+@@ -220,8 +220,7 @@ IF (ENABLE_RPMDB)
+     ENDIF (RPMMISC_LIBRARY)
+   ENDIF (RPM5)
+ 
+-  # check if rpm contains a bundled berkeley db
+-  CHECK_INCLUDE_FILE(rpm/db.h HAVE_RPM_DB_H)
++  set(HAVE_RPM_DB_H 0)
+   IF (NOT HAVE_RPM_DB_H)
+     FIND_LIBRARY (DB_LIBRARY NAMES db)
+     IF (DB_LIBRARY)
+-- 
+2.9.3
+
diff --git a/meta/recipes-extended/libsolv/libsolv_0.6.27.bb b/meta/recipes-extended/libsolv/libsolv_0.6.27.bb
index 7ddd533..0f988dc 100644
--- a/meta/recipes-extended/libsolv/libsolv_0.6.27.bb
+++ b/meta/recipes-extended/libsolv/libsolv_0.6.27.bb
@@ -8,7 +8,8 @@  LIC_FILES_CHKSUM = "file://LICENSE.BSD;md5=62272bd11c97396d4aaf1c41bc11f7d8"
 DEPENDS = "expat zlib rpm"
 
 SRC_URI = "git://github.com/openSUSE/libsolv.git \
-           "
+           file://0001-don-t-pick-up-bundled-db-from-host-rpm.patch \
+          "
 SRC_URI_append_libc-musl = " file://0001-Add-fallback-fopencookie-implementation.patch \
                              file://0002-Fixes-to-internal-fopencookie-implementation.patch \
                            "

Comments

Alexander Kanavin May 29, 2017, 10:50 a.m.
On 05/26/2017 11:35 PM, Max Krummenacher wrote:
> +-  # check if rpm contains a bundled berkeley db
> +-  CHECK_INCLUDE_FILE(rpm/db.h HAVE_RPM_DB_H)
> ++  set(HAVE_RPM_DB_H 0)

Have you looked into what CHECK_INCLUDE_FILE does, and whether it can be 
fixed? I'd like to hear about your findings.

Alex
Max Krummenacher May 29, 2017, 1 p.m.
2017-05-29 12:50 GMT+02:00 Alexander Kanavin
<alexander.kanavin@linux.intel.com>:
> On 05/26/2017 11:35 PM, Max Krummenacher wrote:
>>
>> +-  # check if rpm contains a bundled berkeley db
>> +-  CHECK_INCLUDE_FILE(rpm/db.h HAVE_RPM_DB_H)
>> ++  set(HAVE_RPM_DB_H 0)
>
>
> Have you looked into what CHECK_INCLUDE_FILE does, and whether it can be
> fixed? I'd like to hear about your findings.

Yes, I did.

I creates a c file and tries to compile it with the CFLAGS specified
in CMaketext.

<<<<<<<<
#include "rpm/db.h"
int main () {
return 0;
}
>>>>>>>>

As we're talking about libsolv-native here it uses the build host's
gcc which has the standard include directory
/usr/include and thus finds a /usr/include/rpm/db.h

And again, I do not think that it is an error to find/use headers from
the build host's /usr/include for a *-native
build.

Max
Max Krummenacher May 29, 2017, 1:06 p.m.
2017-05-29 15:00 GMT+02:00 Max Krummenacher <max.oss.09@gmail.com>:
> 2017-05-29 12:50 GMT+02:00 Alexander Kanavin
> <alexander.kanavin@linux.intel.com>:
>> On 05/26/2017 11:35 PM, Max Krummenacher wrote:
>>>
>>> +-  # check if rpm contains a bundled berkeley db
>>> +-  CHECK_INCLUDE_FILE(rpm/db.h HAVE_RPM_DB_H)
>>> ++  set(HAVE_RPM_DB_H 0)
>>
>>
>> Have you looked into what CHECK_INCLUDE_FILE does, and whether it can be
>> fixed? I'd like to hear about your findings.
>
> Yes, I did.
>
> I creates a c file and tries to compile it with the CFLAGS specified
> in CMaketext.
>
> <<<<<<<<
> #include "rpm/db.h"
> int main () {
> return 0;
> }
>>>>>>>>>
>
> As we're talking about libsolv-native here it uses the build host's
> gcc which has the standard include directory
> /usr/include and thus finds a /usr/include/rpm/db.h
>
> And again, I do not think that it is an error to find/use headers from
> the build host's /usr/include for a *-native
> build.

Maybe to add to 'can it be fixed?'

As I said, IMHO it is not broken, but
yes, one could pass an additional parameter to the compiler '-nostdinc'.
CHECK_INCLUDE_FILE(rpm/db.h HAVE_RPM_DB_H, "-nostdinc")
But this would break the intention of the test on the not '-native'
build as there
the rpm headers whould actually be found in the standard include directories.
So if OE ever would decide to change the rpm recipe to have an included db
this would not be picked up by the test in the not '-native' tests.

Max
Alexander Kanavin May 29, 2017, 3:54 p.m.
On 05/29/2017 04:06 PM, Max Krummenacher wrote:
>>>> +-  # check if rpm contains a bundled berkeley db
>>>> +-  CHECK_INCLUDE_FILE(rpm/db.h HAVE_RPM_DB_H)
>>>> ++  set(HAVE_RPM_DB_H 0)
>>>
>>>
>>> Have you looked into what CHECK_INCLUDE_FILE does, and whether it can be
>>> fixed? I'd like to hear about your findings.
>>
>> Yes, I did.
>>
>> I creates a c file and tries to compile it with the CFLAGS specified
>> in CMaketext.
>>
>> <<<<<<<<
>> #include "rpm/db.h"
>> int main () {
>> return 0;
>> }
>>>>>>>>>>
>>
>> As we're talking about libsolv-native here it uses the build host's
>> gcc which has the standard include directory
>> /usr/include and thus finds a /usr/include/rpm/db.h
>>
>> And again, I do not think that it is an error to find/use headers from
>> the build host's /usr/include for a *-native
>> build.
>
> Maybe to add to 'can it be fixed?'
>
> As I said, IMHO it is not broken, but
> yes, one could pass an additional parameter to the compiler '-nostdinc'.
> CHECK_INCLUDE_FILE(rpm/db.h HAVE_RPM_DB_H, "-nostdinc")
> But this would break the intention of the test on the not '-native'
> build as there
> the rpm headers whould actually be found in the standard include directories.
> So if OE ever would decide to change the rpm recipe to have an included db
> this would not be picked up by the test in the not '-native' tests.

I see. You are right here. I admit I don't fully understand if it's 
generally okay for -native recipes to look around in (and later use) 
host include  directories like that, as we're striving towards 
reproducible builds, and this behavior is not supportive of them. 
Richard, can we have your say please?

Alex
Richard Purdie May 29, 2017, 11:11 p.m.
On Mon, 2017-05-29 at 18:54 +0300, Alexander Kanavin wrote:
> I see. You are right here. I admit I don't fully understand if it's 
> generally okay for -native recipes to look around in (and later use) 
> host include  directories like that, as we're striving towards 
> reproducible builds, and this behavior is not supportive of them. 
> Richard, can we have your say please?

Its unavoidable really, we have to have some host system we build on as
we need a compiler/headers from it. Even if you build a gcc-native,
what would you compile it with? :)

If you do want to avoid the risk, you'd choose your own custom base OS
(or container) and then always build on that. It would then be both
reproducible and deterministic. We don't want to mandate a specific
host configuration out the box though.

So this patch avoids an issue. We don't tend to run into too many
issues like this one thankfully.

Cheers,

Richard