reopen 349318
block 349318 by 340904
thanks
> * Add 001_no_export_freetype.diff. This is a modified patch from Steve
> Langasek that causes xft.pc not to export freetype or xrender as part of
> the interface, but hide them in Requires.private instead (closes: #349318)
The patch is:
Index: libXft-X11R7.0-2.1.8.2/xft.pc.in
===================================================================
--- libXft-X11R7.0-2.1.8.2.orig/xft.pc.in 2005-12-30 14:50:49.000000000 -0500
+++ libXft-X11R7.0-2.1.8.2/xft.pc.in 2006-01-22 22:12:27.000000000 -0500
@@ -6,7 +6,7 @@
Name: Xft
Description: X FreeType library
Version: @VERSION@
-Requires: xproto, xrender, fontconfig, freetype2
-Requires.private: xrender, fontconfig, freetype2
+Requires: xproto, fontconfig
+Requires.private: xrender, freetype2
Cflags: -I${includedir}
Libs: -L${libdir} -lXft
This won't work because of the aforementioned bug #340904:
$ grep -h include include/X11/Xft/*.h
#include <X11/Xfuncproto.h>
#include <stdarg.h>
#include <ft2build.h>
#include FT_FREETYPE_H
#include <fontconfig/fontconfig.h>
#include <X11/extensions/Xrender.h>
#include <X11/Xfuncproto.h>
/* #include <X11/Xosdefs.h>*/
#include <X11/Xft/XftCompat.h>
$
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>.
So far, the maintainer has resisted changing pkg-config to export cflags
(which should really be called cppflags...) from Requires.private due to a
fallacious argument regarding the nature of "private" dependencies. There
are three real use cases for libraries which depend on other libraries:
- the library intentionally exports the API and ABI of its dependencies when
linked to, and therefore both the ldflags and the cflags of its
dependencies should be exported by pkg-config in all cases[1]
- 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
- the library's API includes no headers from its dependencies; pkg-config
needs to export the ldflags of private dependencies when statically
linking but not when dynamically linking, and should *never* need to
export the cflags of these headers.
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! Instead, the Requires.private handling is
adequate for the third case; handling of Requires is correct for the first
case; and there is no combination of options that is appropriate for the
second 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.
--
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] Personally, I think this is completely specious, but there are GNOME
people who insist that this describes the relationship between gtk+2.0
glib.
Attachment:
signature.asc
Description: Digital signature