cvs commit: src/lib/msun/i387 fenv.c fenv.h

[Peter Jeremy]

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.
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.
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).

Note that 2 and 3 don't pick up .so's that are dlopen()d by the code
and 3 only works for ports.

This is off the top of my head and further thought may suggest reasons
why the above aren't practical.

-- 
Peter Jeremy