You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Eric Gillespie <ep...@pretzelnet.org> on 2005/02/12 23:55:02 UTC
[PATCH] Fix --enable-dso for Darwin/Mac OS X
This has been bothering me for a while, so i finally worked up a
solution. No doubt this still leaves --enable-dso broken on some
platforms, but it leaves us no worse off while fixing Darwin and
marking a path to fixing it for other systems.
One problem though: Testing on NetBSD (where --enable-dso already
works), the tests pass with --enable-dso without this patch but
fail with it. I didn't go farther than ra-local-test:
START: ra-local-test
assertion "&VTBL == vtable" failed: file "subversion/libsvn_ra/wrapper_template.h", line 311, function "svn_ra_local_init"
END: ra-local-test
I don't understand why, though. It obviously works fine:
0 trunk% ./subversion/svnadmin/svnadmin create --fs-type bdb bdb
0 trunk% ./subversion/svnadmin/svnadmin create --fs-type fsfs fsfs
0 trunk% svn log file://$PWD/bdb
------------------------------------------------------------------------
0 trunk% svn log file://$PWD/fsfs
------------------------------------------------------------------------
Any help on that appreciated. Log message and patch follow.
Fix --enable-dso for Darwin/Mac OS X.
* configure.in
(SVN_LIBDIR): New svn_private_config.h macro representing libdir,
just like SVN_BINDIR.
(SVN_DSO_SUFFIX): New svn_private_config.h macro representing the
suffix of DSO files for fs-loader.c and ra_loader.c. This is
'.dylib' for Darwin and '.so' for everyone else.
Pass libdir along to svn_private_config.h as SVN_LIBDIR, just like
SVN_BINDIR. Pass SVN_DSO_SUFFIX to svn_private_config.h as .dylib
* subversion/libsvn_fs/fs-loader.c
(load_module): Use SVN_LIBDIR and SVN_DSO_SUFFIX to find DSO files.
* subversion/libsvn_ra/ra_loader.c
(load_ra_module): Use SVN_LIBDIR and SVN_DSO_SUFFIX to find DSO
files.
=== configure.in
==================================================================
--- configure.in (/trunk) (revision 1754)
+++ configure.in (/local/darwin-dso) (revision 1754)
@@ -148,6 +148,30 @@
AC_DEFINE_UNQUOTED(SVN_BINDIR, "${SVN_BINDIR}",
[Defined to be the path to the installed binaries])
+dnl Create SVN_LIBDIR for proper substitution
+if test "${libdir}" = '${exec_prefix}/lib'; then
+ if test "${exec_prefix}" = "NONE"; then
+ if test "${prefix}" = "NONE"; then
+ SVN_LIBDIR="${ac_default_prefix}/lib"
+ else
+ SVN_LIBDIR="${prefix}/lib"
+ fi
+ else
+ SVN_LIBDIR="${exec_prefix}/lib"
+ fi
+else
+ SVN_LIBDIR="${libdir}"
+fi
+
+dnl fully evaluate this value. when we substitute it into our tool scripts,
+dnl they will not have things such as ${libdir} available
+SVN_LIBDIR="`eval echo ${SVN_LIBDIR}`"
+AC_SUBST(SVN_LIBDIR)
+
+dnl provide ${libdir} in svn_private.h for use in compiled code
+AC_DEFINE_UNQUOTED(SVN_LIBDIR, "${SVN_LIBDIR}",
+ [Defined to be the path to the installed libraries])
+
dnl This purposely does *not* allow for multiple parallel installs.
dnl However, it is compatible with most gettext usages.
localedir='${datadir}/locale'
@@ -659,7 +683,19 @@
AC_SUBST(SVN_FS_LIB_INSTALL_DEPS)
AC_SUBST(SVN_FS_LIB_LINK)
+dnl Find out the DSO filename suffix for fs-loader.c and ra_loader.c.
+case ${host_os} in
+darwin*)
+ SVN_DSO_SUFFIX='.dylib'
+ ;;
+*)
+ SVN_DSO_SUFFIX='.so'
+ ;;
+esac
+AC_DEFINE_UNQUOTED(SVN_DSO_SUFFIX, "${SVN_DSO_SUFFIX}",
+ [Defined to be the suffix of DSO filenames])
+
dnl Possibly compile JavaHL (experimental)
do_javahl_build=no
AC_ARG_ENABLE(javahl,
=== subversion/libsvn_ra/ra_loader.c
==================================================================
--- subversion/libsvn_ra/ra_loader.c (/trunk) (revision 1754)
+++ subversion/libsvn_ra/ra_loader.c (/local/darwin-dso) (revision 1754)
@@ -116,8 +116,8 @@
const char *compat_funcname;
apr_status_t status;
- libname = apr_psprintf (pool, "libsvn_ra_%s-%d.so.0",
- ra_name, SVN_VER_MAJOR);
+ libname = apr_psprintf (pool, "%s/libsvn_ra_%s-%d%s",
+ SVN_LIBDIR, ra_name, SVN_VER_MAJOR, SVN_DSO_SUFFIX);
funcname = apr_psprintf (pool, "svn_ra_%s__init", ra_name);
compat_funcname = apr_psprintf (pool, "svn_ra_%s_init", ra_name);
=== subversion/libsvn_fs/fs-loader.c
==================================================================
--- subversion/libsvn_fs/fs-loader.c (/trunk) (revision 1754)
+++ subversion/libsvn_fs/fs-loader.c (/local/darwin-dso) (revision 1754)
@@ -82,8 +82,8 @@
const char *funcname;
apr_status_t status;
- libname = apr_psprintf (pool, "libsvn_fs_%s-%d.so.0",
- name, SVN_VER_MAJOR);
+ libname = apr_psprintf (pool, "%s/libsvn_fs_%s-%d%s",
+ SVN_LIBDIR, name, SVN_VER_MAJOR, SVN_DSO_SUFFIX);
funcname = apr_psprintf (pool, "svn_fs_%s__init", name);
/* Find/load the specified library. If we get an error, assume
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Fix --enable-dso for Darwin/Mac OS X
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2005-02-14 at 20:23, Eric Gillespie wrote:
> > I don't like how this change affects the existing platforms. We rely on
> > LD_LIBRARY_PATH for the dynamically linked libraries; why shouldn't we
> > be relying on it for the dynamically loaded ones? If someone relocates
> > a Subversion binary install, they can no longer use front-end scripts
> > and LD_LIBRARY_PATH to make it work, with this change.
> When you have the source, why do you need to relocate binaries?
No working compiler? Insufficient knowledge? Relocating a binary
package is not generally a good idea, but that's not an excuse for us to
use the wrong behavior for dynamically loaded libraries.
> But, if we allow relocation today and want to continue providing
> it, can we do this just for Darwin?
I don't know enough about Darwin to judge whether this is a good idea.
If it's necessary or standard practice on that platform, then sure.
> > (And I expect it's how you broke the test suite; you forced the program
> > to load the installed libraries, rather than the built ones.)
>
> Then why am i able to run svnadmin and svn from the working copy?
> Is the test suite bypassing the magic libtool scripts?
I don't know why you are able to run svnadmin and svn from the working
copy. I don't see how the magic libtool scripts can fix this problem;
they can relink the executable, but they can't change the value of
SVN_LIBDIR.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Fix --enable-dso for Darwin/Mac OS X
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Justin Erenkrantz <ju...@erenkrantz.com> writes:
> --On Monday, February 14, 2005 8:23 PM -0500 Eric Gillespie
> <ep...@pretzelnet.org> wrote:
>
> > Then why am i able to run svnadmin and svn from the working copy?
> > Is the test suite bypassing the magic libtool scripts?
>
> Darwin's linkers don't support relocatable libraries. Chances are that you
> are running from the installed libraries not the ones in your working
> copies. -- justin
I'll post a new patch that only does this for certain systems
(starting with Darwin), and defines a format string from
configure. And yes, i am running from the installed libraries,
otherwise it would be trying to load a nonexistent path. The
question remains. If i can run svnadmin and svn interactively
from the working copy and have them load the modules from the
right place, why does the test suite fall apart?
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Fix --enable-dso for Darwin/Mac OS X
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Monday, February 14, 2005 8:23 PM -0500 Eric Gillespie
<ep...@pretzelnet.org> wrote:
> Then why am i able to run svnadmin and svn from the working copy?
> Is the test suite bypassing the magic libtool scripts?
Darwin's linkers don't support relocatable libraries. Chances are that you
are running from the installed libraries not the ones in your working
copies. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Fix --enable-dso for Darwin/Mac OS X
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Greg Hudson <gh...@MIT.EDU> writes:
> I don't like how this change affects the existing platforms. We rely on
> LD_LIBRARY_PATH for the dynamically linked libraries; why shouldn't we
> be relying on it for the dynamically loaded ones? If someone relocates
> a Subversion binary install, they can no longer use front-end scripts
> and LD_LIBRARY_PATH to make it work, with this change.
When you have the source, why do you need to relocate binaries?
But, if we allow relocation today and want to continue providing
it, can we do this just for Darwin?
> (And I expect it's how you broke the test suite; you forced the program
> to load the installed libraries, rather than the built ones.)
Then why am i able to run svnadmin and svn from the working copy?
Is the test suite bypassing the magic libtool scripts?
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Fix --enable-dso for Darwin/Mac OS X
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sat, 2005-02-12 at 18:55, Eric Gillespie wrote:
> (SVN_LIBDIR): New svn_private_config.h macro representing libdir,
> just like SVN_BINDIR.
> (load_module): Use SVN_LIBDIR and SVN_DSO_SUFFIX to find DSO files.
I don't like how this change affects the existing platforms. We rely on
LD_LIBRARY_PATH for the dynamically linked libraries; why shouldn't we
be relying on it for the dynamically loaded ones? If someone relocates
a Subversion binary install, they can no longer use front-end scripts
and LD_LIBRARY_PATH to make it work, with this change.
(And I expect it's how you broke the test suite; you forced the program
to load the installed libraries, rather than the built ones.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Fix --enable-dso for Darwin/Mac OS X
Posted by Eric Gillespie <ep...@pretzelnet.org>.
"Max Bowsher" <ma...@ukf.net> writes:
> But, even without it, its more flexible than a simple suffix, and is
> flexible enough for me to make it work on Cygwin.
OK, i'll do that.
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Fix --enable-dso for Darwin/Mac OS X
Posted by Max Bowsher <ma...@ukf.net>.
Eric Gillespie wrote:
> "Max Bowsher" <ma...@ukf.net> writes:
>
>> Interesting... I thought you had to compile .bundles not .dylibs if you
>> wanted to load them programmatically?
>
> Nope; this works fine.
>
>> Certainly libtool seems to have a whole bunch of Darwin specific code
>> catering to that idea.
>>
>> Has Apple changed that?
>
> No idea, but it works on Panther.
Most curious.
>> Also, I'd rather that instead of having a plain suffix, we make the
>> printf-format-string the thing set by configure - that will allow me to
>> extend it to work on Cygwin too, when I get around to it.
>
> That would require being able to reorder printf arguments in the
> format string, wouldn't it? Is that portable?
No, that's not portable.
But, even without it, its more flexible than a simple suffix, and is
flexible enough for me to make it work on Cygwin.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Fix --enable-dso for Darwin/Mac OS X
Posted by Eric Gillespie <ep...@pretzelnet.org>.
"Max Bowsher" <ma...@ukf.net> writes:
> Interesting... I thought you had to compile .bundles not .dylibs if you
> wanted to load them programmatically?
Nope; this works fine.
> Certainly libtool seems to have a whole bunch of Darwin specific code
> catering to that idea.
>
> Has Apple changed that?
No idea, but it works on Panther.
> Also, I'd rather that instead of having a plain suffix, we make the
> printf-format-string the thing set by configure - that will allow me to
> extend it to work on Cygwin too, when I get around to it.
That would require being able to reorder printf arguments in the
format string, wouldn't it? Is that portable?
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Fix --enable-dso for Darwin/Mac OS X
Posted by Max Bowsher <ma...@ukf.net>.
Eric Gillespie wrote:
> This has been bothering me for a while, so i finally worked up a
> solution. No doubt this still leaves --enable-dso broken on some
> platforms, but it leaves us no worse off while fixing Darwin and
> marking a path to fixing it for other systems.
>
> One problem though: Testing on NetBSD (where --enable-dso already
> works), the tests pass with --enable-dso without this patch but
> fail with it. I didn't go farther than ra-local-test:
>
> START: ra-local-test
> assertion "&VTBL == vtable" failed: file
> "subversion/libsvn_ra/wrapper_template.h", line 311, function
> "svn_ra_local_init" END: ra-local-test
>
> I don't understand why, though. It obviously works fine:
>
> 0 trunk% ./subversion/svnadmin/svnadmin create --fs-type bdb bdb
> 0 trunk% ./subversion/svnadmin/svnadmin create --fs-type fsfs fsfs
> 0 trunk% svn log file://$PWD/bdb
> ------------------------------------------------------------------------
> 0 trunk% svn log file://$PWD/fsfs
> ------------------------------------------------------------------------
>
> Any help on that appreciated. Log message and patch follow.
Interesting... I thought you had to compile .bundles not .dylibs if you
wanted to load them programmatically?
Certainly libtool seems to have a whole bunch of Darwin specific code
catering to that idea.
Has Apple changed that?
Also, I'd rather that instead of having a plain suffix, we make the
printf-format-string the thing set by configure - that will allow me to
extend it to work on Cygwin too, when I get around to it.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org