Opened 19 months ago

Closed 19 months ago

Last modified 19 months ago

#4569 closed enhancement (fixed)

libcap-2.30

Reported by: Pierre Labastie Owned by: Pierre Labastie
Priority: normal Milestone: 9.1
Component: Book Version: SVN
Severity: normal Keywords:
Cc:

Description

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.

Change History (8)

comment:1 by Pierre Labastie, 19 months ago

Owner: changed from lfs-book to Pierre Labastie
Status: newassigned

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.

comment:2 by Pierre Labastie, 19 months ago

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.

comment:3 by Bruce Dubbs, 19 months ago

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.

comment:4 by Pierre Labastie, 19 months ago

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.

comment:5 by Bruce Dubbs, 19 months ago

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

comment:6 by Pierre Labastie, 19 months ago

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.

comment:7 by Pierre Labastie, 19 months ago

Resolution: fixed
Status: assignedclosed

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

comment:8 by Pierre Labastie, 19 months ago

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

Note: See TracTickets for help on using tickets.