Hi Simon, >> The following additional directories should be handled as system >> include directories: >> >> - /usr/include/<DEB_HOST_GNU_TYPE> for each architecture, including >> the non-default biarch and triarch directories.
> It's non-trivial to determine what the non-default biarch and triarch
> directories for a particular architecture are. Should the Debian packaging
> for pkg-config just hard-code this for all known Debian architectures, or
> can it be derived from gcc -print-search-dirs, or glibc, or something, in
> some mechanical way?
Here's a quick script to get the multilib path qualifiers for the current
architecture:
for opt in $(gcc -print-multi-lib | sed -n -e's/.*;@/-/p'); do
gcc $opt -print-multi-os-directory
done
This currently returns paths like "../lib32" and "../lib64". It's not yet
clear what these paths will be under multiarch, but the current set of
multiarch paths for gcc will cause these to be returned as "../../lib32" and
"../../lib64" instead, so pkgconfig may need to apply some heuristics to
these.
>> - /usr/lib, /usr/lib32 *and* /emul/ia32-linux/usr/lib/ on amd64 and
>> ppc64.
> Is /emul/ia32-linux/usr/lib still necessary, or has it been superseded?
I'm happy to say that this appears to be obsolete in squeeze, at least on
amd64. I don't know about ia64, though (is that what Matthias meant when he
said ppc64?)
> Do /lib, /lib64, /lib32 also need to be filtered out?
I believe the answer here is "no" - only /usr/lib is part of the default
search path for ld, and even if the runtime libraries are shipped in /lib,
the .so's are still supposed to be under /usr/lib not under /lib.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
[email protected] [email protected]
signature.asc
Description: Digital signature
