On Fri, 22 Oct 1999, Greg A. Woods wrote:

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

I see what you're after now. I missed the leading minus sign.

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

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

Alright, that's correct, but it's irrelevant. GNU configure packages
don't usually pick up LDFLAGS from the environment at compile time;
configure, instead, sets LDFLAGS in the generated Makefile at
configure time.

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

What are you talking about? Why would you have to test every interface
in the library? Just rename the library, or re-order the arguments in
Makefile.in.

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

No thank you! If we revert to the old behaviour to make a couple
packages work, are you going to supply fixes for the _hundreds_ that
would be broken? Keep in mind that most make setups don't supply
'-Wl,-R' arguments unless they've been libtoolized, so you would have
to provide a custom solution for every package that uses shared
libraries in order for it to work on elf ports.

> > 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!  ;-)

I don't even have an answer for that.
 
> 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.

I doubt that you'd be scoffed at, if you supply patches to build
against a different library, or a newer version, or if you rename the
library to avoid a conflict. Unless, of course, you present yourself
badly.

More generally, you're going about it all wrong. You should fix the
thing that's broken, and then, if you find yourself repeating the same
fix in many different places, you generalize. That's how the LDFLAGS
evolved into it's present form. ISTR the '-Wl,-R' for elf ports came
first, but then it was a natural to mirror the behavior for aout, as
it permitted removing special handling in many, many packages.

There's an even better reason for setting LDFLAGS in configure's
environment. Most of the configure scripts search for libraries in
conventional places, "conventional" meaning, "conventional on other
systems". So setting LDFLAGS does as well as if the NetBSD path(s)  
were explicitly searched for in configure. If we installed all
packages in /usr/local (as some people do!), it might be impossible to
manipulate LDFLAGS to guarantee the right library. Besides, it's truly
inefficient to extract and build multiple versions of the same library
for many different packages, and it's wrong to have completely
different libraries with the same name. Just fix the broken package.