Re: HEADS UP: compat6x

On Sunday 03 December 2006 09:58, Daniel Eischen wrote:
On Sat, 2 Dec 2006, Doug Barton wrote:

John Hay wrote:
But even in all those other threads, never had there been a decent
answer why it is good to have two incompatible libraries with the same
number. It can only cause hurt.

No one has said that it won't be changed, only that it won't be
changed right this minute. It's ok if you don't understand all the
technical points that were made in the previous threads (I don't
understand them all either). But what you should realize is that this
is -current, and sometimes stuff breaks. If you can't deal with that,
run RELENG_6. Sorry to be so direct about it, but seriously ...

And we're going to enable symbol versioning which also
requires all libraries to have their version bumped
regardless. Once we have symbol versioning, we will
not have to bump library versions again (at least
in the libraries that are symbol versioned - libc,
libm, libthr, libptthread).

Yes, but it doesn't hurt to just bump things now. I actually agree with
John's argument that it is beneficial to allow folks on current to safely
use -stable apps by doing the library bump at first breakage. Granted, after
7.0 that policy will be obsolete, but it is still relevant for 7-current. :)
Heck, why not just enable symbol versioning in current by default now
anyways?

--
John Baldwin
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: libpthread shared library version number
    ... the line of what we have for other system libraries. ... We certainly should be bumping them ... would have to bump them again before a release, ... we should enable symbol versioning at ...
    (freebsd-current)
  • Re: HEADS UP: compat6x
    ... use -stable apps by doing the library bump at first breakage. ... why not just enable symbol versioning in current by default now ... change the way dependencies are recorded in shared libraries, ... only have to rebuild things once. ...
    (freebsd-current)
  • Re: [jakub@redhat.com:Linking against libpthread via -pthread?
    ... Dan Nelson wrote: ... and a third is linked to libpthread. ... I think symbol versioning only helps if you want to provide multiple ... It won't help two libraries that both want to ...
    (freebsd-current)
  • Re: [jakub@redhat.com:Linking against libpthread via -pthread?
    ... a "ldd libgomp.so.1" shows no dependence ... executable links to three shlibs, one library is linked to libc_r, ... I think symbol versioning only helps if you want to provide multiple ... It won't help two libraries that both want to provide the ...
    (freebsd-current)
  • Re: libpthread shared library version number
    ... the line of what we have for other system libraries. ... would have to bump them again before a release, ... we should enable symbol versioning at ...
    (freebsd-current)