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

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

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

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

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

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

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