Re: libpthread shared library version number

Ruslan Ermilov wrote:
On Thu, Nov 02, 2006 at 08:09:48AM -0600, Brooks Davis wrote:
On Thu, Nov 02, 2006 at 08:25:37AM -0500, Daniel Eischen wrote:
On Thu, 2 Nov 2006, Ruslan Ermilov wrote:

On Wed, Nov 01, 2006 at 04:07:38PM -0800, Maxim Sobolev wrote:
Guys,

I have noticed that libpthread shared library version number in 6-STABLE
and 7-CURRENT is the same (.2), which causes all threaded application
compiled for 6-STABLE to segfault when executed on 7-CURRENT system,
unless libpthread.so.2 is replaced with with its 6-STABLE version which
in turn will create problems with threaded apps compiled for 7-CURRENT.
IMHO we should increase version number in 7-CURRENT, so that it is in
the line of what we have for other system libraries.

Any objections?

Last time we bumped them was right before 6.0-RELEASE; we did it
both in HEAD and RELENG_6. We certainly should be bumping them
all again closer to a 7.0-RELEASE, when the RELENG_7 is about to
be created. If we bump some majors now, and break APIs later but
still before a release (we are allowed to do it in -CURRENT), we
would have to bump them again before a release, and because it's
No, in -current we force people to recompile everything. Plus
we have symbol versioning in the libraries most likely to be
effected. If we bump, we should enable symbol versioning at
the same time.
I agree with the last part, but I think we need to bump sooner rather
than later because we need to support binary only applications compiled
against 6.x (remember, we're not really supporting anything else so
smart vendors are going to build against it).

Hmm, bumping not versioned libraries *now* and not bumping them
again at pre-release would work, but doing it without also bumping
"to be versioned" libraries is IMO pointless. And if we bump all
of them now, we'll have to bump some of them again when versioning
is turned on by default.

No, we will not have to do it. Why would we? It's -CURRENT, so that nobody really cares about backward/forward compatibility within that branch.

-Maxim
_______________________________________________
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: Shared library version bump?
    ... :>> In preparation for release of 7.0, ... Hopefully this will be the last major bump for a long time... ... why bother with symbol versioning at all... ... If other libraries become symbol versioned after 7.0 gets ...
    (freebsd-current)
  • Re: HEADS UP: shared library bump, symbol versioning, libthr change
    ... > shared libraries themselves, so as long as libc sybols used by the ... > shared libraries will happily work with both. ... > they will start resolving to FBSD_1.0 symbols, but your bump will ... I certainly wouldn't mind you committing everything _but_ version bumping. ...
    (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)
  • Re: libpthread shared library version number
    ... we should enable symbol versioning at ... The only reason for this bump is to allow binaries compiled for -STABLE to run on -CURRENT, which is not currently possible in the case when binary uses pthreads lib. ... shared library to other shared libraries. ...
    (freebsd-current)
  • Re: __fpclassifyd problem
    ... >> The problem with bumping libm is that we also need, strictly speaking, ... >> to bump all libarires that depend on libm, and that can be very ugly. ... the next thing to try is using a complete exclusive set of 4.x libraries ...
    (freebsd-current)