You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Peter Samuelson <pe...@p12n.org> on 2006/03/10 23:15:53 UTC
libsvn SONAMEs and APR
Debian subversion builds will soon be moving to apr 1.2, in lockstep
with Debian apache2. (Because of mod_dav_svn, we have no choice.) We
know this will occasion an ABI change to libsvn, so this requires
changing the embedded SONAMEs of the libraries. (See footnote for a
quick introduction to SONAMEs.)
I note that subversion currently has no particular notion of library
versions - which I suppose is OK since you're committed to never
changing the ABI incompatibly - but it's probably better to be
explicit. Anyway, libtool generates its own default SONAMEs:
$ objdump -p /usr/lib/libsvn_client-1.so.0 | grep SONAME
SONAME libsvn_client-1.so.0
I'll need to adjust this in some way, to denote the ABI change caused
by the new apr. I'll do it myself on Debian if I have to, but I'd
prefer to avoid this, as it'll create a gratuitous incompatibility
between Linux distributions. E.g., if Fedora also decides to build
subversion 1.3 with apr 1.2, our binaries won't work on Fedora, or vice
versa, unless they happen to make the *same* change to the SONAME
strings that I do.
Would you consider accepting a patch to make SONAME handling explicit
in the Makefile, and also make it sensitive to apr version? Would you
consider this for 1.3.1 or 1.3.2? I'll try to prepare and test a patch
in the next day or two.
Thanks,
Peter
[*] Quick introduction to the SONAME feature: it's a free-form string
embedded in an ELF-format library. A binary linked to the library
copies the SONAME field so that it can look for that exact string, as a
filename, at runtime. (The filename will be a symlink to the library,
placed in /usr/lib or /usr/local/lib or similar.) If an ABI changes
incompatibly, the SONAME of the library must change as well, so that if
you run an old binary, it won't pick up the new, incompatible library -
either it finds a copy of the old, compatible library, or it gets a
runtime error and quits. The SONAME typically takes the form
"libfoo.so.N", but the only thing that really matters is that it be
unique for a given library ABI. The term "SOVERSION" seems to mean the
part of the SONAME that changes between ABIs, but it's not a terribly
well defined term so it's best avoided.
SONAMEs aren't intended to solve the problem of a new binary picking up
an old library and trying to use new features which are missing.
That's a *compatible* ABI change to the library. The *incompatible*
change I'm talking about in this message is the change of apr_off_t
from 32 bits to 64 bits on 32-bit platforms, which affects libsvn's ABI
as well.
Re: libsvn SONAMEs and APR
Posted by Peter Samuelson <pe...@p12n.org>.
[Justin Erenkrantz]
> I'm not sure why we need a SONAME for Subversion or APR.
Because that's how runtime linking on ELF platforms works.
I don't know how all OS platform maintainers feel, but on Debian, we
don't assume that when you upgrade one library you will be willing to
recompile everything that depends on it. We do whatever we can to make
sure your system, and all the binaries on it, continue to work. The
ELF SONAME feature, when used properly, makes this job a lot easier and
more reliable. Thus in Debian we have a policy of always using it
properly - not doing so is considered a bug.
As for libsvn, we have to use the same version of libapr that apache2
uses, because mod_dav_svn must link to libsvn and it must work with
apache2. This requirement drives the version of libapr we link to.
Now we've got an incompatible change coming up where we'll need to
switch from apr 0.9 to apr 1.2. Normally such a thing would be no big
deal, but in this case it means libsvn's own interface changes
incompatibly.
Beyond the Debian policy of using the library SONAME as it was meant to
be used (i.e., to uniquely identify a compatible ABI), the practical
reason we have to change it now is to allow the old and new libsvn's to
coexist on a single system. Old binaries compiled before the change
will use the old libsvn, new binaries compiled after the change will
use the new one. Thanks to the SONAME feature, this works pretty much
automatically, so long as you change it when you need to change it.
(The other thing we have to do is arrange for the old and new packages
to coexist, but that's easy enough, and outside the scope of this
discussion.)
> Shouldn't Debian be linking against APR 1.2 instead of 0.9 now? Why
> wouldn't the standard library dependency code catch this mis-match
> then?
First of all, an app that links to libsvn won't necessarily recursively
link to libapr 0.x or 1.x. That's required on some platforms but not
on ELF, since recursive runtime linking is easy and done by default.
Second, if an app does link to both libsvn and libapr 0.x, and then
tries to run with a libsvn that pulls in libapr 1.x, it may or may not
actually be caught as a runtime-link-time error. It's not actually
forbidden to link (indirectly) to two or more versions of the same
library. More likely, you'll get mysterious seg faults as the wrong
symbols are used in the wrong places. If you avoid the seg faults,
you'll also get madness where client code and library code don't agree
on the size of svn_off_t when it appears in structures or stack
parameters.
2a) In case you were assuming otherwise, libapr-0 and libapr-1 can both
be installed on the same Debian system. Some apps will use one, some
will use the other, and thanks to SONAMEs this works seamlessly. So in
any case, you can't detect which libapr is used for libsvn just by
seeing whether libapr-0 or libapr-1 are available. Commonly they both
will be.
If linking to libapr 0.x vs. libapr 1.x didn't change the exported
Subversion ABI, the SONAME of libsvn wouldn't need to change, and we
wouldn't be having this conversation at all.
> Are you saying that there may exist a hypothetical APR 1.x library
> that doesn't support LFS?
No.
> IIRC, the Debian patch to libtool overrides the GNU linker DT_NEEDED
> flags and just might cause this specific problem - as the binaries
> will ignore accompanying libraries and use only installed libraries
> in /usr/lib. If the case is that Debian didn't screw with libtool we
> wouldn't have this problem, then I'm not sure why we need to fix
> their brokenness.
You seem to have some bitterness in your heart toward the Debian
libtool changes. (: But the SONAME issue, though it also deals with
libtool, has nothing to do with that particular change.
I hope this message clarifies some things. If not, I'll try to clarify
further as needed.
Peter
Re: libsvn SONAMEs and APR
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 3/10/06, Peter Samuelson <pe...@p12n.org> wrote:
> Debian subversion builds will soon be moving to apr 1.2, in lockstep
> with Debian apache2. (Because of mod_dav_svn, we have no choice.) We
> know this will occasion an ABI change to libsvn, so this requires
> changing the embedded SONAMEs of the libraries. (See footnote for a
> quick introduction to SONAMEs.)
>
> I note that subversion currently has no particular notion of library
> versions - which I suppose is OK since you're committed to never
> changing the ABI incompatibly - but it's probably better to be
> explicit. Anyway, libtool generates its own default SONAMEs:
I'm not sure why we need a SONAME for Subversion or APR. Shouldn't
Debian be linking against APR 1.2 instead of 0.9 now? Why wouldn't
the standard library dependency code catch this mis-match then? In
other words, if a FC Subversion 1.3 binary tried to run on Debian,
shouldn't it be looking for libapr-0.so? (If it linked against APR
1.x, then it's safe to assume LFS.)
Are you saying that there may exist a hypothetical APR 1.x library
that doesn't support LFS? If so, that's an option that the packager
had to explicitly override - why are we having to worry about that?
IIRC, the Debian patch to libtool overrides the GNU linker DT_NEEDED
flags and just might cause this specific problem - as the binaries
will ignore accompanying libraries and use only installed libraries in
/usr/lib. If the case is that Debian didn't screw with libtool we
wouldn't have this problem, then I'm not sure why we need to fix their
brokenness. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libsvn SONAMEs and APR
Posted by Peter Samuelson <pe...@p12n.org>.
[Justin Erenkrantz]
> We have explicitly decided in the past that the binary compatibility
> only matters for the Subversion code we distribute - not any of the
> dependencies or how they present themselves in the Subversion ABI.
I don't think there's much more I can say that will convince you that
your approach is a problem. I'm interested in smooth upgrades for
users currently on apr 0.9, which is what subversion 1.3.0 ships with.
You're interested in smooth upgrades for users who already switched to
apr 1.x and already had to recompile all their apps, _and_ who intend
to remove their old libsvn_* files after compiling the new ones, even
if the names didn't overlap.
So let me instead recommend that you document this: if a user upgrades
apache to 2.2 and wishes to use mod_dav_svn, she must not only
recompile mod_dav_svn (no avoiding that, you actually have to recompile
_all_ apache modules) but she must _also_ recompile all apps which use
the subversion libraries, whether or not they have anything to do with
apache. And, that you don't consider this a binary compatibility
problem, even though you chose long ago to tightly couple the
subversion API/ABI to the apr API/ABI.
I think it's only fair for users to know they will have to do this, and
that you disavow any responsibility for mysterious seg faults if they
forget.
Meanwhile, I hate to have to break binary compatibility between Debian
and other Linux distributions, but I'll do it anyway. I have no
choice. I would face a lot more angry users (and fellow developers)
for breaking applications compiled on Debian than for breaking Fedora
RPMs people try to install on Debian.
Peter
Re: [PATCH] libsvn SONAMEs and APR
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 3/31/06, Peter Samuelson <pe...@p12n.org> wrote:
> If the status quo means, as you argue, that Subversion already
> explicitly supports apr 1.x, then you have already broken the promise
> or expectation of binary compatibility for libsvn_*. That being the
> case, I do not see an additional evil in doing it again, assuming (as I
> have argued) that there are solid technical reasons to do so.
That's not true. We have explicitly decided in the past that the
binary compatibility only matters for the Subversion code we
distribute - not any of the dependencies or how they present
themselves in the Subversion ABI. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libsvn SONAMEs and APR
Posted by Marcus Rueckert <da...@web.de>.
On 2006-03-31 05:43:43 -0600, Peter Samuelson wrote:
> One last point: I also dispute the 18-month figure. apr 1.x may have
> been around that long, but Apache 2.2 has only been available for 4
> months. I would bet that most users only migrated subversion to apr
> 1.x when they installed Apache 2.2.
or they needed/wanted LFS support.
darix
--
openSUSE - SUSE Linux is my linux
openSUSE is good for you
www.opensuse.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libsvn SONAMEs and APR
Posted by Peter Samuelson <pe...@p12n.org>.
[Joe Orton]
> Sorry, that message was rather obtuse :) My argument was supposed to be:
> current Subversion releases already implicitly and explicitly support
> APR 1.x (and hence httpd 2.2), therefore changing the SVN library
> sonames based on use of APR 1.x is an unreasonable break of backwards
> compatibility.
Thanks for clarifying.
If the status quo means, as you argue, that Subversion already
explicitly supports apr 1.x, then you have already broken the promise
or expectation of binary compatibility for libsvn_*. That being the
case, I do not see an additional evil in doing it again, assuming (as I
have argued) that there are solid technical reasons to do so.
> I think it would certainly be unreasonable for the SVN project to
> refuse to support APR 1.x/httpd 2.2 (in some abstract way) merely
> because SVN cannot be packaged to allow backwards-compat across APR
> major versions, which is something I'd presume the vast majority of
> users don't care about (witness, lack of anybody caring about it for
> the 18 months APR 1.x has been available).
I don't quite see how you can have it both ways. If the vast majority
of users don't care, why _not_ make a change which is agreed to be
technically correct but breaks a promise (which has already been
implicitly broken once)?
I think ghudson hit upon something when he noted that early adopters of
apr 1.x already accepted the need to recompile all their binaries that
use libsvn; they shouldn't mind having to do it again. Put another
way: there are two classes of people using subversion with apr 1.x:
users of early-adopter distributors like Fedora, and early-adopter
users who compile this stuff on their own. For the former, users
shouldn't even notice the change - the job of the distributor is to
make these things happen smoothly. For the latter, 'make install' will
not overwrite their old libraries (since the filenames have changed),
so their old apps will continue to work with the old library, until
they happen to recompile them.
One last point: I also dispute the 18-month figure. apr 1.x may have
been around that long, but Apache 2.2 has only been available for 4
months. I would bet that most users only migrated subversion to apr
1.x when they installed Apache 2.2. It may not change the substance of
your argument to go from 18 months to 4 months, but I think it's worth
noting. Remember, four months ago, 1.3.0 was in the middle of its long
release process (I think it was at rc5 or so). Given that the release
was already somewhat delayed, even if I had realised at the time that
this problem was worth bringing up in public, I don't think it would
have been reasonable to delay the 1.3.0 release even further over it.
Peter
Re: [PATCH] libsvn SONAMEs and APR
Posted by Joe Orton <jo...@manyfish.co.uk>.
On Fri, Mar 31, 2006 at 01:48:46AM -0600, Peter Samuelson wrote:
> * http://svn.haxx.se/dev/archive-2006-03/0583.shtml
> Joe Orton agrees that delaying this decision hurts users. He _seems_
> to be suggesting that apache 2.2 not be supported at all until
> Subversion 2.0, but I hate to put words in someone's mouth - Joe, can
> you clarify what position you think Subversion should take on this?
Sorry, that message was rather obtuse :) My argument was supposed to be:
current Subversion releases already implicitly and explicitly support
APR 1.x (and hence httpd 2.2), therefore changing the SVN library
sonames based on use of APR 1.x is an unreasonable break of backwards
compatibility.
There seemed to be a presumption that the premise of that argument was
not true, which is what I was trying to refute in my message by pointing
out that the SVN build system supports use of APR 1.x, and that support
for APR 1.x was advertised in the 1.1.2 CHANGES entry.
To be clear, I think this would have been a good idea had it been done
either before the Subversion 1.x release or before the APR 1.0 release,
and it would be a good idea to do it for Subversion 2.x, but it would be
unreasonable to do it in mid-1.x.
I think it would certainly be unreasonable for the SVN project to refuse
to support APR 1.x/httpd 2.2 (in some abstract way) merely because SVN
cannot be packaged to allow backwards-compat across APR major versions,
which is something I'd presume the vast majority of users don't care
about (witness, lack of anybody caring about it for the 18 months APR
1.x has been available). Debian can make that choice, of course; or
just use different SVN sonames to upstream.
Regards,
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libsvn SONAMEs and APR
Posted by Michael Sweet <mi...@easysw.com>.
Justin Erenkrantz wrote:
> On 3/31/06, Michael Sweet <mi...@easysw.com> wrote:
>> Given that Subversion is so closely tied to APR, it would make sense
>> to offer an alternate DSO version number when compiled against APR
>> 1.x. Assuming that APR doesn't make any more disruptive changes
>> like the 0.x to 1.x transition, that'll just mean that Subversion 2
>> will have a DSO major version of 3 (or whatever) instead of 1.
>> Alternately, you could use numbered suffix on the library name, e.g.
>> "libsvn_client2".
>
> -1 as that needlessly breaks people who are already happy with APR 1.x
> and SVN. -- justin
Nothing prevents you from symlinking the .2 DSO to .1 on systems that
have been shipping Subversion with APR 1.x already. And if you are
installing from source, the previous install will provide the .1
dependency until they relink the affected programs.
The problem with the current situation is that things can break in
mysterious and unpredictable ways when a distro or user upgrades
from APR 0.x to 1.x.
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Document Software http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libsvn SONAMEs and APR
Posted by Peter Samuelson <pe...@p12n.org>.
[Justin Erenkrantz]
> Debian purposely disables libtool's implicit linking features - but,
> in all releases we've ever shipped, our distributed GNU libtool's
> will end up implicitly linking to all dependent libraries.
True for libsvn itself, not true for third-party applications unless
*they* use libtool as well. And that's a local decision, or at least a
decision out of the hands of subversion. Certainly on Debian we very
much discourage linking to indirect dependencies; I don't know how
other distributors and administrators handle this.
> Do *any* other projects encode their dependencies in their SONAMEs?
> I sort of doubt it. AFAICT, the GNOME packages don't encode the
> SONAME of glib in there; but libgnome can work off several different
> versions of glib.
I don't think that's quite true. libgtk 2.x and libglib 2.x are
intended to be backward-ABI-compatible in the same way libsvn 1.x is.
gtk 2 requires glib 2; I _believe_ gtk 1 cannot use glib 2. Neither
project has released a version 3 yet. So unless I'm mistaken, the
issue hasn't come up.
Recommended practice is, when publishing an API, to try to make sure
you don't expose any interfaces from third-party libraries in your ABI;
you wrap whatever you need to wrap using your own typedefs and structs
and wrapper functions. This cuts way down on the pain you pass on to
your downstream users, though it requires some trouble, and some
vigilance to make sure you're not inadvertently leaking ABIs you don't
control. (Not counting libc; it's hard to avoid *that*.)
Thus in Debian at least, it is very common for a library to be upgraded
to use libmysql14 instead of libmysql12, or libpng3 instead of libpng2,
without any applications breaking or having to be recompiled.
Obviously the Subversion project chose not to do this for apr, and I do
agree that this was a sound decision - especially the part where you
made this position clear to downstream developers. It wasn't a
mistake, but it _does_ make this a special case. For example, you
don't tell users of libsvn_fs that they have to learn the BDB API;
downstream binaries are free to link or not link -ldb4.x.
Peter
Re: [PATCH] libsvn SONAMEs and APR
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 4/10/06, Philip Martin <ph...@codematters.co.uk> wrote:
> "Garrett Rooney" <ro...@electricjellyfish.net> writes:
>
> > We're already providing http-2.2/apr-1.2 as an option, many people
> > (myself included) have gone and build svn with them and have been
> > doing so since httpd 2.2 came out, or even before that for those who
> > just wanted the latest apr and didn't care about httpd, I just want to
> > be sure we don't screw things up for those users.
>
> We "screwed up" when we provided an option that broke the ABI. I'm
> proposing another option that will "screw up" those who ignored the
> first "screw up". If they choose to use the new option they will have
> to rebuild, just as they would have had to rebuild when they chose the
> first option. If things were really to be on an equal footing then we
> would require a configure option to enable APR > 0.9.x, but since you
> got your "screw up" in first it gets enabled by deafult :)
Ok, as long as it's optional that's fine with me. Maybe in 2.0 we can
actually try and get this stuff "right" ;-)
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libsvn SONAMEs and APR
Posted by Philip Martin <ph...@codematters.co.uk>.
"Garrett Rooney" <ro...@electricjellyfish.net> writes:
> We're already providing http-2.2/apr-1.2 as an option, many people
> (myself included) have gone and build svn with them and have been
> doing so since httpd 2.2 came out, or even before that for those who
> just wanted the latest apr and didn't care about httpd, I just want to
> be sure we don't screw things up for those users.
We "screwed up" when we provided an option that broke the ABI. I'm
proposing another option that will "screw up" those who ignored the
first "screw up". If they choose to use the new option they will have
to rebuild, just as they would have had to rebuild when they chose the
first option. If things were really to be on an equal footing then we
would require a configure option to enable APR > 0.9.x, but since you
got your "screw up" in first it gets enabled by deafult :)
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libsvn SONAMEs and APR
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 4/10/06, Philip Martin <ph...@codematters.co.uk> wrote:
> "Garrett Rooney" <ro...@electricjellyfish.net> writes:
>
> > The point is that the APR ABI can change in various ways even within
> > the same version number, and anything that doesn't take that into
> > acount will be almost as fragile as the system we've got now.
>
> I have already agreed that there are ways to defeat it, just as there
> are ways to defeat the current Subversion run-time BDB version checks.
> However what I am suggesting is that we support the two default
> configurations http-2.0/apr-0.9 and http-2.2/apr-1.2. Are you really
> suggesting that we should not provide that as an option?
We're already providing http-2.2/apr-1.2 as an option, many people
(myself included) have gone and build svn with them and have been
doing so since httpd 2.2 came out, or even before that for those who
just wanted the latest apr and didn't care about httpd, I just want to
be sure we don't screw things up for those users.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
another [PATCH] --enable-soname-depend-on-apr
Posted by Philip Martin <ph...@codematters.co.uk>.
"Justin Erenkrantz" <ju...@erenkrantz.com> writes:
> On 4/10/06, Philip Martin <ph...@codematters.co.uk> wrote:
>> I don't understand, are you claiming that a third-party application
>> must use libtool?
>
> If they are linking against our libraries, yes.
>
> Linking against our libraries will only work consistently across all
> supported platforms if the downstream app uses libtool. libtool has
> the ability to tweak internal link options that we didn't know were
> being touched. Therefore, if you try to bypass libtool and use the
> bare linker, you may not select the right linker flags or dependencies
> on specific platforms.
I don't think libtool is necessary on an ELF platform. Of course all
sorts of compiler flags could break the ABI, but once again I am not
interested in corner cases. Subversion's own Perl bindings don't use
libtool, and while the perl bindings have problems (ones that would
not apply to a third-party user of the Subversion libraries) it does
indicate that libtool is not strictly necessary. If libtool were to
produce libraries that were incompatible with "standard" shared
libraries on a platform which has good support for such libraries then
I think that would be a libtool bug.
>> Are we talking at cross purposes on libtool? I'm proposing a patch
>> along the lines of Peter's patch, but under some --enable-foo flag and
>> possibly restricting APR to either 0.9.x or 1.2.x
>
> Which patch are you referring to specifically?
http://svn.haxx.se/dev/archive-2006-03/0522.shtml
> If you want to tweak
> the SONAME, you have to alter libtool as it produces the SONAMEs - not
> Subversion. The feature Peter wanted was to install multiple versions
> of the SVN libraries in the same directory but have them linked
> against different APRs. Like so:
>
> libsvn_fs-1.so.0.0.0.APR0APRUTIL0
> libsvn_fs-1.so.0.0.0.APR1APRUTIL1
Not quite, Peter's patch produced a SONAME like libsvn_fs-1.so.1 so
the library would be libsvn_fs-1.so.1.0.0.
I'd suggest a patch where APR 0.9.x leads to libsvn_fs-1.so.0.0.0, as
at present, and APR 1.2.x produces libsvn_fs-1.so.1.0.0, with
everything else being an error. Not tested, but something like:
Index: Makefile.in
===================================================================
--- Makefile.in (revision 19191)
+++ Makefile.in (working copy)
@@ -92,6 +92,7 @@
SHELL = @SHELL@
LIBTOOL = @SVN_LIBTOOL@
LTFLAGS = @SVN_LT_CCTAG@ --silent
+LT_SOVERSION = @SVN_LT_SOVERSION@
LTCXXFLAGS = @SVN_LT_CXXTAG@ --silent
LT_LDFLAGS = @LT_LDFLAGS@
LT_NO_UNDEFINED = @LT_NO_UNDEFINED@
@@ -156,7 +157,7 @@
COMPILE_JAVAHL_JAVAC = $(JAVAC) $(JAVAC_FLAGS)
COMPILE_JAVAHL_JAVAH = $(JAVAH)
-LINK = $(LIBTOOL) $(LTFLAGS) --mode=link $(CC) $(LT_LDFLAGS) $(CFLAGS) $(LDFLAGS) -rpath $(libdir)
+LINK = $(LIBTOOL) $(LTFLAGS) --mode=link $(CC) $(LT_LDFLAGS) $(CFLAGS) $(LDFLAGS) $(LT_SOVERSION) -rpath $(libdir)
# special link rule for mod_dav_svn
LINK_APACHE_MOD = $(LIBTOOL) $(LTFLAGS) --mode=link $(CC) $(LT_LDFLAGS) $(CFLAGS) $(LDFLAGS) -rpath $(APACHE_LIBEXECDIR) -avoid-version -module $(APACHE_LDFLAGS)
Index: configure.in
===================================================================
--- configure.in (revision 19191)
+++ configure.in (working copy)
@@ -58,6 +58,28 @@
SVN_LIB_APR($APR_VER_REGEXES)
SVN_LIB_APRUTIL($APU_VER_REGEXES)
+SVN_LT_SOVERSION="-version-info 0"
+AC_ARG_ENABLE(soname-depend-on-apr,
+ AC_HELP_STRING([--enable-soname-depend-on-apr],
+ [make the Subversion SONAME depend on the APR version]),
+ [
+ if test "$enableval" = "yes" ; then
+ AC_MSG_CHECKING([which Subversion SONAME to use])
+ if test `expr $apr_version : 0.9` -ne 0; then
+ AC_MSG_RESULT([libsvn_xxx-1.so.0])
+ else
+ if test `expr $apr_version : 1.2` -ne 0; then
+ AC_MSG_RESULT([libsvn_xxx-1.so.1])
+ SVN_LT_SOVERSION="-version-info 1"
+ else
+ AC_MSG_ERROR([APR $apr_version unsupported])
+ fi
+ fi
+ fi
+ ],
+ [])
+AC_SUBST(SVN_LT_SOVERSION)
+
# Either a space-separated list of allowable Neon versions, or "any" to
# mean allow anything.
NEON_ALLOWED_LIST="0.24.7 0.25.0 0.25.1 0.25.2 0.25.3 0.25.4 0.25.5"
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libsvn SONAMEs and APR
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/10/06, Philip Martin <ph...@codematters.co.uk> wrote:
> I find that odd given that apr_off_t is part of Subversion's ABI.
If we didn't have apr_off_t but used off_t, the ABI would change
depending upon your compiler flags (32-bit or 64-bit offsets). So?
> > If your app happens to work without libtool, good for you; but
> > removing libtool from the chain isn't something that we can support.
>
> I don't understand, are you claiming that a third-party application
> must use libtool?
If they are linking against our libraries, yes.
Linking against our libraries will only work consistently across all
supported platforms if the downstream app uses libtool. libtool has
the ability to tweak internal link options that we didn't know were
being touched. Therefore, if you try to bypass libtool and use the
bare linker, you may not select the right linker flags or dependencies
on specific platforms.
> Are we talking at cross purposes on libtool? I'm proposing a patch
> along the lines of Peter's patch, but under some --enable-foo flag and
> possibly restricting APR to either 0.9.x or 1.2.x
Which patch are you referring to specifically? If you want to tweak
the SONAME, you have to alter libtool as it produces the SONAMEs - not
Subversion. The feature Peter wanted was to install multiple versions
of the SVN libraries in the same directory but have them linked
against different APRs. Like so:
libsvn_fs-1.so.0.0.0.APR0APRUTIL0
libsvn_fs-1.so.0.0.0.APR1APRUTIL1
The app, via SONAME, when asked to link against libsvn_fs-1.so would
really link against libsvn_fs-1.so.0.0.0.APR1APRUTIL1.
HTH. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libsvn SONAMEs and APR
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2006-04-10 at 16:27 -0700, Justin Erenkrantz wrote:
> On 4/10/06, Greg Hudson <gh...@mit.edu> wrote:
> > glib provides a consist ABI within major versions. (I dispute that glib
> > primitive sizes have changed between point releases.) No downstream
> > library works with both glib 1.x and glib 2.x.
>
> There were some incorrect autoconf checks around file offsets - look
> at early versions of glib 2.x. So, yes, the ABI has the potential to
> change within a major version in glib.
So, either you're wrong, or glib screwed up and violated the ABI
compatibility rules. I don't see how either case is relevant to us.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libsvn SONAMEs and APR
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/10/06, Greg Hudson <gh...@mit.edu> wrote:
> glib provides a consist ABI within major versions. (I dispute that glib
> primitive sizes have changed between point releases.) No downstream
> library works with both glib 1.x and glib 2.x.
There were some incorrect autoconf checks around file offsets - look
at early versions of glib 2.x. So, yes, the ABI has the potential to
change within a major version in glib.
*shrug* -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libsvn SONAMEs and APR
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2006-04-10 at 16:11 -0700, Justin Erenkrantz wrote:
> Please take a look at how a typical glib, gtk+, etc. apps expose
> glib/gtk+ ABIs. When a glib primative size changes (which has the
> potential of changing in a couple of 2.x.y point releases of glib), so
> does the ABI for that downstream application.
glib provides a consist ABI within major versions. (I dispute that glib
primitive sizes have changed between point releases.) No downstream
library works with both glib 1.x and glib 2.x.
> But, the solution to this is not to create our own internal copy of
> every APR data structure and only expose our 'private' copy - because
> if the APR ABI does indeed change without Subversion recompiling,
> we're just as horked as we were before. -- justin
If the ABI changes without the soname changing, the downstream library
has screwed up. (Non-default configure options which affect the ABI
aren't really an issue here; if the packager or site administrator uses
such options inconsistently, then that's their problem.) APR hasn't
screwed up here, because the major version and soname changed when the
ABI changed.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libsvn SONAMEs and APR
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/10/06, Greg Hudson <gh...@mit.edu> wrote:
> On Mon, 2006-04-10 at 15:42 -0700, Justin Erenkrantz wrote:
> > I don't view APR's ABI as part of Subversion's.
>
> That's an odd statement. Subversion's ABI demonstrably changes if you
> compile it against APR 0.9 and then again against APR 1.0 (both in their
> default configurations), as the size of apr_off_t changes, and that type
> is used in several Subversion structures and functions.
So? I view it the same as if a libc ABI changes: Subversion can't
hide all of its dependencies - we're a compiled binary targeted at a
specific platform with specific libraries, not a dynamic interpreted
program.
Please take a look at how a typical glib, gtk+, etc. apps expose
glib/gtk+ ABIs. When a glib primative size changes (which has the
potential of changing in a couple of 2.x.y point releases of glib), so
does the ABI for that downstream application.
The solution that downstream packagers seem to use is to ensure that
all of the versions are upgraded in-line - which works fine for SVN
and APR too.
But, the solution to this is not to create our own internal copy of
every APR data structure and only expose our 'private' copy - because
if the APR ABI does indeed change without Subversion recompiling,
we're just as horked as we were before. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libsvn SONAMEs and APR
Posted by Philip Martin <ph...@codematters.co.uk>.
"Garrett Rooney" <ro...@electricjellyfish.net> writes:
> The point is that the APR ABI can change in various ways even within
> the same version number, and anything that doesn't take that into
> acount will be almost as fragile as the system we've got now.
I have already agreed that there are ways to defeat it, just as there
are ways to defeat the current Subversion run-time BDB version checks.
However what I am suggesting is that we support the two default
configurations http-2.0/apr-0.9 and http-2.2/apr-1.2. Are you really
suggesting that we should not provide that as an option?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libsvn SONAMEs and APR
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2006-04-10 at 15:42 -0700, Justin Erenkrantz wrote:
> I don't view APR's ABI as part of Subversion's.
That's an odd statement. Subversion's ABI demonstrably changes if you
compile it against APR 0.9 and then again against APR 1.0 (both in their
default configurations), as the size of apr_off_t changes, and that type
is used in several Subversion structures and functions.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libsvn SONAMEs and APR
Posted by Philip Martin <ph...@codematters.co.uk>.
"Justin Erenkrantz" <ju...@erenkrantz.com> writes:
> On 4/10/06, Philip Martin <ph...@codematters.co.uk> wrote:
>> That doesn't really address my point. You probably know more than me,
>> but as I understand it backporting full LFS to APR 0.9.x is simple
>> except that it would be an unacceptable ABI change. Nothing you have
>> written explains why you are happy to make the same ABI change in
>> Subversion.
>
> I don't view APR's ABI as part of Subversion's.
I find that odd given that apr_off_t is part of Subversion's ABI.
>> > Even then, it's still very possible for LFS to be toggled on or off
>> > even in the same 'library' version of APR/APR-util. Same goes for
>> > threading, mmap, etc.
>>
>> I'm not really interested in corner cases, although I suspect that
>> threading is handled by 'apr-config --cflags' and that mmap doesn't
>> change the ABI.
>
> As Garrett points out, those features changes the ABI by adding or
> removing APR symbols.
>
>> > Those apps *should* be linking with libtool. If not, it's very likely
>> > that it may not compile or link appropriately.
>>
>> I disagree, libtool is optional.
>
> If your app happens to work without libtool, good for you; but
> removing libtool from the chain isn't something that we can support.
I don't understand, are you claiming that a third-party application
must use libtool?
>> Since nobody else appears to care about this problem I don't think
>> it's sensible to change the default. How about a configure option to
>> allow people to choose to get (or set?) a different SONAME? After all
>> it is simple to support http-2.0/apr-0.9 and http-2.2/apr-1.2 in
>> parallel so we should provide a standard way to do it even if it is
>> not the default.
>
> As I've said before, feel free to make it optional. However, you
> might run head-first into libtool to get it to set non-numeric custom
> SONAMEs - as it relies upon versions of the order X.Y.Z to set the
> SONAME. (See soname_spec, versuffix, etc.)
>
> My hunch is that Peter's Debian patch would tweak GNU libtool not
> Subversion as Subversion doesn't have much control over SONAMEs. --
Are we talking at cross purposes on libtool? I'm proposing a patch
along the lines of Peter's patch, but under some --enable-foo flag and
possibly restricting APR to either 0.9.x or 1.2.x
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libsvn SONAMEs and APR
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/10/06, Philip Martin <ph...@codematters.co.uk> wrote:
> That doesn't really address my point. You probably know more than me,
> but as I understand it backporting full LFS to APR 0.9.x is simple
> except that it would be an unacceptable ABI change. Nothing you have
> written explains why you are happy to make the same ABI change in
> Subversion.
I don't view APR's ABI as part of Subversion's.
> > Even then, it's still very possible for LFS to be toggled on or off
> > even in the same 'library' version of APR/APR-util. Same goes for
> > threading, mmap, etc.
>
> I'm not really interested in corner cases, although I suspect that
> threading is handled by 'apr-config --cflags' and that mmap doesn't
> change the ABI.
As Garrett points out, those features changes the ABI by adding or
removing APR symbols.
> > Those apps *should* be linking with libtool. If not, it's very likely
> > that it may not compile or link appropriately.
>
> I disagree, libtool is optional.
If your app happens to work without libtool, good for you; but
removing libtool from the chain isn't something that we can support.
> Since nobody else appears to care about this problem I don't think
> it's sensible to change the default. How about a configure option to
> allow people to choose to get (or set?) a different SONAME? After all
> it is simple to support http-2.0/apr-0.9 and http-2.2/apr-1.2 in
> parallel so we should provide a standard way to do it even if it is
> not the default.
As I've said before, feel free to make it optional. However, you
might run head-first into libtool to get it to set non-numeric custom
SONAMEs - as it relies upon versions of the order X.Y.Z to set the
SONAME. (See soname_spec, versuffix, etc.)
My hunch is that Peter's Debian patch would tweak GNU libtool not
Subversion as Subversion doesn't have much control over SONAMEs. --
justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libsvn SONAMEs and APR
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 4/10/06, Philip Martin <ph...@codematters.co.uk> wrote:
> > Even then, it's still very possible for LFS to be toggled on or off
> > even in the same 'library' version of APR/APR-util. Same goes for
> > threading, mmap, etc.
>
> I'm not really interested in corner cases, although I suspect that
> threading is handled by 'apr-config --cflags' and that mmap doesn't
> change the ABI.
The problem Justin is referring to with threading and MMAP support are
that in APR they're both handled via preprocessor defines. You check
APR_HASH_THREADS (or something similar) and if it's defined you use
the threading functions. So if you drop in an APR 0.9.x library
compiled without threading on a box where subversion was compiled
against an APR 0.9.x library that had threading you'll get an svn that
refers to symbols that don't exist.
(I will stipulate that this is perhaps kind of silly, and it might
make more sense to have the functions return runtime errors instead of
not existing at all, but that's a separate point.)
The point is that the APR ABI can change in various ways even within
the same version number, and anything that doesn't take that into
acount will be almost as fragile as the system we've got now.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libsvn SONAMEs and APR
Posted by Philip Martin <ph...@codematters.co.uk>.
"Justin Erenkrantz" <ju...@erenkrantz.com> writes:
> On 4/7/06, Philip Martin <ph...@codematters.co.uk> wrote:
>> As I understand it, the reason APR 0.9 doesn't have LFS is that it
>> would be an ABI change. I find it odd that the same ABI change is
>> perfectly acceptable in Subversion.
>
> No. It was because APR 0.9.x has pooched LFS autoconf detection on
> Linux. LFS on Solaris and other platforms works fine in 0.9.x for
> some cases - with the proper incantations APR 0.9.x will do LFS too on
> Linux. APR 1.0.0 was the first release that has reliable autoconf LFS
> checks that work on Linux and everywhere else we care about out of the
> box.
That doesn't really address my point. You probably know more than me,
but as I understand it backporting full LFS to APR 0.9.x is simple
except that it would be an unacceptable ABI change. Nothing you have
written explains why you are happy to make the same ABI change in
Subversion.
> Even then, it's still very possible for LFS to be toggled on or off
> even in the same 'library' version of APR/APR-util. Same goes for
> threading, mmap, etc.
I'm not really interested in corner cases, although I suspect that
threading is handled by 'apr-config --cflags' and that mmap doesn't
change the ABI.
>> I don't understand why that matters, a third party object using the
>> Subversion ABI won't usually use Subversion's libtool. I accept that
>> if such an object is linked explicitly with libapr as well as libsvn
>> then changing the SONAME won't solve the problem, but for the objects
>> that are not linked explicitly against libapr the SONAME is a
>> solution.
>
> Those apps *should* be linking with libtool. If not, it's very likely
> that it may not compile or link appropriately.
I disagree, libtool is optional.
> At a minimum, it needs
> to use APR's compiler and link options or bad things may occur.
Agreed, but using libtool does not guarantee that the correct compiler
flags get used.
>> Is that sufficient reason to do nothing? Changing the SONAME might
>> not be a perfect solution, but it handles the common case of
>> http-2.0/apr-0.9 and http-2.2/apr-1.2.
>
> My opinion is that it won't really help.
Care to explain why not? Note, I said it helps with the common case
of http-2.0/apr-0.9 and http-2.2/apr-1.2. I'm not proposing that we
support every possible ABI resulting from every possible configuration
of APR, but I see no reason why we should not distinguish between the
two common default configurations.
> The only real way to do it
> is to enforce run-time APR version checks - like we do with BDB. We'd
> call apr_version/apu_version; but Subversion has never required any
> initialization calls - other than apr_initialize(). So, again, this
> is a problem that only downstream devs can deal with. -- justin
I don't think Subversion's run-time checks are any sort of magic
bullet. I'd hazard a guess that BDB configured to use non-default
mutexes would probably pass the Subversion checks and yet still fail
to open an existing environment. If your suggestion that mmap changes
the ABI is true I don't see how Subversion's run-time checks would
detect such a thing.
Since nobody else appears to care about this problem I don't think
it's sensible to change the default. How about a configure option to
allow people to choose to get (or set?) a different SONAME? After all
it is simple to support http-2.0/apr-0.9 and http-2.2/apr-1.2 in
parallel so we should provide a standard way to do it even if it is
not the default.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libsvn SONAMEs and APR
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/7/06, Philip Martin <ph...@codematters.co.uk> wrote:
> As I understand it, the reason APR 0.9 doesn't have LFS is that it
> would be an ABI change. I find it odd that the same ABI change is
> perfectly acceptable in Subversion.
No. It was because APR 0.9.x has pooched LFS autoconf detection on
Linux. LFS on Solaris and other platforms works fine in 0.9.x for
some cases - with the proper incantations APR 0.9.x will do LFS too on
Linux. APR 1.0.0 was the first release that has reliable autoconf LFS
checks that work on Linux and everywhere else we care about out of the
box.
Even then, it's still very possible for LFS to be toggled on or off
even in the same 'library' version of APR/APR-util. Same goes for
threading, mmap, etc.
> I don't understand why that matters, a third party object using the
> Subversion ABI won't usually use Subversion's libtool. I accept that
> if such an object is linked explicitly with libapr as well as libsvn
> then changing the SONAME won't solve the problem, but for the objects
> that are not linked explicitly against libapr the SONAME is a
> solution.
Those apps *should* be linking with libtool. If not, it's very likely
that it may not compile or link appropriately. At a minimum, it needs
to use APR's compiler and link options or bad things may occur.
> Is that sufficient reason to do nothing? Changing the SONAME might
> not be a perfect solution, but it handles the common case of
> http-2.0/apr-0.9 and http-2.2/apr-1.2.
My opinion is that it won't really help. The only real way to do it
is to enforce run-time APR version checks - like we do with BDB. We'd
call apr_version/apu_version; but Subversion has never required any
initialization calls - other than apr_initialize(). So, again, this
is a problem that only downstream devs can deal with. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libsvn SONAMEs and APR
Posted by Philip Martin <ph...@codematters.co.uk>.
"Justin Erenkrantz" <ju...@erenkrantz.com> writes:
> On 4/6/06, Philip Martin <ph...@codematters.co.uk> wrote:
>> How may people used APR 1.0+ before Apache 2.2? Debian packages a lot
>> of software and APR 1.0+ only became an issue when Apache 2.2 was
>> released.
>
> As I said back in 2004, apache.org was using APR 1.0. I haven't used
> Apache 2.0.x/APR 0.9 with Subversion in years. (APR 0.9 never handled
> LFS.)
As I understand it, the reason APR 0.9 doesn't have LFS is that it
would be an ABI change. I find it odd that the same ABI change is
perfectly acceptable in Subversion.
>> Really? I know there is a problem if the application explicitly links
>> to the other libraries, but if it avoids that and links just to libsvn
>> then I thought the other libraries were not part of the ABI.
>
> Debian purposely disables libtool's implicit linking features - but,
> in all releases we've ever shipped, our distributed GNU libtool's will
> end up implicitly linking to all dependent libraries.
I don't understand why that matters, a third party object using the
Subversion ABI won't usually use Subversion's libtool. I accept that
if such an object is linked explicitly with libapr as well as libsvn
then changing the SONAME won't solve the problem, but for the objects
that are not linked explicitly against libapr the SONAME is a
solution.
>> APR is
>> different because it's types appear explicitly in the Subversion API.
>
> APR and APR-util at a minimum must be there - other libraries might
> need to be encoded depending upon on the platform's inter-library
> linkage rules.
>
> With APR's binary compatibility rules now in effect - a binary linking
> against SVN compiled against APR 1.2 should work with APR 1.3 but not
> 1.1. Note that there's no requirement for APR and APR-util to be at
> the same version. I'm not quite sure that SONAME is expressive enough
> to honor these rules. I have a feeling that any SONAME solution will
> end up either working only with 1.2 or with all 1.x series. Neither
> of which is correct (one is too liberal, one is too restrictive).
Is that sufficient reason to do nothing? Changing the SONAME might
not be a perfect solution, but it handles the common case of
http-2.0/apr-0.9 and http-2.2/apr-1.2.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libsvn SONAMEs and APR
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/6/06, Philip Martin <ph...@codematters.co.uk> wrote:
> How may people used APR 1.0+ before Apache 2.2? Debian packages a lot
> of software and APR 1.0+ only became an issue when Apache 2.2 was
> released.
As I said back in 2004, apache.org was using APR 1.0. I haven't used
Apache 2.0.x/APR 0.9 with Subversion in years. (APR 0.9 never handled
LFS.)
> Really? I know there is a problem if the application explicitly links
> to the other libraries, but if it avoids that and links just to libsvn
> then I thought the other libraries were not part of the ABI.
Debian purposely disables libtool's implicit linking features - but,
in all releases we've ever shipped, our distributed GNU libtool's will
end up implicitly linking to all dependent libraries.
> APR is
> different because it's types appear explicitly in the Subversion API.
APR and APR-util at a minimum must be there - other libraries might
need to be encoded depending upon on the platform's inter-library
linkage rules.
With APR's binary compatibility rules now in effect - a binary linking
against SVN compiled against APR 1.2 should work with APR 1.3 but not
1.1. Note that there's no requirement for APR and APR-util to be at
the same version. I'm not quite sure that SONAME is expressive enough
to honor these rules. I have a feeling that any SONAME solution will
end up either working only with 1.2 or with all 1.x series. Neither
of which is correct (one is too liberal, one is too restrictive).
Do *any* other projects encode their dependencies in their SONAMEs? I
sort of doubt it. AFAICT, the GNOME packages don't encode the SONAME
of glib in there; but libgnome can work off several different versions
of glib. If you change a glib structure, you'd likely alter some of
the interfaces somewhere in GNOME's higher-level libraries. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libsvn SONAMEs and APR
Posted by Philip Martin <ph...@codematters.co.uk>.
"Justin Erenkrantz" <ju...@erenkrantz.com> writes:
> The issue has nothing to do with Apache HTTP Server 2.2 - Debian's
> problem is only about APR 1.0+. Hence, this topic inevitably arose
> when APR 1.0 was released back in 2004. I definitely don't view it as
> an inadvertant bug.
How may people used APR 1.0+ before Apache 2.2? Debian packages a lot
of software and APR 1.0+ only became an issue when Apache 2.2 was
released.
>> If you are totally opposed to changing the current default SONAME, how
>> about a configure option to do it?
>
> Remember that a simple soname change isn't enough. It must embed
> every library dependency Subversion imports in order to be accurate.
> You'll have to come up with an encoding scheme to describe all of the
> library versions in that one string. -- justin
Really? I know there is a problem if the application explicitly links
to the other libraries, but if it avoids that and links just to libsvn
then I thought the other libraries were not part of the ABI. APR is
different because it's types appear explicitly in the Subversion API.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libsvn SONAMEs and APR
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/6/06, Philip Martin <ph...@codematters.co.uk> wrote:
> "Justin Erenkrantz" <ju...@erenkrantz.com> writes:
>
> > On 4/5/06, Philip Martin <ph...@codematters.co.uk> wrote:
> >> I don't recall any discussion about the ABI change implied by
> >> releasing Subversion with support for APR 1.2. Was there any
> >> discussion, did we make a conscious decision to break the ABI without
> >> changing the soname? If we simply didn't consider it then I think it
> >> was a mistake and we should fix it.
> >
> > http://svn.haxx.se/dev/archive-2004-07/0030.shtml
>
> That's some time before Apache 2.2 was released. Effectively the
> discussion happened at a completely separate time to the release of an
> Apache that triggered the ABI change. Perhaps I should have paid more
> attention, but this was an inadvertant ABI change as far as I'm
> concerned. I still think it was a mistake, and I think we should fix
> it, just like any other inadvertant bug.
The issue has nothing to do with Apache HTTP Server 2.2 - Debian's
problem is only about APR 1.0+. Hence, this topic inevitably arose
when APR 1.0 was released back in 2004. I definitely don't view it as
an inadvertant bug.
> If you are totally opposed to changing the current default SONAME, how
> about a configure option to do it?
Remember that a simple soname change isn't enough. It must embed
every library dependency Subversion imports in order to be accurate.
You'll have to come up with an encoding scheme to describe all of the
library versions in that one string. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libsvn SONAMEs and APR
Posted by Philip Martin <ph...@codematters.co.uk>.
"Justin Erenkrantz" <ju...@erenkrantz.com> writes:
> On 4/5/06, Philip Martin <ph...@codematters.co.uk> wrote:
>> I don't recall any discussion about the ABI change implied by
>> releasing Subversion with support for APR 1.2. Was there any
>> discussion, did we make a conscious decision to break the ABI without
>> changing the soname? If we simply didn't consider it then I think it
>> was a mistake and we should fix it.
>
> http://svn.haxx.se/dev/archive-2004-07/0030.shtml
That's some time before Apache 2.2 was released. Effectively the
discussion happened at a completely separate time to the release of an
Apache that triggered the ABI change. Perhaps I should have paid more
attention, but this was an inadvertant ABI change as far as I'm
concerned. I still think it was a mistake, and I think we should fix
it, just like any other inadvertant bug.
If you are totally opposed to changing the current default SONAME, how
about a configure option to do it?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libsvn SONAMEs and APR
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/5/06, Philip Martin <ph...@codematters.co.uk> wrote:
> I don't recall any discussion about the ABI change implied by
> releasing Subversion with support for APR 1.2. Was there any
> discussion, did we make a conscious decision to break the ABI without
> changing the soname? If we simply didn't consider it then I think it
> was a mistake and we should fix it.
http://svn.haxx.se/dev/archive-2004-07/0030.shtml
=) -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libsvn SONAMEs and APR
Posted by Philip Martin <ph...@codematters.co.uk>.
"Justin Erenkrantz" <ju...@erenkrantz.com> writes:
> On 3/31/06, Michael Sweet <mi...@easysw.com> wrote:
>> Given that Subversion is so closely tied to APR, it would make sense
>> to offer an alternate DSO version number when compiled against APR
>> 1.x. Assuming that APR doesn't make any more disruptive changes
>> like the 0.x to 1.x transition, that'll just mean that Subversion 2
>> will have a DSO major version of 3 (or whatever) instead of 1.
>> Alternately, you could use numbered suffix on the library name, e.g.
>> "libsvn_client2".
>
> -1 as that needlessly breaks people who are already happy with APR 1.x
> and SVN. -- justin
I don't recall any discussion about the ABI change implied by
releasing Subversion with support for APR 1.2. Was there any
discussion, did we make a conscious decision to break the ABI without
changing the soname? If we simply didn't consider it then I think it
was a mistake and we should fix it.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libsvn SONAMEs and APR
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 3/31/06, Michael Sweet <mi...@easysw.com> wrote:
> Given that Subversion is so closely tied to APR, it would make sense
> to offer an alternate DSO version number when compiled against APR
> 1.x. Assuming that APR doesn't make any more disruptive changes
> like the 0.x to 1.x transition, that'll just mean that Subversion 2
> will have a DSO major version of 3 (or whatever) instead of 1.
> Alternately, you could use numbered suffix on the library name, e.g.
> "libsvn_client2".
-1 as that needlessly breaks people who are already happy with APR 1.x
and SVN. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libsvn SONAMEs and APR
Posted by Michael Sweet <mi...@easysw.com>.
Peter Samuelson wrote:
> [Peter Samuelson]
>> Would you consider accepting a patch to make SONAME handling explicit
>> in the Makefile, and also make it sensitive to apr version? Would
>> you consider this for 1.3.1 or 1.3.2?
>
> Ping. I think maxb and ghudson agree with me, jerenkrantz and joe
> disagree. Are there further questions I can answer, anything else I
> can do so that you can make a decision on this?
>
> It has been noted that this is somewhat time-sensitive - apache 2.2 is
> on the rise, and every user and vendor who upgrades to it and
> recompiles subversion will need to decide how to handle the ABI change.
> In my opinion, the only sane options for Subversion are to make this
> change (or an equivalent solution) as soon as possible (by 1.3.2?), or
> refuse to support Apache 2.2 until Subversion 2.0.
>
> * http://svn.haxx.se/dev/archive-2006-03/0522.shtml
> My patch. It illustrates two approaches to detect the ABI - please
> pick one. (:
>
> * http://svn.haxx.se/dev/archive-2006-03/0503.shtml
> I attempt to explain the need for this. Justin, did you have any
> further questions?
>
> * http://svn.haxx.se/dev/archive-2006-03/0583.shtml
> Joe Orton agrees that delaying this decision hurts users. He _seems_
> to be suggesting that apache 2.2 not be supported at all until
> Subversion 2.0, but I hate to put words in someone's mouth - Joe, can
> you clarify what position you think Subversion should take on this?
>
> If other developers could read the above messages and weigh in, that
> would be great. I'm happy to answer any further questions.
Given that Subversion is so closely tied to APR, it would make sense
to offer an alternate DSO version number when compiled against APR
1.x. Assuming that APR doesn't make any more disruptive changes
like the 0.x to 1.x transition, that'll just mean that Subversion 2
will have a DSO major version of 3 (or whatever) instead of 1.
Alternately, you could use numbered suffix on the library name, e.g.
"libsvn_client2".
Support for DSO versioning will also allow for proper identification
of ABI revisions, such that an application compiled against the 1.3
libraries will not run with the 1.2 libraries.
The alternative is for applications linked against Subversion to
start behaving erratically after an update of Subversion, APR, and/or
Apache...
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Publishing Software http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libsvn SONAMEs and APR
Posted by Peter Samuelson <pe...@p12n.org>.
[Philip Martin]
> If we don't change the soname:
> Case [3]:
> - foo linked against subversion/apr-0.9
> - foo has libsvn and libapr in the NEEDED section
> - system upgrades to new subversion/apr-1.x keeping apr-0.9
I'm particularly interested in case 5:
Case 5:
- foo linked against subversion/apr-0.9
- foo has libsvn (and possibly libapr, doesn't really matter) in the
NEEDED section
- system upgrades to new subversion/apr-1.x keeping apr-0.9
_and subversion/apr-0.9_
- foo continues to work normally
This is what I will do on Debian, and having both svn libs installed
simultaneously is only possible if the soname is changed.
> I don't object to a configure switch to keep the old SONAME, either
> one specific to this case --soname-use-apr0 or a generic
> --soname-version=0.
Interesting approach - I happen to think it's unnecessary, but if it
makes people happy....
Peter
Re: [PATCH] libsvn SONAMEs and APR
Posted by Philip Martin <ph...@codematters.co.uk>.
Peter Samuelson <pe...@p12n.org> writes:
> If other developers could read the above messages and weigh in, that
> would be great. I'm happy to answer any further questions.
Consider some program/library/module foo that uses Subversion but
doesn't get upgraded when the system gets upgraded. Now foo might be
explicitly linked to both libsvn and libapr, or it may be linked to
libsvn only (Subversion itself has examples of both).
If we don't change the soname:
Case 1:
- foo linked against subversion/apr-0.9
- foo has libsvn in the NEEDED section
- system upgrades to new subversion/apr-1.x
- foo runs and fails due to ABI incompatibility
Case 2:
- foo linked against subversion/apr-0.9
- foo has libsvn and libapr in the NEEDED section
- system upgrades to new subversion/apr-1.x removing apr-0.9
- foo fails to start because apr-0.9 is missing
Case 4:
- foo linked against subversion/apr-0.9
- foo has libsvn and libapr in the NEEDED section
- system upgrades to new subversion/apr-1.x keeping apr-0.9
- foo runs and fails due to ABI incompatibility
Case 4:
- foo linked against subversion/apr-1.x using old SONAME
- system upgrades to new subversion/apr-1.x
- foo runs and works
If we change the soname:
Case 1:
- foo fails to start
Case 2:
- foo fails to start
Case 3:
- foo fails to start
Case 4:
- foo fails to start because the old SONAME is missing, although it
would work if it could be persuaded to run.
Failing to start is probably better than failing at runtime due to ABI
changes, so I'm in favour of changing the SONAME. I don't object to a
configure switch to keep the old SONAME, either one specific to this
case --soname-use-apr0 or a generic --soname-version=0.
For the problem case 4 where a program that would work fails to run,
it might be possible for a distribution get around this by providing
dummy libsvn_xxx-1.so.0 libraries with the old SONAME that depend on
the new SONAME. Such libraries should only be used when upgrading
from subversion/apr-1.x with the old SONAME, it would be a bad idea to
install them if upgrading from subversion/apr-0.9.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] libsvn SONAMEs and APR
Posted by Peter Samuelson <pe...@p12n.org>.
[Peter Samuelson]
> Would you consider accepting a patch to make SONAME handling explicit
> in the Makefile, and also make it sensitive to apr version? Would
> you consider this for 1.3.1 or 1.3.2?
Ping. I think maxb and ghudson agree with me, jerenkrantz and joe
disagree. Are there further questions I can answer, anything else I
can do so that you can make a decision on this?
It has been noted that this is somewhat time-sensitive - apache 2.2 is
on the rise, and every user and vendor who upgrades to it and
recompiles subversion will need to decide how to handle the ABI change.
In my opinion, the only sane options for Subversion are to make this
change (or an equivalent solution) as soon as possible (by 1.3.2?), or
refuse to support Apache 2.2 until Subversion 2.0.
* http://svn.haxx.se/dev/archive-2006-03/0522.shtml
My patch. It illustrates two approaches to detect the ABI - please
pick one. (:
* http://svn.haxx.se/dev/archive-2006-03/0503.shtml
I attempt to explain the need for this. Justin, did you have any
further questions?
* http://svn.haxx.se/dev/archive-2006-03/0583.shtml
Joe Orton agrees that delaying this decision hurts users. He _seems_
to be suggesting that apache 2.2 not be supported at all until
Subversion 2.0, but I hate to put words in someone's mouth - Joe, can
you clarify what position you think Subversion should take on this?
If other developers could read the above messages and weigh in, that
would be great. I'm happy to answer any further questions.
Peter
[PATCH] libsvn SONAMEs and APR
Posted by Peter Samuelson <pe...@p12n.org>.
[Peter Samuelson]
> Would you consider accepting a patch to make SONAME handling explicit
> in the Makefile, and also make it sensitive to apr version? Would
> you consider this for 1.3.1 or 1.3.2? I'll try to prepare and test a
> patch in the next day or two.
Here's a patch. It seems to work on my system - but I'll keep testing
other cases to make sure.
There are two approaches to autodetecting the ABI in question - I left
them both in but commented one out - so this patch is more for
illustration than for applying directly.
Peter
[[[
Pass library version information into libtool, taking the ABI of
apr_off_t into account.
Patch by: Peter Samuelson <pe...@p12n.org>
* build/ac-macros/apr.m4 (SVN_LIB_APR):
Test for APR_HAS_LARGE_FILES, and export SVN_LT_SOVERSION, as
libtool command line options to set the library version.
* Makefile.in:
New macro LT_SOVERSION for the above; use it in the $(LINK) macro.
]]]
Index: Makefile.in
===================================================================
--- Makefile.in (revisione 18785)
+++ Makefile.in (copia locale)
@@ -94,6 +94,7 @@
LTFLAGS = @SVN_LT_CCTAG@ --silent
LTCXXFLAGS = @SVN_LT_CXXTAG@ --silent
LT_LDFLAGS = @LT_LDFLAGS@
+LT_SOVERSION = @SVN_LT_SOVERSION@
LT_NO_UNDEFINED = @LT_NO_UNDEFINED@
LT_CXX_LIBADD = @LT_CXX_LIBADD@
@@ -156,7 +157,7 @@
COMPILE_JAVAHL_JAVAC = $(JAVAC) $(JAVAC_FLAGS)
COMPILE_JAVAHL_JAVAH = $(JAVAH)
-LINK = $(LIBTOOL) $(LTFLAGS) --mode=link $(CC) $(LT_LDFLAGS) $(CFLAGS) $(LDFLAGS) -rpath $(libdir)
+LINK = $(LIBTOOL) $(LTFLAGS) --mode=link $(CC) $(LT_LDFLAGS) $(LT_SOVERSION) $(CFLAGS) $(LDFLAGS) -rpath $(libdir)
# special link rule for mod_dav_svn
LINK_APACHE_MOD = $(LIBTOOL) $(LTFLAGS) --mode=link $(CC) $(LT_LDFLAGS) $(CFLAGS) $(LDFLAGS) -rpath $(APACHE_LIBEXECDIR) -avoid-version -module $(APACHE_LDFLAGS)
Index: build/ac-macros/apr.m4
===================================================================
--- build/ac-macros/apr.m4 (revisione 18785)
+++ build/ac-macros/apr.m4 (copia locale)
@@ -85,11 +85,31 @@
AC_MSG_ERROR([apr-config --shlib-path-var failed])
fi
+ dnl Determine whether or not we will be using the 64-bit apr_off_t ABI.
+ dnl This necessarily changes the SONAME of libsvn_*.
+ dnl if test `expr $apr_version : 0` -ne 0; then
+ dnl SVN_LT_SOVERSION="-version-info 0"
+ dnl else
+ dnl SVN_LT_SOVERSION="-version-info 1"
+ dnl fi
+ oldcppflags=$CPPFLAGS
+ CPPFLAGS="$CPPFLAGS $SVN_APR_INCLUDES"
+ AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
+#include <apr.h>
+#if APR_HAS_LARGE_FILES
+# error Large file ABI required
+#endif
+ ]])], [apr_lfs_abi=0], [apr_lfs_abi=1])
+ CPPFLAGS=$oldcppflags
+
+SVN_LT_SOVERSION="-version-info $apr_lfs_abi"
+
AC_SUBST(SVN_APR_PREFIX)
AC_SUBST(SVN_APR_INCLUDES)
AC_SUBST(SVN_APR_LIBS)
AC_SUBST(SVN_APR_EXPORT_LIBS)
AC_SUBST(SVN_APR_SHLIB_PATH_VAR)
+ AC_SUBST(SVN_LT_SOVERSION)
])
dnl SVN_DOWNLOAD_APR()
Re: libsvn SONAMEs and APR
Posted by Joe Orton <jo...@manyfish.co.uk>.
On Sun, Mar 12, 2006 at 01:32:51PM -0500, Greg Hudson wrote:
> On Sun, 2006-03-12 at 18:21 +0000, Joe Orton wrote:
> > But doing this now in a 1.x release *by default* would be very
> > unpleasant; having a special "make my sonames Debian ABI policy
> > compatible" configure option seems somewhat perverse.
>
> So far, I believe we have always recommended using Subversion in concert
> with httpd 2.0 (if using mod_dav_svn) and apr 0.x. This change would
> allow us to recommend using Subversion in concert with httpd 2.2 and apr
> 1.x as a second option.
>
> Some distributions already started building apr with httpd 2.2 and apr
> 1.x, without having changed the Subversion soname (causing applications
> linked normally against the Subversion libraries to potentially break
> unpredictably, and applications linked with libtool against the
> Subversion libraries to fail to run). If we change the default soname
> for apr 1.x linkage, such distributions will be faced with a dilemma,
> but I'm not sure that's our fault.
This affects any user of APR 1.x with Subversion, not just
distributions. I think it would be an entirely reasonable position to
renege on the commitment to soname stability in this case if APR 1.0 had
been released just now rather than 18 months ago, if the Subversion
configure script was not explicitly written to support builds against
APR 1.x, and if support for APR 1.x had not been advertised in the
Subversion 1.1.2 CHANGES entry.
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: libsvn SONAMEs and APR
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sun, 2006-03-12 at 18:21 +0000, Joe Orton wrote:
> And also the
> APR-util major version if you want to be pedantic, per previous mail.
I wasn't convinced; APR_MD5_DIGESTSIZE is a constant "fixed by nature",
as it were, and I don't think we have to worry about it changing.
> But doing this now in a 1.x release *by default* would be very
> unpleasant; having a special "make my sonames Debian ABI policy
> compatible" configure option seems somewhat perverse.
So far, I believe we have always recommended using Subversion in concert
with httpd 2.0 (if using mod_dav_svn) and apr 0.x. This change would
allow us to recommend using Subversion in concert with httpd 2.2 and apr
1.x as a second option.
Some distributions already started building apr with httpd 2.2 and apr
1.x, without having changed the Subversion soname (causing applications
linked normally against the Subversion libraries to potentially break
unpredictably, and applications linked with libtool against the
Subversion libraries to fail to run). If we change the default soname
for apr 1.x linkage, such distributions will be faced with a dilemma,
but I'm not sure that's our fault. And the dilemma doesn't seem *too*
bad; either you override our default and become binary-incompatible with
Debian, or you change the soname "gratuitously" and either deal with
coexistence or force a rebuild of Subversion-using applications,
something those distributions have already decided is okay.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: libsvn SONAMEs and APR
Posted by Joe Orton <jo...@manyfish.co.uk>.
On Sun, Mar 12, 2006 at 12:09:04PM -0500, Greg Hudson wrote:
> On Sun, 2006-03-12 at 16:04 +0000, Joe Orton wrote:
> > We could support that in Fedora, and would if there were a substantial
> > number of third-party APR-based apps that people used; but there aren't
> > many such apps, so we don't. But this is just distro policy and is not
> > really relevant.
>
> It seems relevant to me.
>
> Debian policy: when the ABI of any library changes, make it possible for
> both ABIs to coexist, so that previously-built applications continue to
> work.
Peter was talking about apr-0 and apr-1 coexisting there, to which this
*is* irrelevant but if the real issue is making the differently-linked
*subversion* packages coexist, I see the relevance. I guess it vaguely
makes sense to do this soname munging upstream for that reason; but
certainly it must be done based on the APR major version not the
apr_off_t size, which is merely one aspect of the APR ABI. And also the
APR-util major version if you want to be pedantic, per previous mail.
But doing this now in a 1.x release *by default* would be very
unpleasant; having a special "make my sonames Debian ABI policy
compatible" configure option seems somewhat perverse.
Regards,
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: libsvn SONAMEs and APR
Posted by Joe Orton <jo...@manyfish.co.uk>.
On Sun, Mar 12, 2006 at 12:09:04PM -0500, Greg Hudson wrote:
> On Sun, 2006-03-12 at 16:04 +0000, Joe Orton wrote:
> >> If an app links to apr-0 but libsvn uses apr-1, it's not like this
> >> will catch the problem, unless you remove apr-0 from your system so
> >> that the app will fail to start.
>
> > That's a different problem, and one which cannot be solved by the
> > runtime linker; merely changing the SVN sonames doesn't help.
>
> Actually, there's something called symbol versioning which can solve
> this problem, but I don't believe it's portable enough for apps to make
> use of. I know Debian's library policy at least used to involve symbol
> versioning, but I don't understand the details.
I meant to mention: symbol versioning does not really solve that
problem; the app and libsvn need to interchange pointers to opaque APR
data structures. Symbol versioning could allow you to safely use
distinct APR function implementations in each, but you're still doomed
when the two copies of APR need to interoperate.
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: libsvn SONAMEs and APR
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sun, 2006-03-12 at 16:04 +0000, Joe Orton wrote:
> We could support that in Fedora, and would if there were a substantial
> number of third-party APR-based apps that people used; but there aren't
> many such apps, so we don't. But this is just distro policy and is not
> really relevant.
It seems relevant to me.
Debian policy: when the ABI of any library changes, make it possible for
both ABIs to coexist, so that previously-built applications continue to
work.
Fedora policy: when the ABI of a library changes, unless it is widely
used, force a rebuild of everything built against that library.
Peter is proposing a change to make the Debian policy work for
Subversion in light of our trickle-down dependency on the APR ABI. You
are proposing an alternative "solution" which only works for the Fedora
policy.
>> If an app links to apr-0 but libsvn uses apr-1, it's not like this
>> will catch the problem, unless you remove apr-0 from your system so
>> that the app will fail to start.
> That's a different problem, and one which cannot be solved by the
> runtime linker; merely changing the SVN sonames doesn't help.
Actually, there's something called symbol versioning which can solve
this problem, but I don't believe it's portable enough for apps to make
use of. I know Debian's library policy at least used to involve symbol
versioning, but I don't understand the details.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: libsvn SONAMEs and APR
Posted by Joe Orton <jo...@manyfish.co.uk>.
On Sat, Mar 11, 2006 at 04:27:59PM -0600, Peter Samuelson wrote:
> [Joe Orton]
> > I think the correct answer is that any application which links against
> > libsvn* must also link directly against (i.e. have a DT_NEEDED for)
> > libapr. The Subversion API does not isolate applications from APR ABI
> > changes, so this doesn't seem unreasonable - <app which uses SVN> has a
> > direct dependency on the APR ABI version; so app needs a DT_NEEDED for
> > the libapr SONAME.
>
> OK, so can you tell me what happens on Fedora if I do the following?
>
> 1) Compile an application using libsvn-linked-to-apr-0
> 2) Upgrade subversion to a build that uses apr-1
> 3) Try to run the application
>
> Debian users expect this to Just Work, and part of my job as a library
> maintainer is to accommodate use cases like this one.
You cannot expect the above to work at all - you can only expect it to
work when the application is rebuilt against apr-1. The application has
a dependency on both the SVN ABI and also on the APR ABI.
> 2) The application will fail to run because apr-0 is no longer
> installed at all.
Correct if the application does have a DT_NEEDED for the apr-0.x soname,
and the apr-0.x package is removed when upgrading to apr-1.x (as would
normally happen).
> This assumes apr-0 and apr-1 cannot coexist on Fedora. If apr-0 and
> apr-1 can't coexist, it also implies that moving from one to the other
> requires rebuilding *all* apps (packaged or local) that depend on it,
> all at once. Such a forced transition is considered very bad form on
> Debian.
We could support that in Fedora, and would if there were a substantial
number of third-party APR-based apps that people used; but there aren't
many such apps, so we don't. But this is just distro policy and is not
really relevant.
> 3) The application will run with a new libsvn-with-apr-1 and thus will
> indirectly load both apr-0 and apr-1 when starting up.
Correct if the application has the DT_NEEDED for apr and the user
decides to have both apr-0.x and apr-1.x packages installed. Even if
the SVN sonames are munged the user will be able to shoot themselves in
the foot in exactly this manner.
> > You'd also have to embed the apr-util ABI version in the SVN sonames;
> > and the apr-util ABI version must also probably embed the OpenLDAP
> > ABI version because of the apr_ldap.h mess; etc etc.
>
> The aprutil version bump matches the apr version bump, so I see no need
> to embed that separately. I know they are separate libraries, but it
> seems reasonable to treat them as a unit, until such time as I have a
> need or desire to upgrade their uses independently.
The APR-util ABI could be changed without changing the APR ABI, there's
no enforced lock-step there. svn_base64_from_md5 exposes a dependency
on APR_MD5_DIGESTSIZE, which is defined by the APR-util ABI. This would
be simple to avoid, of course.
> > Yet there's absolutely no practical gain to adding all this
> > complexity: when you want to update to an APR package which has a new
> > ABI, you still have to update exactly the same set of packages.
>
> Only if you assume that all library ABI changes propagate all the way
> down the chain to affect user apps.
That's not logical; I'm not talking about the general case, I'm talking
about this specific case. It is true for Subversion and APR; if you
rebuild Subversion against a version of APR with a different ABI, you
must to do so for all apps linked against Subversion too.
You seem to imply this is not the case. It's true not only because of
the exposed types like apr_off_t, but also because SVN-based apps are
required to use APR interfaces directly, from apr_initialize(), to
pools, to apr_hash_* and so on. The APR_OS_START_USERERR definition is
another place where SVN consumers would be affected by an APR ABI
change, since it would change all svn error codes too.
> > The Debian libtool patch which Justin mentions is certainly related
> > to this: libtool will by default ensure that the libapr* dependency
> > is leaked upwards to any application which links against libsvn*.la.
>
> I fail to see how that helps anything.
It ensures that there is a dependency between application and the APR
ABI version, as would munging the SVN soname as you propose.
> If an app links to apr-0 but libsvn uses apr-1, it's not like this
> will catch the problem, unless you remove apr-0 from your system so
> that the app will fail to start.
That's a different problem, and one which cannot be solved by the
runtime linker; merely changing the SVN sonames doesn't help.
Regards,
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: libsvn SONAMEs and APR
Posted by Peter Samuelson <pe...@p12n.org>.
[Joe Orton]
> I think the correct answer is that any application which links against
> libsvn* must also link directly against (i.e. have a DT_NEEDED for)
> libapr. The Subversion API does not isolate applications from APR ABI
> changes, so this doesn't seem unreasonable - <app which uses SVN> has a
> direct dependency on the APR ABI version; so app needs a DT_NEEDED for
> the libapr SONAME.
OK, so can you tell me what happens on Fedora if I do the following?
1) Compile an application using libsvn-linked-to-apr-0
2) Upgrade subversion to a build that uses apr-1
3) Try to run the application
Debian users expect this to Just Work, and part of my job as a library
maintainer is to accommodate use cases like this one. Manipulating
SONAMEs is a large part of this. Library maintenance is harder than
regular app maintenance precisely because we have to think about these
things.
Here are the possibilities that I can think of:
1) The application will find an old libsvn and apr-0 at runtime, and
will work normally. This requires that libsvn-with-apr-0 and
libsvn-with-apr-1 coexist on the system, and that the runtime linker be
able to tell them apart. To do this, the runtime linker needs to see
two different SONAMEs.
2) The application will fail to run because apr-0 is no longer
installed at all. This assumes apr-0 and apr-1 cannot coexist on
Fedora. If apr-0 and apr-1 can't coexist, it also implies that moving
from one to the other requires rebuilding *all* apps (packaged or
local) that depend on it, all at once. Such a forced transition is
considered very bad form on Debian.
3) The application will run with a new libsvn-with-apr-1 and thus will
indirectly load both apr-0 and apr-1 when starting up. It will later
crash or misbehave, either because of symbol confusion between the two
versions of apr, or because of an ABI mismatch with libsvn (all uses of
apr_off_t). If you are very lucky and the app doesn't use apr_off_t
anywhere, it *may* work normally.
Those outcomes are in decreasing order of preference. 2) is better
than 3) because at least the problem can be unambiguously determined,
but Debian developers and users would be quite unhappy with either.
> Making every library SONAME be a product of the exported ABI version
> of every dependant library would get quickly unmanageable.
Only dependent libraries that affect the ABI of your own library. Many
such changes don't affect you. This, by the way, is why Debian libtool
tries not to force an application to link the whole chain of dependent
libraries directly. Doing so would make library transitions much less
agile, because of artificial version dependencies that the app should
not have to directly care about.
> You'd also have to embed the apr-util ABI version in the SVN sonames;
> and the apr-util ABI version must also probably embed the OpenLDAP
> ABI version because of the apr_ldap.h mess; etc etc.
The aprutil version bump matches the apr version bump, so I see no need
to embed that separately. I know they are separate libraries, but it
seems reasonable to treat them as a unit, until such time as I have a
need or desire to upgrade their uses independently.
As for aprutil being affected by libldap, it is the responsibility of
the Debian aprutil maintainers to ensure the same thing I'm trying to
ensure. If they have to force a SONAME bump in order to incorporate
some new LDAP client library, they will do so. Then I have the option
of following them, or sticking with the old library version. But since
libsvn does not use LDAP, I can't imagine why the LDAP interface change
would trickle down into the libsvn ABI. Thus *my* users would still
not be affected (unless they also use LDAP independently of using
libsvn, of course.)
> Yet there's absolutely no practical gain to adding all this
> complexity: when you want to update to an APR package which has a new
> ABI, you still have to update exactly the same set of packages.
Only if you assume that all library ABI changes propagate all the way
down the chain to affect user apps. In many if not most cases, this is
not true. As an example, apps that use libsvn_fs have no need to link
directly to libdb4.x, and as far as I can tell, no need to care which
version of Berkeley DB was used to build Subversion. The
libsvn_fs_base ABI shields the app from having to know. So rebuilding
Subversion against a newer BDB may require migrating repositories, but
will not require recompiling applications.
By trimming dependencies down to what an application uses _directly_,
we avoid lots of cases of forcing users to recompile (or forcing
maintainers to upload recompiled packages) needlessly.
> The Debian libtool patch which Justin mentions is certainly related
> to this: libtool will by default ensure that the libapr* dependency
> is leaked upwards to any application which links against libsvn*.la.
I fail to see how that helps anything. If an app links to apr-0 but
libsvn uses apr-1, it's not like this will catch the problem, unless
you remove apr-0 from your system so that the app will fail to start.
Peter
Re: libsvn SONAMEs and APR
Posted by Joe Orton <jo...@manyfish.co.uk>.
On Fri, Mar 10, 2006 at 05:15:53PM -0600, Peter Samuelson wrote:
> Debian subversion builds will soon be moving to apr 1.2, in lockstep
> with Debian apache2. (Because of mod_dav_svn, we have no choice.) We
> know this will occasion an ABI change to libsvn, so this requires
> changing the embedded SONAMEs of the libraries. (See footnote for a
> quick introduction to SONAMEs.)
>
> I note that subversion currently has no particular notion of library
> versions - which I suppose is OK since you're committed to never
> changing the ABI incompatibly - but it's probably better to be
> explicit. Anyway, libtool generates its own default SONAMEs:
>
> $ objdump -p /usr/lib/libsvn_client-1.so.0 | grep SONAME
> SONAME libsvn_client-1.so.0
>
> I'll need to adjust this in some way, to denote the ABI change caused
> by the new apr. I'll do it myself on Debian if I have to, but I'd
> prefer to avoid this, as it'll create a gratuitous incompatibility
> between Linux distributions. E.g., if Fedora also decides to build
> subversion 1.3 with apr 1.2, our binaries won't work on Fedora, or vice
> versa, unless they happen to make the *same* change to the SONAME
> strings that I do.
I considered this issue when I updated the Fedora packaging for APR 1.x.
I think the correct answer is that any application which links against
libsvn* must also link directly against (i.e. have a DT_NEEDED for)
libapr. The Subversion API does not isolate applications from APR ABI
changes, so this doesn't seem unreasonable - <app which uses SVN> has a
direct dependency on the APR ABI version; so app needs a DT_NEEDED for
the libapr SONAME.
Making every library SONAME be a product of the exported ABI version of
every dependant library would get quickly unmanageable. You'd also have
to embed the apr-util ABI version in the SVN sonames; and the apr-util
ABI version must also probably embed the OpenLDAP ABI version because of
the apr_ldap.h mess; etc etc. Yet there's absolutely no practical gain
to adding all this complexity: when you want to update to an APR package
which has a new ABI, you still have to update exactly the same set of
packages.
The Debian libtool patch which Justin mentions is certainly related to
this: libtool will by default ensure that the libapr* dependency is
leaked upwards to any application which links against libsvn*.la. That
is the desirable behaviour in this case; and it's exactly why this
behaviour should not be changed globally, but needs to be decided
per-library and per-dependency.
Regards,
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: libsvn SONAMEs and APR
Posted by Max Bowsher <ma...@ukf.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Peter Samuelson wrote:
> Debian subversion builds will soon be moving to apr 1.2, in lockstep
> with Debian apache2. (Because of mod_dav_svn, we have no choice.) We
> know this will occasion an ABI change to libsvn, so this requires
> changing the embedded SONAMEs of the libraries.
Yes.
> I note that subversion currently has no particular notion of library
> versions - which I suppose is OK since you're committed to never
> changing the ABI incompatibly - but it's probably better to be
> explicit.
Uhh, yes we do: that notion is "1" - i.e. our major version number.
Sure, it's not a particularly *complex* notion, but it is there.
> Anyway, libtool generates its own default SONAMEs:
>
> $ objdump -p /usr/lib/libsvn_client-1.so.0 | grep SONAME
> SONAME libsvn_client-1.so.0
>
> I'll need to adjust this in some way, to denote the ABI change caused
> by the new apr. I'll do it myself on Debian if I have to, but I'd
> prefer to avoid this, as it'll create a gratuitous incompatibility
> between Linux distributions. E.g., if Fedora also decides to build
> subversion 1.3 with apr 1.2, our binaries won't work on Fedora, or vice
> versa, unless they happen to make the *same* change to the SONAME
> strings that I do.
>
> Would you consider accepting a patch to make SONAME handling explicit
> in the Makefile, and also make it sensitive to apr version? Would you
> consider this for 1.3.1 or 1.3.2? I'll try to prepare and test a patch
> in the next day or two.
Tentatively, yes. You need to tell us what scheme for SONAMEs and what
libtool options are involved to get a clearer answer.
Max.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
iD8DBQFEEqnHfFNSmcDyxYARAu5OAJ0aYcT4nGfvsZuqj+LkA6hoq20P5gCfeidY
WQ7pj4S7W1Zva6/yDW9EVZ0=
=RRyr
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org