cvs commit: src/lib/msun/i387 fenv.c fenv.h
scottl at samsco.org
Fri Mar 18 11:12:31 PST 2005
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
> 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.
> 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.
More information about the cvs-all