[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

multiarch and pkg-config

On Tue, 02 Feb 2010 at 14:22:49 +0100, Goswin von Brederlow wrote:
> You can move headers, the *.so link and static libs. But .pc and .la
> files can not be in the triplet dir yet afaik. So that is a no go for
> now. But if you want you can try and see what changes libtool and
> pkgconfig would need for this.

Removing .la files (in the right order, leaf packages first) is a release goal
anyway, so I think it would be reasonable to say that only -dev packages that
have already lost their .la files (like dbus) can be multiarch.

`pkg-config --debug 2>&1 | grep i486` (on my i386) reveals that pkg-config
already looks in /usr/lib/pkgconfig/i486-linux-gnu; perhaps it could be made
to search /usr/lib/TRIPLET/pkgconfig too (hackish version:
/usr/lib/pkgconfig/TRIPLET could be a symlink there, on Debian).

However, this would also require that pkg-config itself was multiarch or
otherwise supported cross-compilation (/usr/bin/i486-linux-gnu-pkg-config,
like AC_CHECK_TOOL would use? pkg-config --arch=i486-linux-gnu? etc.); until
then, it's not useful for pkg-config-using libraries to be multiarch (if
I have i386 and amd64 versions of libdbus-1-dev, but only the one whose
architecture matches my version of pkg-config actually works, then I might
as well uninstall the other version of libdbus-1-dev).

I'd be interested to hear from Tollef what the plan is regarding pkg-config
and multiarch.

In the meantime, from the point of view of the multiarch cabal, which of these
is most correct?

* pkg-config'd libraries should not be multiarch until pkg-config supports it,
  but the .a, .so should go in /usr/lib/TRIPLET as soon as possible

* pkg-config'd libraries should not be multiarch until pkg-config supports it,
  and until then they should ensure that the .a, .so stay in /usr/lib

* pkg-config'd libraries may do whichever of those is most straightforward

> /usr/include/triplet is at least preferable to
> /usr/lib/triplet/package/include as the former is in the default include
> path and works without -I option.

That defeats the purpose of using the dbus-1.0 subdirectory, which is precisely
to *not* be on the default inclusion path, for parallel-installability across
some future API break, perhaps to dbus-1.5 or dbus-2.0 or something (D-Bus
hasn't needed to do this, but the migration from Gtk 1.2 to 2.0 did, and
Qt 3 -> 4 appears to do the same).

Whether you personally consider this design broken or not, it exists and is
widespread, and multiarch should cope; the major advantage is that it avoids
the need for the mutual Conflicts seen in e.g. libdb4.x-dev.

In cases where an API-specific subdirectory is used by upstream for that
purpose, sticking to upstream's choice of
/usr/lib/TRIPLET/PACKAGE-API/include vs. /usr/include/TRIPLET/PACKAGE-API
is considerably easier than not, and I don't really see a technical argument
one way or the other when the default -I path is no longer relevant; is
there one that I'm missing?

> > (Some concrete examples: GLib and GDK also have one arch-specific header in
> > ${libdir} each; expat is one of several with a version of config.h in
> > /usr/include; Python has pyconfig.h in a /usr/include subdirectory.)
> Most of /usr/lib/glib-2.0/include/glibconfig.h is already arch
> independent or can trivialy be rewritten as such using C99.

GLib upstream supports pre-C99 compilers, so that's unlikely to be feasible
(unless you want Debian to fork GLib, which seems like a recipe for disaster).


Reply to: