libcap-2.30

[Pierre Labastie]

New minor.

Release notes for 2.30

    Note: future bug reports should captured in this kernel.org tracker.
    BUGFIX: arm and i386 fixes C and Go setgroups choice - used wrong syscall in 2.29.
    cleaned up make clean and make install to actually work as intended
    updated Gentoo libpsx.pc file from Lars Wendler
    refactored the way libpsx linkage with libcap performed mutual discovery.
        Previously (2.28) libpsx had an API call overridden by libcap using weak linkage function in libpsx. In 2.30 this is reversed, namely libpsx provides the stronger function and libcap has a weak "no-op" version.
    a bit more consistency in handling the 'all' sets in libcap (C) and libcap/cap (Go). Namely, they both dynamically discover the number of capabilities named by the kernel and use this as the definition of 'all' for the current runtime.
        libcap (C) exports cap_max_bit() to export the number of supported capabilities
        libcap/cap (Go) exports cap.MaxBits() for this same value.

[Pierre Labastie]

I'm not sure the change in linking is without consequence. No other package links to the libpsx function. Will make a test and report.

[Pierre Labastie]

If we do not install libpsx.a, iproute2 fails with:

/usr/bin/ld: cannot find -lpsx

The reason is that libcap.pc has:

Requires: libpsx

and libpsx.pc has:

Libs: -L${libdir} -lpsx -lpthread -Wl,-wrap,pthread_create

The problem is that we have libcap as a shared library, but libpsx is only built as a static library...

The simplest for now would be to comment out the Requires:... line in libcap.pc, but this would mean that two functions (with psx in the name) would become no-op. I hope those two functions are not used by dependent packages.

[Bruce Dubbs]

It would seem to me that the most conservative thing to do is to retain libpsx.a. It may not be optimal from our standpoint, but it would not be unique either.

[Pierre Labastie]

Hmmm, I am not sure linking a shared library to a static one would succeed. I've done a successful build just removing the "Requires:" line in libcap.pc. Will try one with your suggestion (just replace STA...LIBNAME with STACAPLIBNAME in our instructions, and not modifying the .pc file.

[Bruce Dubbs]

Are we doing that? You can certainly link an executable with a static library and a different dynamic library.

[Pierre Labastie]

Any program linking to libcap and using the .pc file will end up with a link command containing:

... -lcap -lpsx -lpthread -Wl,-wrap,pthread_create

where we would have libcap.so and libpsx.a. It may work since everything is compiled with -fPIC. Trying a build ATM.

[Pierre Labastie]

Seems to work with libpsx.a. Fixed at r11720.

[Pierre Labastie]

Upstream does not want to provide a shared library while the API is still very unstable. But they consider it, see ​this bug report