Date: Fri, 18 Mar 2005 12:14:22 -0700 From: Scott Long <scottl@samsco.org> To: Peter Jeremy <PeterJeremy@optushome.com.au> Cc: Warner Losh <imp@bsdimp.com> Subject: Re: cvs commit: src/lib/msun/i387 fenv.c fenv.h Message-ID: <423B288E.3090901@samsco.org> In-Reply-To: <423B2778.2070206@samsco.org> References: <20050317.233645.74714466.imp@bsdimp.com> <20050318064521.GA42508@VARK.MIT.EDU> <423A86D9.5030504@portaone.com> <20050318.005008.71126625.imp@bsdimp.com> <423A8B51.3010609@portaone.com> <423A8DC5.5010006@samsco.org> <20050318190828.GC30813@cirb503493.alcatel.com.au> <423B2778.2070206@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Scott Long wrote:
> Peter Jeremy wrote:
>
>> On Fri, 2005-Mar-18 01:13:57 -0700, Scott Long wrote:
>>
>>> No, I think that what he's worried about is that you have port foo that
>>> generates a library called libfoo.so.1, and that library is linked
>>> against libm.so.2. You then have port bar that generates a binary
>>> linked against libfoo.so.1 and libm.so.2. Now lets say that libm.so.2
>>> gets bumped to libm.so.3, and you also rebuild port bar. Now bar is
>>> linked to libfoo.so.1 and libm.so.3, but libfoo.so.1 is still linked
>>> against libm.so.2;
>>
>>
>>
>> Is it worthwhile checking (and warning) about this condition? Possible
>> options include:
>> 1) ld-elf.so learning that a .so is make up of a name and a version
>> number
>> and whinging if an executable attempts to load two shared libraries
>> with
>> the same name and different versions.
>
>
> This would definitely be good to have for diagnostic purposes, whether
> the mythical library versioning happens or not.
^^^^^^^
symbol
>
>> 2) ld(1) whinging (and failing) if the shared libraries on the command
>> line would result in the final executable being linked against two
>> different versions of a shared library.
>
>
> As you point out below, this does nothing for dlopen(), and I don't
> think that it'll provide enough useful information for end users.
>
>> 3) portupgrade (or even port dependency checking) doing an 'ldd' on each
>> dependency and either complaining or rebuilding any where the
>> dependency
>> predates a library bump. (Doing this properly probably means building
>> the port then discovering that it now needs multiple .so versions and
>> having to rebuild it after cleaning up the offending dependency).
>
>
> Yes, this would be interesting to have also.
>
> Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?423B288E.3090901>