I faled to spot this discussion earlier, but have just come back to it
as I realised that the current version of pkg-config-crosswrapper
being shipped in pkg-config is, well, 'wrong'.
This discussion above is all good stuff. Simon's patch is good, and
pretty-much follows what I have here (but apparently failed to ever
submit in a bug - sorry about that, it's been sat on this disk for
months).
The existing wrapper, whilst a useful proof-of-concept is not
adequate, so an upload needs doing to improve it, which means we need
to choose which behaviour to implement/upload. This has been stalled
since September.
The existing versions will fail for all of these cases:
* Arch-independent .pc files needed in cross-build
* cross-libs installed on multiarch paths
* override PKG_CONFIG_LIBDIR specified
Interesting point about allowing override of PKG_CONFIG_LIBDIR. I guess
Simon is right that we should honour that if pre-set, even when
cross-building. I can see cases where it might go wrong, but that's
probably a bug elsewhere, and we should treat it when we find an
offending example.
Re using dpkg-architecture to get the correct multiarch path: I see no
harm in doing this, because dpkg-dev is in build-essential so for
pkg-config to use it if present is not a problem.
dpkg-architecture -t"${triplet}" -qDEB_HOST_MULTIARCH
is the canonical way to find out this path in debian and this tool
should use it, just like others should.
Protoecting its use with a test -x would probably be wise.
Doing this will avoid breakage with the use of pkg-config with 'strange'
toolchains and cross-combos: anything supported by dpkg-architecture
should work as expected.
Simon and vincent are correct that /usr/lib/pkgconfig should not be
searched when crossbuilding in a strict implmentation of 'the right
thing'. However we are currently in a transition from non-multiarch to
multiarch and it's less obvious what is the best thing to do at this
point. We now have the ability to install non-native libs & -dev pkgs
on this path, by replacing the native lib * -dev pkg.
If we don't search that path then you can't use this mechanism with
any lib that has not yet been multiarched.
If we do search that path then there is a risk that wrong-arch libs
will be found and the build will proceed until it blows up during
linking. (This may not be true in the BUILD=amd64 HOST=i486 case? Is
that true? If so it is a point aginst searching /usr/lib/pkgconfig)
Unfortunately multiarching -dev packages is not trivial so doing all
3000-odd is going to take quite some time. In order to be able to
build 'most' things in the meantime I think Steve is probably right
that we should search this fallback path, at least for the time being.
The same reasoning has been used in bug#646288. Some stats: Currently
(in unstable) we have 792 packages multiarched, and 113 -dev packages
multiarched.
Vincent is right that this means cross-building in chroots will be more
reliable than cross-building on your 'main system', but that just
reflects the current reality (that we can't co-install -dev packages
for more than one arch in one rootfs until they are multiarched). He
is confused about dpkg-cross and .pc files. dpkg-cross is not used to
modify packages in multiarch world so cannot be responsible for moving
.pc files: that only applies in 'old-style' crossbuilding with
/usr/<triplet>/lib paths.
When the multiarch transition is 'complete' (however we define that)
we can remove /usr/lib/pkgconfig from the search path and
cross-building within your main rootfs will work nicely.
Ultimately it is up to the package maintainer whether to choose the
strictly-correct-but-not-useful-until-all-deps-multiarched solution,
or the expedient-but-wasted-build-time/failed-builds solution. I can
live with either but it would be really good if he could chose one,
because the existing script is pretty shoddy whichever way you look at
it, and entirely useless for libs that _have_ been multiarched.
Do we need to arrange further discussion to choose a solution here, or
can a choice just be made so people can work with it?
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
