Subject: Re: how to handle shared libraries
To: Rui Paulo <rpaulo@NetBSD.org>
From: Luke Mewburn <lukem@NetBSD.org>
List: tech-userlevel
Date: 08/25/2005 13:35:35
--1Dvf9Qz7hFaodvwE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Aug 18, 2005 at 07:40:59PM +0100, Rui Paulo wrote:
  | On 2005.08.18 20:30:06 +0000, Julio M. Merino Vidal wrote:
  | | On 8/18/05, Rui Paulo <rpaulo@netbsd.org> wrote:
  | | > Hi,
  | | > I'm modifing a makefile and I noticed that there is no ${LIBXXX} for
  | | > shared objects, only for ar(1) archives.
  | |=20
  | | Which library is that?  Maybe the shared library is not created for a
  | | reason (such as the API not being stable yet, as done in some
  | | X libraries).
  |=20
  | The shared library is libssl. What I am asking is if what I did is corr=
ect
  | or not and if we do have varnabes for shared objects like we have for
  | ar archives.

I've been considering solving this problem for other reasons
(to support MKSTATIC=3Dno), but the solution is more complicated
that you'd think.

In general, we want to have the "library dependency make variable"
use the .so if the program is dynamically linked and the .so is
available, else use the .a.  This means that updating libc.so
but not libc.a would mean that a program would detect that it
needs to be relinked again.  Except there's special cases that
need dealing with.

I investigated this a while ago (as part of fixing the aforementioned
MKSTATIC=3Dno issue), but I haven't finished getting my solution
to work yet.

Cheers,
Luke.

--1Dvf9Qz7hFaodvwE
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (NetBSD)

iD8DBQFDDTyHpBhtmn8zJHIRAmg3AJ9mwHYCMWqEESHCfqSvkOrZ3GIGNwCfcvt5
Iifb/R1Ktk3VDtyPVt2CUZs=
=YKsx
-----END PGP SIGNATURE-----

--1Dvf9Qz7hFaodvwE--