The following reply was made to PR pkg/35617; it has been noted by GNATS.

From: Joerg Sonnenberger <joerg@britannica.bec.de>
To: Brook Milligan <brook@biology.nmsu.edu>
Cc: gnats-bugs@NetBSD.org, pkg-manager@NetBSD.org,
	gnats-admin@NetBSD.org, pkgsrc-bugs@NetBSD.org
Subject: Re: pkg/35617: shared library (e.g., libgdal.so) not built/installed
Date: Thu, 15 Feb 2007 21:25:17 +0100

 On Thu, Feb 15, 2007 at 01:12:57PM -0700, Brook Milligan wrote:
 > Joerg Sonnenberger writes:
 >  >  I strongly object such a fix.
 > 
 > However, this leads me to ask two questions.  First, could you please
 > explain your rationale for those of us who do not necessarily
 > understand why you object so strongly.  Perhaps there are obvious
 > platform-dependent issues that I do not know about that would lead to
 > this objection.
 
 For once, it is likely to trigger issues on Darwin/OS X. It is also very
 bad practise as it tends to hide the real issues, e.g. missing functions
 which got removed because they aren't "used" anymore. 
 
 In fact, I want to start making correct linkage a hard requirement for
 pkgsrc.
 
 > Second, could you please explain how to make the following work
 > correctly in the absence of this patch: a program loads via dlopen() a
 > plugin that in turn resolves symbols in libgdal.so.
 
 I think you are confusing cause and action here. There's one and only
 one situation where it is acceptable to have unresolved symbols in a
 shared object: if those are intended to be provided by the main program.
 Arguably that is extremely poor style. If it is really absolutely
 necessary to do that, it can often be worked around in a platform
 specific way.
 
 Independent of that, I don't think this is the culprit here. The
 gdal-lib package correctly builds a shared library on DragonFly, so it
 is unlikely to apply here. Can you check the build output for actual
 errors?
 
 Joerg