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

Re: multiarch and pkg-config

Tollef Fog Heen <tfheen@err.no> writes:

> ]] Simon McVittie 
> | `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).
> Yeah, I should probably change that around.  It's just a configure
> option, and given I don't believe anybody uses the triplet dir today,
> I'll probably just move it.

Seems simpler for sources as then setting libdir will do the right thing

But how would -dev packages signal that they need support for this? They
do not depend on pkg-config as they are usable without. Should they
Breaks: pkg-config (<< ver)? Seems too strong.

> | 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.
> I discussed this with Loïc Minier during UDS in Dallas and we did at
> least talk about using AC_CHECK_TOOL in pkg.m4.  I'd then need to
> implement some magic in pkg-config which feels a bit hackish, but which
> I could live with.  If somebody has feedback on the preferred way, I'm
> open to suggestions.

There already seems to be a check in place at least in some
sources. e.g cross building libxtst for arm:


| checking for arm-linux-gnu-pkg-config... no
| checking for pkg-config... /usr/bin/pkg-config
| configure: WARNING: In the future, Autoconf will not detect cross-tools
| whose name does not start with the host triplet.  If you think this
| configuration is useful to you, please write to autoconf@gnu.org.
| checking pkg-config is at least version 0.9.0... yes

> | 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
> If we want to support multiarch compilation, this sounds ok to me.  I'm
> personally not convinced by the point of doing it.  Though.

We probably don't want multiarch compilation as such but cross
compilation is a huge benfit for many people and multiarch dev packages
would make it possible to cross compile without having to set a sysroot
and without mangling packages during unpacking.

It also makes sense to compile sources with everything in the triplet
dir. No point having the *.so link or .pc files in different libdirs. It
is probably harder to not multiarchify the -dev packages as well.


Reply to: