cups-config: only CUPS libraries go in non-static cups-config --libs
#5261
Conversation
We're including compression and crypto libraries in the linker flags output, even when we're built as a shared library. This doesn't make sense, because callers of cups-config are only looking for their direct dependencies. If they plan to make any SSL or zlib calls of their own, they should be managing those flags on their own. This resolves problems seen in package management, where libcups users end up inadvertently linking against (e.g.) gnutls directly, without the package manager being aware. (And thus, it doesn't know to rebuild on library upgrades.)
|
We've had problems with this in the past; will re-investigate but I know on some platforms doing this doesn't actually work... :/ |
|
Any tips on what platform(s)? I don't believe any other *-config tool (e.g., pkg-config) works the way cups-config currently does. |
|
AIX, HP-UX, IRIX, macOS and some versions of Solaris for sure. |
|
do those include static linking ? i can understand on static-only systems needing the extra linkage. |
|
No, those are all operating systems that support shared libraries. They just don't always support recursive linkage (i.e. just the symbols referenced in the shared library get bound) so the application linking to libcups that also needs one or more additional functions from a dependent library must also link to the dependent library. Like I said, I'll re-investigate to see if we can move away from that, or at least make it conditional on a per-platform basis... |
… to the "--libs" output (Issue #5261)
3 participants
We're including compression and crypto libraries in the linker flags
output, even when we're built as a shared library. This doesn't make
sense, because callers of cups-config are only looking for their direct
dependencies. If they plan to make any SSL or zlib calls of their own,
they should be managing those flags on their own.
This resolves problems seen in package management, where libcups users
end up inadvertently linking against (e.g.) gnutls directly, without the
package manager being aware. (And thus, it doesn't know to rebuild on
library upgrades.)