Subject: Re: pkg/8649: Build of windowmaker fails
To: Heiko W.Rupp <hwr@xlink.net>
From: Greg A. Woods <woods@most.weird.com>
List: netbsd-bugs
Date: 10/24/1999 13:22:48
[ On Sunday, October 24, 1999 at 14:10:36 (+0200), Heiko W.Rupp wrote: ]
> Subject: Re: pkg/8649: Build of windowmaker fails
>
> > The build is finding an older installed library *before* the local
> > libraries becuase of the way bsd.pkg.mk prepends "-L${PREFIX}/lib" to
> > LDFLAGS instead of appending it after any "-L" options the package might
> > add itself.

Actually I realize now that in WindowMaker the bug is with the use of
${X11BASE}/lib in LDFLAGS, not ${LOCALBSE}/lib....

> I wonder then the change happened, as this used to work fine until
> not too long ago.

The problem would only appear if the new version of WindowMaker
contained incompatible changes to any of the interfaces (and I don't
just mean function parameters) in any of their own private libraries
(i.e.  libWINGs, libWMaker, or libwraster).  Builds will still mostly
work so long as the previous version's libraries are compatible enough
with the new version.

> The current behaviour makes it a pain in the ass to update e.g. a
> windowmanager, when actually using that windowmanager when rebuilding
> the package.

Yes!  It is especially annoying since there's absolutely no need to mess
with LDFLAGS in the case of WindowMaker!  I.e. this bug should never
have occured, but the current scheme of providing a '-L' in LDFLAGS
makes it inevitable (and unpredictable).

> If it stays this way, it should be documented on www.netbsd.org, as
> I think many others will also stumble over this problem.

I'm trying to build a case for removing all mention/setting of LDFLAGS
in pkgsrc/mk/bsd.pkg.mk.  This seems like the most elegant and least
intrusive of any change, at least that's been my experience using this
change so far.  Indeed the FreeBSD ports system does much better at
building a wider range of packages and binary packages and yet does not
mess with LDFLAGS either.

I'm somewhat more leary of completely removing the use of
"-L${X11BASE}/lib" in LDFLAGS in bsd.pkg.mk -- X11 packages do always
need other libraries from that directory, and X11 packages that do not
use imake (and some that do) are notoriously bad for getting
non-standard X11 installations wrong..  However this flag should always
appear after any internal package library search paths as otherwise this
bug is inevitable in any package which installs its own private
libraries.  Perhaps the only real fix is to be diligent at fixing the
real bugs in any broken X11 packages and indeed completely removing all
setting and use of LDFLAGS from bsd.pkg.mk.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>