You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by br...@xbc.nu on 2004/01/08 10:03:06 UTC
inclusion of r8098 into 1.0
(Unfortunately I can't commit to the repository at the moment, so I'm casting
my vote here. Sorry about the mess.)
Here's what branches/1.0-stabilization/STATUS has to say about r8098:
> * r8098
> Load RA modules as foo-MAJOR.so.0 instead of foo-MAJOR.so.
> Justification: Low risk; we should be nice to binary packagers.
> Votes:
> +1: ghudson, epg, sussman
> +0: cmpilato
And this is from the commit log:
> From Ben Reser: don't use the .so link when loading RA libraries,
> because .so links are only supposed to be necessary for development.
> Instead use the .so.0 link (APR versioning requires the number
> following .so to be 0).
1) What does this do to portability? Is the whole dymnamic RA
loading thing limited to ELF systems, or to Linux systems,
or what? I know it never worked on Windows, and we never
promised it did. But what about Mac OS X or HP-UX? I'm
99% certain it won't work there.
2) "APR versioning requires the number following .so to be 0"?
The svn libraries don't follow the APR version numbers, and
we have a different ABI version (ours is 1, not 0).
In short, I don't understand how this change affects portability, our
dependencies on the APR version, etc. I also don't know how often this
feature is used at all, and how often it's tested.
-1 for now.
At the very least I'd like to see documentation that addresses my
concerns. I don't mind if the feature is not portable, I'm just
nervous because I don't understand the issues.
Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: inclusion of r8098 into 1.0
Posted by br...@xbc.nu.
Quoting Greg Hudson <gh...@MIT.EDU>:
> I don't know about HPUX. How are shared libraries installed there?
They're called *.sl, not *.so, so it's pretty much certain that dynamic linking
won't work there at all.
>
> > 2) "APR versioning requires the number following .so to be 0"?
> > The svn libraries don't follow the APR version numbers, and
> > we have a different ABI version (ours is 1, not 0).
>
> I'm talking about the rules in
> <http://apr.apache.org/versioning.html>,
> not the version numbers of the APR libraries themselves. In this
> scheme, the library's major number is included in the library name,
> while the major number in the libtool version info is always set to 0.
>
> (This is to allow deliberate linking against a particular major
> version of the libraries.)
Ah, I begin to see the light.
> I think the answer to your question is: because APR does not provide
> enough DSO machinery, the feature is currently only portable to ELF
> systems.
All right. Since the patch seems not to have changed that restriction in any
way, I withdraw my vote; that is, my veto.
Thanks for the explanation.
Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: inclusion of r8098 into 1.0
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, January 9, 2004 12:48 AM -0500 Greg Hudson <gh...@MIT.EDU>
wrote:
> to the actual libraries, or copies of them, or something. (I'm not
> actually sure whether libtool would help us do the symlink thing
> portably.)
More or less, the -module flag in libtool is meant to create DSOs that aren't
in the name of the standard extension on that platform. And, we could use a
variant of httpd's instdso.sh file to install the files correctly.
But, given that what we have only works on one platform (and not that well), I
think we should either punt this 'feature' or make sure it works correctly on
every platform. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: inclusion of r8098 into 1.0
Posted by Ben Reser <be...@reser.org>.
On Fri, Jan 09, 2004 at 12:48:09AM -0500, Greg Hudson wrote:
> But Apache modules aren't installed for normal linking purposes like
> Subversion RA libraries are. So if we want to adopt the Apache scheme,
> we'll have to create a directory for RA libraries and install symlinks
> to the actual libraries, or copies of them, or something. (I'm not
> actually sure whether libtool would help us do the symlink thing
> portably.)
Actually I would much prefer this. Treating the RA libraries as regular
libraries was rather confusing to me at first. But then that would be
possibly problematic as you don't always use DSO.
> I'd say we should just ditch run-time repository loading, but Ben uses
> it in the Red Hat RPMs, and it means that the installed binary set can
> be chopped up more finely than it could otherwise.
Mandrake. But yeah it does make the packages not suck in dependencies
that a user wouldn't need otherwise.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: inclusion of r8098 into 1.0
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2004-01-08 at 17:48, Justin Erenkrantz wrote:
> > I think the answer to your question is: because APR does not provide
> > enough DSO machinery, the feature is currently only portable to ELF
> > systems. But it's possible that it worked on HPUX before and doesn't
> > now, in which case we have to make a decision between working correctly
> > on ELF systems and working at all on HPUX.
> Not sure what you are looking for here, but what we do in httpd is that all
> module DSOs are installed as .so regardless of the platform and its
> specific/preferred extension. And, the apr_dso_load will correctly call
> the native function to load that dynamic library.
But Apache modules aren't installed for normal linking purposes like
Subversion RA libraries are. So if we want to adopt the Apache scheme,
we'll have to create a directory for RA libraries and install symlinks
to the actual libraries, or copies of them, or something. (I'm not
actually sure whether libtool would help us do the symlink thing
portably.)
I'd say we should just ditch run-time repository loading, but Ben uses
it in the Red Hat RPMs, and it means that the installed binary set can
be chopped up more finely than it could otherwise.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: inclusion of r8098 into 1.0
Posted by Ben Reser <be...@reser.org>.
On Thu, Jan 08, 2004 at 02:48:18PM -0800, Justin Erenkrantz wrote:
> But, I'm not at all sure what this RA run-time loading 'feature' is doing
> in Subversion - I've never understood it. libsvn_ra_dav and libsvn_ra_svn,
> libsvn_ra_local are already specified on the link line, so the compiled
> binaries are going to already pull those libraries in (and fail if they
> aren't there).
Not if you use --enable-dso on configure.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: inclusion of r8098 into 1.0
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, January 8, 2004 9:55 AM -0500 Greg Hudson <gh...@MIT.EDU>
wrote:
> I think the answer to your question is: because APR does not provide
> enough DSO machinery, the feature is currently only portable to ELF
> systems. But it's possible that it worked on HPUX before and doesn't
> now, in which case we have to make a decision between working correctly
> on ELF systems and working at all on HPUX.
Not sure what you are looking for here, but what we do in httpd is that all
module DSOs are installed as .so regardless of the platform and its
specific/preferred extension. And, the apr_dso_load will correctly call
the native function to load that dynamic library.
But, I'm not at all sure what this RA run-time loading 'feature' is doing
in Subversion - I've never understood it. libsvn_ra_dav and libsvn_ra_svn,
libsvn_ra_local are already specified on the link line, so the compiled
binaries are going to already pull those libraries in (and fail if they
aren't there). -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: inclusion of r8098 into 1.0
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2004-01-08 at 05:03, brane@xbc.nu wrote:
> > From Ben Reser: don't use the .so link when loading RA libraries,
> > because .so links are only supposed to be necessary for development.
> > Instead use the .so.0 link (APR versioning requires the number
> > following .so to be 0).
>
>
> 1) What does this do to portability? Is the whole dymnamic RA
> loading thing limited to ELF systems, or to Linux systems,
> or what? I know it never worked on Windows, and we never
> promised it did. But what about Mac OS X or HP-UX? I'm
> 99% certain it won't work there.
On OSX, the shared libraries are apparently installed as:
libsvn_subr-1.0.0.0.dylib*
libsvn_subr-1.0.dylib -> libsvn_subr-1.0.0.0.dylib*
which means dynamic loading won't work with or without the patch.
I don't know about HPUX. How are shared libraries installed there?
> 2) "APR versioning requires the number following .so to be 0"?
> The svn libraries don't follow the APR version numbers, and
> we have a different ABI version (ours is 1, not 0).
I'm talking about the rules in <http://apr.apache.org/versioning.html>,
not the version numbers of the APR libraries themselves. In this
scheme, the library's major number is included in the library name,
while the major number in the libtool version info is always set to 0.
(This is to allow deliberate linking against a particular major version
of the libraries.)
> In short, I don't understand how this change affects portability, our
> dependencies on the APR version, etc. I also don't know how often this
> feature is used at all, and how often it's tested.
It's used when you build with --enable-dso, which causes
SVN_LIBSVN_CLIENT_LINKS_RA_{DAV,SVN,LOCAL} to become undefined, so that
the entries in the ra_libraries table become NULL. In turn,
svn_ra_get_ra_library() loads the appropriate module.
I think the answer to your question is: because APR does not provide
enough DSO machinery, the feature is currently only portable to ELF
systems. But it's possible that it worked on HPUX before and doesn't
now, in which case we have to make a decision between working correctly
on ELF systems and working at all on HPUX.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org