Subject: Re: use of in pkgsrc
To: Alistair Crooks <>
From: None <>
List: tech-pkg
Date: 05/21/2002 22:42:40
On Mon, 20 May 2002, Alistair Crooks wrote:

> On Sun, May 19, 2002 at 02:09:44PM -0400, wrote:
> > 
> > a number of pkgs currently use in pkgsrc for building
> > libraries.  While this is nice, its resulting in broken PLISTs and in some
> > cases, broken packages.  The basic reason is that the set of libraries
> > produced varies by MACHINE_ARCH.  For example, on mipsel (pmax),
> > everything is PIC so there isn't a seperate libfoo_pic.a created.  Thus a
> > PLIST generated on i386 may list libfoo_pic.a and the PLIST will be wrong
> > on pmax.  Also, I've come across some pkgs which rather than using the
> > install target from, they explicitly add the install commands.
> > Now, they end up trying to install a libfoo_pic.a which doesn't exist and
> > the install fails.
> > 
> > Since there are around 15 pkgs that get patched to use (and an
> > unknown number which might already use it), I wonder if we need a slightly
> > more unified way of handling this.  Maybe a BSD_LIBS variable which would
> > expand into the PLIST?  Or maybe some flags in the PLIST which would get
> > turned into @comments on arch's which don't install the particular flavor
> > of lib?  Something like:
> > 
> > ${ARCH_INSTALLS_PIC}lib/libfoo_pic.a
> > ${ARCH_INSTALLS_P}lib/libfoo_p.a
> You could also modify the PLIST-modifying code in, but I agree that
> it would be nice to solve this generically.

the thing that worries me about modifying the PLIST code is that we need
to maybe have a BSD_LIB_LIBS=libfoo libbar setting in the Makefile to
identifies libraries which got built via since a
build system might not install the same set.  Comments on an approach
where a BSD_LIB_LIBS variable works with the PLIST modifying code to deal

Actually, this does make me want staged installs with dynamic plist's...