Subject: dilema with use of LDFLAGS=-L${LOCALBASE}/lib vs. private application libraries
To: NetBSD Packages Technical Discussion List <tech-pkg@NetBSD.ORG>
From: Greg A. Woods <woods@most.weird.com>
List: tech-pkg
Date: 10/18/1999 19:44:47
This is the second time I've encountered a problem with an application
in the pkgsrc tree that has a private library that clashes in name (and
function, etc.) with a public library from another totally unrelated
package.

The problem is the following line in pksrc/mk/bsd.pkg.mk:

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

Now this wouldn't normally be a problem except when a package uses an
internal library to build, and when that library clashes with a publicly
installed library from some other unrelated package, *and* when the
package uses '-L../lib' or similar, *and* when the package uses GNU
Autoconf.

Let us pretend that this package has a lib "libconflictlib.a" that
resides in ../lib (relative to the source for "product"), and that
there's also a "/usr/pkg/lib/libconflict.a" on the build system which
had been put there by some other unrelated package.  Let us also pretend
that '-ljpeg', also installed in /usr/pkg/lib, is required by this
package.  The result are compiler invocations such as:

     cc -o product -L/usr/pkg/lib -Wl,-R/usr/pkg/lib product.o -L../lib -lconflict -ljpeg

Because of the ordering of the '-L' arguments the wrong -lconflict will
be found.

I think in both cases I didn't need any libraries from any other package
and I was able to simply tromp on the value of LDFLAGS from bsd.pkg.mk
via the following hack:

+   .if !defined(NO_USE_LOCALBASE_LIBS)
    LDFLAGS+=		-Wl,-R${LOCALBASE}/lib -L${LOCALBASE}/lib
+   .endif

and then setting "NO_USE_LOCALBASE_LIBS" in the package Makefile.

I could also hack the package, but this gets very messy and tedious,
especially for large packages, and even more difficult if the package
were to also use GNU Automake.  Besides it's not a problem with the
package, per se.  If both packages used shared libraries then the only
solution would be to rename the least public library, but this is also
ugly, at least to me.

Does anyone have any other ideas?

(BTW, I'm not purposefully trying to hide which packages I'm having this
problem with -- just trying to show it in a generic light.)

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