What's up with the list?

[Bernd Petrovitsch]

Hi!

On Son, 2008-10-19 at 12:57 +0200, Matěj Týč wrote:
[...]
> > Why? When you are cross compiling $prefix/bin is where your
> > cross compiled binaries go. In most cases cross compiled 
> > binaries will not work on the host you are compiling on.
> That's right, I have forgot about that :-) However, cross-compiled
> libraries's .pc files are going to be installed in $prefix/lib/pkgconfig
> directory, right?

IMHO yes.

> > If you have just cross compiled a wince-arm-pkg-config on an
> > i386 Linux host, that wince-arm-pkg-config binary will not run on
> > your Linux host.
> Now I see what's wrong with it, thanks!
> The "cross-compiling pkg-config" thing wasn't a really smart idea.

Just that I'm not sure I was clear enough: When mentioned
"cross-compile", I meant: using pkg-config running on the build host
(because some libs and apps use it) but the compiled libs and apps run
on the target system.
The special problem is (or was - it was > 1 year ago with
pkg-config-0.21 that seriously had to make that), that the location of
the very same cross-compiled lib is different on the build host (when it
comes to linking of the apps and other libs) and run-time.
And the problem was *not* "$APP uses $LIB using pkg-config" but it was
"$APP uses $LIB1 which uses $LIB2 all using pkg-config" because $LIB2
was indirectly linked/pulled in by $LIB1 and the compile-time directory
of $LIB2 ended up in $APP. And the build-time directory structure does
not exist at run-time (and there is no sane way to get these two to
match).
So hardcoding directories in a .pc file and transparently getting that
directory into other binaries is basically a big "no no" (and yes,
libtool has the same problem BTW).
It ended up that one rewrites the generated .pc files with sed or perl.

[...]
> > So document it and submit a patch for the pkg-config docs.
> No problem, but before I do that, I would like to find the smartest
> solution to this problem.

ACK.
Environment variables (prefix them with PKG_CONFIG_ or any other long
string) to override paths/... is usually pretty useful since one usually
has several of environment variables to specify various aspects of the
cross-toolchain anyways, starting with CC, HOSTCC and standard options
for CC, HOSTCC, CPP, CXX, .....
Putting a "pkg-config" script, which is actually a wrapper
around /usr/bin/pkg-config, in some extra directory and editing the PATH
is somewhat problematic as it risks that some overly clever (or - more
to the point - dumb) Makefile/... also plays games with PATH and I'm not
a fan of dissecting autoconf etc. just to get some app to compile.
I don't know if it's simple to change the name from "pkg-config" to
"arm-linux-pkg-config" (or whatever one - the developer! - calls it) for
all libs and apps.

JftSoC: More than enough libs and apps also require to compile programs
transparently as part of the build process. So the simple "just change
PATH to all of the cross-tools" and similar is also not possible.

[...]
	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services