Hi James, Nice to meet you! On Wed, Feb 08, 2006 at 07:28:39PM +0800, James Henstridge wrote: > Tollef Fog Heen wrote: > >Hi, any chance you could comment on this? I'm somewhat inclined to > >agree with Steve, but you know this stuff better than I do, so I'd > >value a second opinion. > >Also, if there's anything unclear or anything, please do mail Steve > >(and the bug) with me in Cc. > [snip] > >Both the xrender and freetype2 headers are included in Xft/Xft.h, and types > >from both of these headers are exported in the Xft API -- so any software > >using Xft.h needs to be able to find these other headers as well. > >Currently, pkg-config does *not* pass cflags from packages listed in > >Requires.private when called as pkg-config --cflags <foo>. > The fact that the headers are included makes them part of the _public_ > ABI of Xft. There are Xft functions that accept or return types defined > in the Xrender and freetype2 headers. > If Xft is updated to a new version of either of those libraries such > that those types are defined differently (altered struct layout, > different type sizes, etc), then the app also needs to be updated to the > new version. Ok, here's the problem with this argument. Yes, if one of the freetype types that's used in Xft/Xft.h changes, that is an ABI change... *in libXft* -- that's why we care about it! Because it's an ABI change in libXft, the soname of *libXft* should change. With the change of libXft's soname, there's no reason an application that is a consumer of libXft, but *not* a consumer of freetype, should care about libfreetype *at all*.[1] On the other hand, there are plenty of cases in which an ABI change in libfreetype will *not* cause an ABI change in libXft. Addition or removal of functions, addition of typedefs, or removal or changing of any typedefs not used in libXft's ABI are all changes that should require an soname change in libfreetype but not an soname change in libXft. The present ABI transition in libfreetype is such a case. But because these applications are being encouraged to link directly to libfreetype, *even though they don't use it*, they have to care about ABI changes that should not affect them. The net result is that pkg-config's handling of Requires/Requires.private is directly causing churn in response to ABI changes in any indirect library dependencies, where this should be completely unnecessary on GNU/Linux platforms. It increases the chances of segfaults or other failures from loading two different versions of a library into memory, and correspondingly increases the frequency with which binaries need to be rebuilt in response to ABI changes that don't actually concern them. And it does this entirely to support a use case which, as explained above, should not actually exist. > >- the library intentionally includes headers from dependencies in its own > > headers in order to inherit type definitions, but these definitions are > > not intended for direct consumption by users of this library alone; > > therefore pkg-config must export the cflags from dependencies in all > > cases, but the ldflags only when linking statically > Changes to type definitions _do_ change the ABI. If library A uses > library B's types in its ABI, then it's ABI will break if library B > changes those types. An app using library A should definitely record > the version of library B being used. However: - If library A's soname is correctly changed in sync with library B's, linking application C to library B is redundant. - If library A's soname is not changed when library B's soname changes, pkg-config's behavior does not prevent applications from being broken by the ABI change in libA. At most, it makes it easier to detect such breakage due to double-linkage of libB. > >Please note that today, the handling of Requires.private in pkg-config maps > >to *none* of these cases -- I can't think of a single situation in which > >cflags of dependencies are needed when statically linking, and not needed > >when dynamically linking! > The cflags of dependencies listed in "Requires.private" are not included > for either dynamic or static modes of pkg-config, so maps to case 3 > quite well. Ah, guess I should have looked a bit closer at the behavior in that case. > >This is unfortunate, because there are a great many packages that are > >inheriting dependencies this way on libraries they don't use. While it is > >true that an ABI change in the dependent library will *sometimes* mean an > >ABI change in the depending library, this is not always the case. As a > >result, this behavior of pkg-config causes unnecessary churn for packages > >depending on libraries in this scenario. In the case of libxft2, that's > >over 400 packages in Debian that are potentially affected. > Sure, unnecessary churn is bad and should be avoided. But you do want > to make sure that the churn happens when required. Er, the whole reason I'm objecting to the current behavior is that it *is* unnecessary churn. If the libfreetype ABI change affected the ABI of libXft, there would be no sense in trying to avoid the double-linking, and I wouldn't be bothering! :) > Relying on indirect linkage in a lot of cases just results in more fragile > applications. No, recursive linking of indirect dependencies results in more *brittle* applications, which break any time anything anywhere in the dependency tree changes. I'm not sure why you think that "relying" on libraries to take care of their own messes without bothering the application is fragile. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/ [1] This sets aside the issue that you can't reasonably ensure that the freetype.h included from Xft/Xft.h matches the ABI used when building libxft.so except through a package manager; that's simply an argument why you should properly encapsulate types from other libraries instead of exposing them in your own API, which doesn't help us in the case when that's not what people do. It's also not anything that pkg-config's current behavior actually helps...
Attachment:
signature.asc
Description: Digital signature