[ On Friday, October 22, 1999 at 17:57:05 (-0500), Frederick Bruckman wrote: ]
> Subject: Re: dilema with use of LDFLAGS=-L${LOCALBASE}/lib vs. private application libraries
>
> > So, my new proposal is simply:
> > 
> > - LDFLAGS+=		-Wl,-R${LOCALBASE}/lib -L${LOCALBASE}/lib
> 
> That won't make any difference.

Oh, but it will.  Removing that line makes all the difference in the
world!  By now I've proven this by example too -- it really does work in
the real world at eliminating both of the problems I encountered, and it
should work to fix problems with tools like windowmaker that install
their own libraries too.

> The problems you reported were with packages that use GNU configure.

I didn't mention any specific packages because the problem isn't
specific to only packages that use GNU Configure.

> The package system only sets LDFLAGS in the environment for configure;

No, that's not true.  It also sets it via MAKE_ENV too.

> it's up to configure to use that to find the libraries it needs, and
> to save and use the value of LDFLAGS in the generated Makefiles.
> 
> If configure is picking up the wrong library entirely, and not simply
> the wrong version, it's a bug.

How's configure to know?  It's not a 100% solvable problem.  Configure
can not be expected to test every interface in the library, especially
when the package on its own is very careful to make sure that it uses
the required '-L' arguments in the correct order.  I.e. the packages I
encountered problems with do build 100% correctly if they have not been
adversely affected by the incorrect environment from bsd.pkg.mk.

Indeed GNU Configure in particular explicitly defines the proper use of
the LDFLAGS environment variable and bsd.pkg.mk is violating this
definition due to incorrect assumptions on its part.

Note that it's probably safe to comletely remove the use of LDFLAGS in
setting CONFIGURE_ENV, though not from MAKE_ENV for the sake of X11
packages, suggesting the following more complete change:

- LDFLAGS+=		-Wl,-R${LOCALBASE}/lib -L${LOCALBASE}/lib
  MAKE_ENV+=		LDFLAGS="${LDFLAGS}"
- CONFIGURE_ENV+=		LDFLAGS="${LDFLAGS}"


> The best solution is for one of the
> packages to change the name of it's library.

Only if you look at the world through rose coloured glasses all the
time!  ;-)

Changing the name of one of the libraries is never going to solve this
problem in an elegant and generic manner -- it is bound to recure over
and over and over again.

However the proposal I've made will guarantee to solve the problem with
the least amount of effort on the part of pkgsrc maintainers and with no
intervention required by package authors (who'll just scoff at most such
suggestions anyway!) because it'll move it from being a generic problem
that can strike without warning to one that's managed in only those well
known cases where it can be predicted well in advance.

-- 
							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>