Spilt libperl from perl

[Ralf Corsepius]

On Tue, 2007-04-24 at 17:19 +0200, Axel Thimm wrote:
> On Tue, Apr 24, 2007 at 03:04:23PM +0200, Ralf Corsepius wrote:
> > > Also things like pkg-config for example will still look under 
> > > /usr/lib64/pkgconfig even when run with/through setarch i386.
> > Right pkg-config is an issue of its own. It lacks multilib support.
> 
> Which may be another side-effect fixed by using bin and bin64,
Well this would work-around some packaging issues, and some of the
issues pkg-config has with building native binaries on multilib'ed
systems, but it would not help the actual issue pkgconfig has with
multilibs.

Consider, GCC uses multilibs at compile-time/link-time. Somewhat
oversimplified, multilibs changes GCC's library search paths by
appending a relative directory to library-directories (-L).

So, if pkgconfig wants to be flexible (multilibs can change over time)
and portable (pkg-config is not tied to native compilation, consider
cross-compilation), it 
(a) should check if it is being used with a multilib enabled GCC
and 
(b) if (a) applies, could adopt GCC's multilib library search-path
expansion to be able to automatically expand PKG_CONFIG_PATH.

> e.g. the i386-on-x86_64 developer just removes the 64 bit paths and
> voila, /usr/bin/pkgconfig does the right thing for i386. And the
> normal paths take care that /usr/bin64/pkgconfig manages 64 bit libs.
The correct API would be to take multilib flags into account:

E.g. something similar to

pkg-config CC=gcc CFLAGS=-m32 ....
on i386/x86_64 platforms

or 

pkg-config CC="avr-gcc" CFLAGS="-mavr5"
for an avr cross-compiler targetting avr5 multilibs

> Clean separation of archs.
This is run-time separation, trying to map link-time separation into
run-time separation. This works as long as the number of multilibs is
small, but becomes very unhandy, when using pkg-config for systems which
have many multilibs (such as many embedded systems).

Ralf