[OE-core] [PATCH v2 2/4] libcap: fix (base_)libdir usage

[Mark Asselstine]

On Tuesday, May 8, 2018 2:26:47 PM EDT Mark Asselstine wrote:
> On Tuesday, May 8, 2018 1:46:43 PM EDT Ricardo Salveti wrote:
> > On Mon, Apr 16, 2018 at 10:00 AM, Koen Kooi <koen at dominion.thruhere.net>
> 
> wrote:
> > > The recipe wants to install libs into base_libdir, but uses "basename
> > > $libdir" to derive that. That breaks in a multiarch setup. Use the
> > > proper
> > > variable and remove the inline python usage.
> > > 
> > > Signed-off-by: Koen Kooi <koen.kooi at linaro.org>
> > > ---
> > > 
> > >  meta/recipes-support/libcap/libcap_2.25.bb | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/meta/recipes-support/libcap/libcap_2.25.bb
> > > b/meta/recipes-support/libcap/libcap_2.25.bb index d619a2e..47ecf34
> > > 100644
> > > --- a/meta/recipes-support/libcap/libcap_2.25.bb
> > > +++ b/meta/recipes-support/libcap/libcap_2.25.bb
> > > @@ -32,7 +32,7 @@ PACKAGECONFIG[pam] = "PAM_CAP=yes,PAM_CAP=no,libpam"
> > > 
> > >  EXTRA_OEMAKE = " \
> > >  
> > >    INDENT=  \
> > > 
> > > -  lib=${@os.path.basename('${libdir}')} \
> > > +  lib='${base_libdir}' \
> > > 
> > >    RAISE_SETFCAP=no \
> > >    DYNAMIC=yes \
> > >    BUILD_GPERF=yes \
> > 
> > This creates a build failure when usrmerge is used, as libcap expects
> > only the lib folder name and not the lib path (and when usrmerge is
> > enabled base_libdir gets set to /usr/lib instead of /lib).
> > 
> > Since base_libdir and libdir are all based out baselib, can you
> > provide more details about how that broke your multiarch setup?
> > 
> > The failure when usrmerge is used:
> > WARNING: libcap-2.25-r0 do_package: QA Issue: libcap:
> > 
> > Files/directories were installed but not shipped in any package:
> >   /usr/lib
> >   /usr/usr/lib/libcap.so
> >   /usr/usr/lib/libcap.so.2
> >   /usr/usr/lib/libcap.so.2.25
> >   /usr/usr/lib/libcap.a
> >   /usr/usr/lib/pkgconfig
> >   /usr/usr/lib/pkgconfig/libcap.pc
> >   /usr/usr/lib/security/pam_cap.so
> 
> Agreed. I just started to determine how this is breaking qemu-native (with
> virtfs enabled in the PACKAGECONFIG) and found that this change drops
> several files from being installed in the native-sysroot.
> 
> Before this change:
> ⟫ cat .../tmp/work/x86_64-linux/qemu-native/2.11.1-r0/recipe-sysroot-native/
> installeddeps/libcap-native.39df7fd64afdeb62b13bb47b7969532b
> recipe-sysroot-native/sysroot-providers/libcap-native
> recipe-sysroot-native/usr/include/sys/capability.h
> recipe-sysroot-native/usr/sbin/getpcaps
> recipe-sysroot-native/usr/sbin/capsh
> recipe-sysroot-native/usr/sbin/getcap
> recipe-sysroot-native/usr/sbin/setcap
> recipe-sysroot-native/usr/lib/libcap.so
> recipe-sysroot-native/usr/lib/libcap.so.2.25
> recipe-sysroot-native/usr/lib/libcap.a
> recipe-sysroot-native/usr/lib/libcap.so.2
> recipe-sysroot-native/usr/lib/pkgconfig/libcap.pc
> recipe-sysroot-native/usr/lib/pkgconfig/
> recipe-sysroot-native/sysroot-providers/
> recipe-sysroot-native/usr/include/sys/
> recipe-sysroot-native/usr/include/
> recipe-sysroot-native/usr/share/
> recipe-sysroot-native/usr/sbin/
> recipe-sysroot-native/usr/lib/
> recipe-sysroot-native/usr/
> 
> After the change:
> ⟫ cat .../tmp/work/x86_64-linux/qemu-native/2.11.1-r0/recipe-sysroot-native/
> installeddeps/libcap-native.2d12ea82cbd6eeaf25251caae2dce487
> recipe-sysroot-native/sysroot-providers/libcap-native
> recipe-sysroot-native/usr/include/sys/capability.h
> recipe-sysroot-native/usr/sbin/getpcaps
> recipe-sysroot-native/usr/sbin/capsh
> recipe-sysroot-native/usr/sbin/getcap
> recipe-sysroot-native/usr/sbin/setcap
> recipe-sysroot-native/sysroot-providers/
> recipe-sysroot-native/usr/include/sys/
> recipe-sysroot-native/usr/include/
> recipe-sysroot-native/usr/share/
> recipe-sysroot-native/usr/sbin/
> recipe-sysroot-native/usr/lib/
> recipe-sysroot-native/usr/
> 
> I also believe that the old inline python was also not functioning correctly
> which is why it was believed that the change was non-consequential for non-
> multilib builds. I am looking at putting together a fix but would be more
> than happy if someone else came up with something first.

Sorry, I stand corrected the python is functional, I was getting confused with 
the interplay between 'lib' used during make and 'prefix' used during install. 

The issue wtih the -native build is that $base_libdir is influenced by 
additions made in native.bbclase, specifically:

    # Path prefixes
    base_prefix = "${STAGING_DIR_NATIVE}"
    prefix = "${STAGING_DIR_NATIVE}${prefix_native}"

Since $base_libdir incorporates $base_prefix:

export base_libdir = "${root_prefix}/${baselib}"
where
root_prefix = "${@bb.utils.contains('DISTRO_FEATURES', 'usrmerge', \
    '${exec_prefix}', '${base_prefix}', d)}"

So we end doubling down $STAGING_DIR_NATIVE twice. Once via 'lib=' in 
do_compile and once via 'prefix=' in do_install.

Similarly with the 'usrmerge' builds, we are doubling down on '/usr', once in 
do_compile and one in do_install.

I will send out a fix but since the original commit doesn't really describe 
the multiarch breakage I will have to rely on Koen to validate that my change 
doesn't just put us back to where we were.

Mark




> 
> Mark
> 
> > Thanks,