Date: Tue, 4 Apr 1995 10:07:09 -0600 From: Nate Williams <nate@trout.sri.MT.net> To: "William A. Arbaugh" <waa@aurora.cis.upenn.edu>, Paul Traina <pst@cisco.com> Cc: current@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: READ BEFORE SUPPING: critical change to login/su Message-ID: <199504041607.KAA06084@trout.sri.MT.net> In-Reply-To: "William A. Arbaugh" <waa@aurora.cis.upenn.edu> "Re: READ BEFORE SUPPING: critical change to login/su" (Apr 4, 11:20am)
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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). The reason it wasn't caught earlier is because the linker depended on certain characteristics of linking which I changed. > Shouldn't the linker be fixed to handle the unresolved symbols from a > shared library. Yes. > 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. I am planning on fixing this, but the whole shared lib/linker code is very new to me. If anyone feels like jumping in feel free to do so since my time is limited due to work commitments. (though sleep will become less important as the release date looms closer). Having two sets of eyes looking through the code certainly can't hurt. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504041607.KAA06084>