Opened 5 years ago

Last modified 5 years ago

#59436 new defect

libxml2 @2.9.9: libxml2-config.cmake LIBXML2_LIBRARIES includes libxml2's dependencies, which results in overlinking

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by:
Priority: Normal Milestone:
Component: ports Version: 2.6.2
Keywords: Cc: jmroot (Joshua Root)
Port: libxml2

Description

libxml2 installs /opt/local/lib/cmake/libxml2/libxml2-config.cmake which contains:

list(APPEND LIBXML2_LIBRARIES -L/opt/local/lib -licui18n -licuuc -licudata  -liconv -lm  )

This causes software that uses cmake to find libxml2 to overlink to libraries that aren't needed—when building dynamically-linked software.

/opt/local/bin/xml2-config --libs also produces output that results in overlinking, but this cannot be avoided, since xml2-config does not distinguish between the use case of static linking (where these extra libraries are needed) and dynamic linking (where they are not). pkg-config libxml-2.0 --libs is a better way for programs to discover the libraries for dynamic linking.

I don't know how software that uses cmake to find libxml2 uses LIBXML2_LIBRARIES—I don't know if it could be used for static linking or if it is only used for dynamic linking. If it could be used for static linking, then that sucks and we can't change this.

Change History (6)

comment:1 Changed 5 years ago by jmroot (Joshua Root)

That file doesn't look very good in this regard, however I don't know if it's used much, since cmake ships its own module for finding libxml2: https://cmake.org/cmake/help/latest/module/FindLibXml2.html

comment:2 Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)

Oh, well I assumed it was used by libiio which would explain why it was revbumped after the icu update.

comment:3 Changed 5 years ago by jmroot (Joshua Root)

Yes, it is. It uses libxml2-config.cmake if present and uses FindLibXml2.cmake as a fallback. The comments in the CMakeLists seem to indicate that the reason for that is to get all the libraries needed for a static build.

comment:4 Changed 5 years ago by michaelld (Michael Dickens)

Unless libxml2 requires ICU for the API, then there's no reason they the ICU ABI should be required in this manner. Even static links shouldn't require it, as it should be built-in to the static library. Or, that's my belief / understanding of how these things should work.

Is there a PR for this issue yet? There are a -lot- of ports that depend on libxml2, which if not fixed will either require a rev-bump or to be rebuilt because of this chained dependency .... grrr ....

comment:5 Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)

My understanding is that xml2-config, and other projects' *-config scripts, print all libraries when using the --libs flag, because linking to a static library requires linking to all of its dependencies as well. I don't do static libraries so I don't have experience with this myself. For dynamically linked libraries this is not needed but *-config scripts don't provide a way for the caller to indicate that the flags will be used for dynamic linking. pkg-config, on the other hand, prints only the flags needed for dynamic linking when the --libs flag is used, unless the --static flag is also used.

I'm not very familiar with cmake. I have not submitted a PR to change this cmake file because I do not know how the file is used. If it is ever used to build static libraries, then the file should not be changed. If it is used only to build dynamic libraries, then it should be changed.

comment:6 in reply to:  4 Changed 5 years ago by jmroot (Joshua Root)

Replying to michaelld:

Even static links shouldn't require it, as it should be built-in to the static library. Or, that's my belief / understanding of how these things should work.

That's not the case; when linking an executable statically you really do need to explicitly mention every library that provides any symbol used by your code either directly or indirectly. GNU libtool has code to automate this via the .la files installed with every library, which is why we already delete (or remove the dependency information from) all .la files.

Note: See TracTickets for help on using tickets.