autoconf
[Top][All Lists]
Advanced

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

Re: /usr/local [was: CPPFLAGS prob]


From: Dan Kegel
Subject: Re: /usr/local [was: CPPFLAGS prob]
Date: Thu, 17 Jun 2004 08:24:30 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113

Murray Cumming wrote:
I think one needs a separate copy of pkg-config for each toolchain
you want to build things with.  (Or at least its data files)...


No, that makes no sense.

Nevertheless, even after reviewing "man pkg-config", I think it's true.
Take a look at the output of "strings /usr/bin/pkg-config | grep /":

 /usr/lib/pkgconfig
 /usr/include
 -L/usr/lib
 -L /usr/lib
 Package %s has -L/usr/lib in Libs
 Removing -L/usr/lib from libs for %s

And look at some of the files in /usr/lib/pkgconfig:

::::::::::::::
audiofile.pc
::::::::::::::
prefix=/usr
exec_prefix=/usr
libdir=/usr/lib
includedir=/usr/include

The only way pkg-config can work is if you have a separate
copy of pkg-config and its data files for each copy of the userland libraries.
This makes perfect sense: for each value of $prefix, you'll
have a separate copy of $prefix/usr/bin/pkg-config and 
$prefix/usr/lib/pkgconfig.

Unless you're familiar with cross-compiling, you probably won't understand
or care about any of the above.  That may change, though, as multiarch systems
become more common.  See http://raw.no/debian/amd64-multiarch-2, which
proposes putting libraries and include files not in /usr/include but in
/usr/$(gcc -dumpmachine)/{lib,include}
where gcc is the gcc associated with that copy of userland.

- Dan

--
My technical stuff: http://kegel.com
My politics: see http://www.misleader.org for examples of why I'm for regime 
change




reply via email to

[Prev in Thread] Current Thread [Next in Thread]