Date: Tue, 4 Apr 1995 11:20:48 -0400 (EDT) From: "William A. Arbaugh" <waa@aurora.cis.upenn.edu> To: Paul Traina <pst@cisco.com> Cc: jkh@FreeBSD.org, phk@FreeBSD.org, current@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: READ BEFORE SUPPING: critical change to login/su Message-ID: <Pine.A32.3.91.950404111531.29806C-100000@aurora.cis.upenn.edu> In-Reply-To: <v02110101aba674a55ec0@[171.69.126.217]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 4 Apr 1995, Paul Traina wrote: > Apparently, the linker does not resolve undefined symbols of shared libraries > at link time, and libskey.so.2.0 makes references to stuff found in libmd.a. > The modules in libmd.a that skey requires were not getting linked into the > actual programs that used skey, so when someone actually invoked skey based > programs like keyinit(1) there were unresolved runtime references > (bloody amazing this wasn't caught earlier). > I reported it last week to hackers. Would bugs or current been more appropriate? > Anyway, the "proper" fix here is to do away with libskey.so.2.0, as it's > really not a good idea for the skey stuff to be shared anyway, which means > that libskey.a and libmd.a will be linked in the old fashioned way and > the right things will happen. > Shouldn't the linker be fixed to handle the unresolved symbols from a shared library. I agree that skey shouldn't be a shared library, but that really isn't fixing the real problem though. Someone may stumble onto this again with another program that uses a mix of shared and static libraries. bill ----------------------------------------------------------------------- Bill Arbaugh email: waa@aurora.cis.upenn.edu office: Moore 102 phone: (215) 573-3639 FAX: (215) 573-2232 ------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.A32.3.91.950404111531.29806C-100000>