Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 6 Feb 2004 23:27:10 -0800
From:      David Schultz <das@FreeBSD.ORG>
To:        "M. Warner Losh" <imp@bsdimp.com>
Cc:        ports@FreeBSD.ORG
Subject:   Re: HEADS UP: libkse -> libpthread switch
Message-ID:  <20040207072710.GA1369@VARK.homeunix.com>
In-Reply-To: <20040207.000718.29363133.imp@bsdimp.com>
References:  <20040205072422.GB11291@VARK.homeunix.com> <4023C100.2090305@freebsd.org> <20040207005520.GA7132@VARK.homeunix.com> <20040207.000718.29363133.imp@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Feb 07, 2004, M. Warner Losh wrote:
> In message: <20040207005520.GA7132@VARK.homeunix.com>
>             David Schultz <das@freebsd.org> writes:
> : Maybe I don't understand dynamic linking in FreeBSD well enough,
> : but an application that is both statically and dynamically linked
> : against the same library seems bizarre and unusual to me.
> : Wouldn't the two halves reference different copies of the library,
> : breaking things like malloc() and gethostbyname() (in the
> : hypothetical case of libc)?  I don't see how such a thing could
> : possibly work in the first place.
> 
> Such a thing is possible if at the time you built library X, it
> required library Y shared.  You then build program A that requires
> library X and Y, but link Y static.  Bad things happen after that.
> Esp if Y is libc or libc_r.

Yeah, I understand how it can happen, and I've even seen it on a
Solaris box.[1]  But Scott's message seems to imply that partially
statically linked binaries work right now, and that we need to
keep it that way moving into the next release, even at the expense
of potentially breaking fully dynamic binaries.  Perhaps he meant
something else.


[1] My initial thought was that FreeBSD did something differently
    such that this could work in FreeBSD but not in Solaris, but
    I just tried it and this is not the case.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040207072710.GA1369>