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

[Scott Long]

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