Re: cross-compilation and proprietary pkg-config replacements (pcre-config, pcap-config, etc)

[Wookey]

+++ John Spencer [2014-08-15 23:49 +0200]:
> Hello!
> 
> I'm currently in the process of adding cross-compilation support to
> a linux distribution, but I'm running into a lot of nasty issues.
> 
> The #1 offender are proprietary pkg-config replacements, and there are many.
> They break cross-compilation by returning non-sysrooted include and
> library directories from the host, like -I/usr/include or -L/lib.
> 
> I'm glad to say that autoconf itself is one of the few components
> that properly handle cross-compilation.
> 
> It seems it's "en vogue" for libs to ship their own broken
> replacement rather than supplying a portable pkgconfig file...
> the list is big, but these here are the most often used ones:
> pcap-config, pcre-config, freetype-config, apr-1-config,
> glib-config, gtk-config, ncursesw5-config, libmikmod-config, etc.

It's not really "en vogue", it's historic: many of the things that
have their own *-config scripts are sufficiently old that they
pre-date pkg-config so are not doing this just to be annoying. At the
time they didn't have much choice.

> since it's unlikely to get any of those fixed in the next decade (or
> even convinced to ship .pc files instead of their NIH'd pkg-config
> replacement), 

I don't see why this should be too hard. We've (Debian) already
persuaded a couple of projects to just use pkg-config instead of
whatever homegrown stuff they had, or at least do that as well. It's
the right way to make crossing and multiarch work right (as you are
aware), and I'd hope that most upstreams could be persuaded of that.

But there is a load of work involved in fixing things up and checking
you didn't break all their reverse dependencies so it will take some time.

> my idea was to add support for them into autoconf itself:
> 
> Offer a m4 macro for each of them (or a generic "external config"
> macro), which then calls these config tools and prefixes the
> returned include and library paths with the sysroot path (passed to
> configure via --with-sysroot=).
> so packagers depending on these libraries would use the provided macros
> rather than hardcoding their own test.

Interesting idea. Is that easier than just adding a pkg-config file to
each project?

If you do this do remember that we want it to work on multiarch
systems too, where sysroot is not used (equivalent to sysroot=/) 

> Does this sound viable and acceptable for inclusion ?
> Or is there another workaround that i missed ?

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/