cvs commit: src/lib Makefile.inc src/lib/libatm Makefile src/lib/libautofs Makefile src/lib/libbegemot Makefile src/lib/libbluetooth Makefile src/lib/libbsm Makefile src/lib/libbz2 Makefile src/lib/libc_r Makefile src/lib/libcrypt ...

[Hartmut Brandt]

John Baldwin wrote:
> On Friday 15 June 2007 06:33:21 pm Hartmut Brandt wrote:
>> John Baldwin wrote:
>>> On Sunday 20 May 2007 10:49:08 pm Daniel Eischen wrote:
>>>> deischen    2007-05-21 02:49:08 UTC
>>>>
>>>>   FreeBSD src repository
>>>>
>>>>   Modified files:
>>>>     lib/libautofs        Makefile 
>>> This isn't connected to the build AFAICT.
>>>
>>>>   Log:
>>>>   Bump library versions in preparation for 7.0.
>>>>   
>>>>   Ok'd by:        kan
>>> Was this bump supposed to be exhaustive?  The following libraries haven't 
> been 
>>> bumped relative to 6.x:
>>>
>>> - libalias
>>> - libbsnmp
>>>   - all the snmp_*.so modules
>> I'm probably not up-to-date with the handling of version numbers, but I 
>> would think that the snmp_*.so modules version numbers are meant to 
>> reflect the API version that these modules use (which is implemented by 
>> bsnmpd). This hasn't changed, so what would be the reason to bump that 
>> number? Same for libbsnmp.
> 
> If they depend on libc.so then they could try to pull libc.so.6 into an 
> existing binary using libc.so.7 (or vice versa).  Probably for snmp_* and 
> bsnmpd this doesn't matter since folks are likely to use the bsnmpd that 
> comes with the OS.  But we bumped all of this for 6.0, which is why I'm 
> asking if the bump was supposed to be exhaustive like 6.0, or if it was 
> intentionally only bumping a subset.  The fact that most of the ncurses 
> libraries were bumped but not the two 'libncurses*' suggests that at least 
> that case is a bug.

I see. I remember to have a problem with this kind of things when a 
loaded module tried to pull in a libc different from the one used by the 
main program.

harti