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
already.
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:
http://www.emdebian.org/buildd/?log=libxtst-arm-1216068648.log&pkg=libxtst
| 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.
MfG
Goswin
Reply to: