You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by David Mankin <ma...@ants.com> on 2002/06/10 08:44:05 UTC
[APR PATCH] Bootstrapping problem on Mac OS X
This weekend I tried to bootstrap subversion from the r1868 tarball.
However, I ran into a Mac OS X related stopper. Every time I tried to
run svn to checkout the repository, it exited with this error:
dyld: svn can't open library: libsvn_ra_local.so (No such file or directory, errno = 2)
I configured and built svn with the --enable-maintainer-mode and
--disable-shared.
Using gdb I tracked the problem down to a call in APR's apr_dso_load()
in unix/dso.c, line 144. apr_dso_load calls NSAddLibrary(path). It
checks the return value of NSAddLibrary. Unfortunately, if you don't
setup an error handler with a call to NSInstallLinkEditErrorHandlers(),
then all link errors are fatal and the whole program exits.
The man page for NSAddLibrary() (NSModule(3)) is a little confusing on
what an error in NSAddLibrary() means. Two excerpts:
NSAddLibrary is passed the file name of a dynamic shared
library to be added to the search list. If it is success-
ful it returns TRUE else it returns FALSE.
...
If the user does not supply [error handlers], the default
will be to write an error message on to file descriptor 2
(usually stderr) and exit the program... [except for warnings].
(Whole manpage available at http://www.osxfaq.com/man/3/NSModule.ws)
My experience shows that on failure, rather than returning FALSE, the
default error handling is exiting the program.
I really don't know much about dynamic libraries or APR, so I don't know
the right way to fix this. At the end of this message is a patch for
APR that works for me and at least makes the Subversion bootstrapping
work. But I'm nowhere near sure it's good to apply this to APR. (For
instance, my patch installs NSLinkEditErrorHandlers, but never
uninstalls them. I don't know if it should. Also, it compiles with
warnings.)
IMO this is a bug in APR that should be fixed (trying to load a
non-existent library shouldn't kill the program).
However, I think there might also be a bug (or several) in Subversion.
I compiled with --disable-shared, and yet subversion is still trying to
load a dynamic library. I'm trying to do an HTTP checkout, and yet it's
trying to load a dynamic library for RA local. Both of these seem like
they might be problems. (And even with my patch to APR, I still get a
warning, about not being able to load libsvn_ra_local.so, every time I
do anything with the client. Maybe my patch should throw away the error
instead of printing it?)
[A fourth thing that may be an issue: when I modified dso.c and then
re-ran make from the top-level svn makefile, it didn't re-link the svn
binary, even though the apr.la (?) library had changed. I had to touch
clients/cmdline/main.c in order to force make to rebuild svn.]
Here was my stack trace when apr quits my program:
#0 apr_dso_load (res_handle=0xbffff5b8, path=0xbffff580 "¿ÿõà¿ÿù´",
pool=0x18) at dso.c:148
#1 0x00039d54 in load_ra_module (func=0xbffff620, ra_name=0x9a724
"local", pool=0x2a8350) at subversion/libsvn_ra/ra_loader.c:96
#2 0x00039e84 in svn_ra_init_ra_libs (ra_baton=0xbffff6a8,
pool=0x2a8350) at subversion/libsvn_ra/ra_loader.c:150
#3 0x0000cf1c in svn_client_checkout (before_editor=0x0,
before_edit_baton=0x0, after_editor=0x2a8600, after_edit_baton=0x2ac550,
auth_baton=0x2a85e8, URL=0x2a85d8, path=0x2a84b8, revision=0xbffff798,
recurse=1, xml_src=0x0, pool=0x2a8350) at
subversion/libsvn_client/checkout.c:105
#4 0x00002abc in svn_cl__checkout (os=0x2a8468, opt_state=0xbffff798,
pool=0x2a8350) at subversion/clients/cmdline/checkout-cmd.c:125
#5 0x0000689c in main (argc=5, argv=0xbffff99c) at
subversion/clients/cmdline/main.c:1108
#6 0x0000266c in _start ()
#7 0x0000249c in start ()
(line numbers, except in dso.c, reference r1868, sorry.)
I haven't dug into the svn code enough to know how to fix the problems,
but here's my patch to dso.c:
--- subversion-r1868-clean/apr/dso/unix/dso.c Fri May 3 09:00:27 2002
+++ subversion-r1868/apr/dso/unix/dso.c Mon Jun 10 01:35:52 2002
@@ -115,6 +115,25 @@
return APR_SUCCESS;
}
+/*
+ * Under Darwin, we need to have a linkEdit error handler, or else if
+ * NSAddLibrary() fails, it will exit the whole program. This function prints
+ * the same message that the OS would, but does not exit the program.
+ */
+#if defined(DSO_USE_DYLD)
+APR_DECLARE(void) apr_dso_load_linkEdit_errorhander(NSLinkEditErrors errorClass,
+ int errorNumber,
+ const char *filename,
+ const char *errorString)
+{
+ if (errorString != NULL) {
+ fprintf(stderr, "%s", errorString);
+ } else {
+ fprintf(stderr, "LinkEdit error! errorno = %d\n", errorNumber);
+ }
+}
+#endif
+
APR_DECLARE(apr_status_t) apr_dso_load(apr_dso_handle_t **res_handle,
const char *path, apr_pool_t *pool)
{
@@ -125,6 +144,21 @@
NSObjectFileImage image;
NSModule os_handle = NULL;
char* err_msg = NULL;
+
+ /*
+ * Only set the linkEdit handler, not the missing-symbol or
+ * multiply-defined-symbol handlers.
+ */
+ NSLinkEditErrorHandlers error_handlers = {
+ NULL, NULL, &apr_dso_load_linkEdit_errorhander
+ };
+ /*
+ * Load fprintf so that the error handler can use it. Otherwise we can get
+ * deadlock because the error handling needs to load the fprintf library.
+ */
+ fprintf(stderr, "");
+ NSInstallLinkEditErrorHandlers(&error_handlers);
+
if (NSCreateObjectFileImageFromFile(path, &image) == NSObjectFileImageSuccess) {
/*
If people want, I can provide the patch as a diff against APR HEAD so
that someone (Sander?) can apply it or pass it off the the APR folks.
-David Mankin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [APR PATCH] Bootstrapping problem on Mac OS X
Posted by David Mankin <ma...@ants.com>.
On Mon, 10 Jun 2002, Justin Erenkrantz wrote:
> On Mon, Jun 10, 2002 at 01:44:05AM -0700, David Mankin wrote:
> >
> > This weekend I tried to bootstrap subversion from the r1868 tarball.
> > However, I ran into a Mac OS X related stopper. Every time I tried to
> > run svn to checkout the repository, it exited with this error:
> >
> > dyld: svn can't open library: libsvn_ra_local.so (No such file or directory, errno = 2)
> >
> > I configured and built svn with the --enable-maintainer-mode and
> > --disable-shared.
>
> Please try with the latest of APR and SVN (remember a bootstrap
> isn't meant to do anything other than get the latest of SVN). There
> have been some fixes to APR's handling of Darwin DSOs recently. I'm
> not sure if it fixes this or not, but it might. Please try that
> though.
I haven't tried it with the latest APR and SVN yet (It took me all
weekend to get the bootstrap to bootstrap), but I did check the HEAD of
APR in CVS and the code in question hasn't changed substantially since
the version rolled in the SVN tarball. So, I'm pretty sure that I'll be
able to reproduce it, but won't be able to try until later this evening.
> I believe that Pier's patch that we added to call NSAddLibrary is a
> tad bogus. I think it should only call NSAddLibrary if and only if
> NSCreateObjectFileImageFromFile returns NSObjectFileImageFormat.
> That would be my guess as to Pier's failure case for loading
> the JVM shared libraries. (Pier, if you are reading this, can you
> please check if this is indeed what is returned? I don't know how
> to reproduce your case.)
I don't know enough about Darwin library loading to comment, but it does
look a little strange.
> I will attempt to reproduce this later tonight. My problem with
> OS X and SVN is that the DAV client does not work properly. This
> problem is nasty to investigate because the process enters an
> unkillable state where I can't do anything to it except reboot
> the machine. -- justin
-David Mankin
Re: [APR PATCH] Bootstrapping problem on Mac OS X
Posted by David Mankin <ma...@ants.com>.
On Mon, 10 Jun 2002, Justin Erenkrantz wrote:
> On Mon, Jun 10, 2002 at 01:44:05AM -0700, David Mankin wrote:
> >
> > This weekend I tried to bootstrap subversion from the r1868 tarball.
> > However, I ran into a Mac OS X related stopper. Every time I tried to
> > run svn to checkout the repository, it exited with this error:
> >
> > dyld: svn can't open library: libsvn_ra_local.so (No such file or directory, errno = 2)
> >
> > I configured and built svn with the --enable-maintainer-mode and
> > --disable-shared.
>
> Please try with the latest of APR and SVN (remember a bootstrap
> isn't meant to do anything other than get the latest of SVN). There
> have been some fixes to APR's handling of Darwin DSOs recently. I'm
> not sure if it fixes this or not, but it might. Please try that
> though.
I haven't tried it with the latest APR and SVN yet (It took me all
weekend to get the bootstrap to bootstrap), but I did check the HEAD of
APR in CVS and the code in question hasn't changed substantially since
the version rolled in the SVN tarball. So, I'm pretty sure that I'll be
able to reproduce it, but won't be able to try until later this evening.
> I believe that Pier's patch that we added to call NSAddLibrary is a
> tad bogus. I think it should only call NSAddLibrary if and only if
> NSCreateObjectFileImageFromFile returns NSObjectFileImageFormat.
> That would be my guess as to Pier's failure case for loading
> the JVM shared libraries. (Pier, if you are reading this, can you
> please check if this is indeed what is returned? I don't know how
> to reproduce your case.)
I don't know enough about Darwin library loading to comment, but it does
look a little strange.
> I will attempt to reproduce this later tonight. My problem with
> OS X and SVN is that the DAV client does not work properly. This
> problem is nasty to investigate because the process enters an
> unkillable state where I can't do anything to it except reboot
> the machine. -- justin
-David Mankin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [APR PATCH] Bootstrapping problem on Mac OS X
Posted by Justin Erenkrantz <je...@apache.org>.
On Mon, Jun 10, 2002 at 01:44:05AM -0700, David Mankin wrote:
>
> This weekend I tried to bootstrap subversion from the r1868 tarball.
> However, I ran into a Mac OS X related stopper. Every time I tried to
> run svn to checkout the repository, it exited with this error:
>
> dyld: svn can't open library: libsvn_ra_local.so (No such file or directory, errno = 2)
>
> I configured and built svn with the --enable-maintainer-mode and
> --disable-shared.
Please try with the latest of APR and SVN (remember a bootstrap
isn't meant to do anything other than get the latest of SVN). There
have been some fixes to APR's handling of Darwin DSOs recently. I'm
not sure if it fixes this or not, but it might. Please try that
though.
I believe that Pier's patch that we added to call NSAddLibrary is a
tad bogus. I think it should only call NSAddLibrary if and only if
NSCreateObjectFileImageFromFile returns NSObjectFileImageFormat.
That would be my guess as to Pier's failure case for loading
the JVM shared libraries. (Pier, if you are reading this, can you
please check if this is indeed what is returned? I don't know how
to reproduce your case.)
I will attempt to reproduce this later tonight. My problem with
OS X and SVN is that the DAV client does not work properly. This
problem is nasty to investigate because the process enters an
unkillable state where I can't do anything to it except reboot
the machine. -- justin
Re: [APR PATCH] Bootstrapping problem on Mac OS X
Posted by David Mankin <ma...@ants.com>.
On Mon, 10 Jun 2002, Greg Stein wrote:
> > (And even with my patch to APR, I still get a
> > warning, about not being able to load libsvn_ra_local.so, every time I
> > do anything with the client. Maybe my patch should throw away the error
> > instead of printing it?)
>
> Hmm? What is printing that warning? I don't see any code in ra_loader.c that
> would do that.
It was my patch printing that warning (instead of Darwin that used to
print the warning before exiting). See below...
> >...
> > +/*
> > + * Under Darwin, we need to have a linkEdit error handler, or else if
> > + * NSAddLibrary() fails, it will exit the whole program. This function prints
> > + * the same message that the OS would, but does not exit the program.
> > + */
> > +#if defined(DSO_USE_DYLD)
> > +APR_DECLARE(void) apr_dso_load_linkEdit_errorhander(NSLinkEditErrors errorClass,
> > + int errorNumber,
> > + const char *filename,
> > + const char *errorString)
> > +{
> > + if (errorString != NULL) {
> > + fprintf(stderr, "%s", errorString);
> > + } else {
> > + fprintf(stderr, "LinkEdit error! errorno = %d\n", errorNumber);
> > + }
>
> The APR library is not allowed to use stderr. The only thing you can do is
> return errors.
>
Thanks, Greg. See, I told ya I don't know much about APR. I printed the
error message just like Darwin does. (Actually it uses fd 2, instead of
stderr, but I doubt that APR should do that either.) I'll take the
printing out of my patch.
I don't know how to get the message back to the client, though. The
message is passed to the error-handler callback, and not returned on the
NSAddLibrary() call. Maybe the callback should store the pointer to the
message in some static variable that the NSAddLibrary can return as the
error? The thread-safety-conscious Java programmer in me doesn't like
that very much, but maybe it would be okay? Pseudo code:
static char* last_error_message = NULL;
void apr_dso_load_linkedit_error_handler(const char* msg, ...)
{
last_error_message = msg;
}
apr_status_t apr_dso_load(...)
{
char* err_msg = NULL;
...
else if (NSAddLibrary(path) == TRUE) {
...
} else {
err_msg = last_error_message ? last_error_message :
"cannot create object file image or add library";
last_error_message = NULL;
}
...
}
This doesn't seem safe, but I can't think of another way to get the OS
error message out. (But it's been a *long* time since I've coded in C,
maybe I'm missing something.) It'd be a shame to just lose the OS error
with its useful information (file not found, e.g.) and replace it with
"cannot add library".
Ideas & suggestions welcome.
-David Mankin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [APR PATCH] Bootstrapping problem on Mac OS X
Posted by David Mankin <ma...@ants.com>.
On Mon, 10 Jun 2002, Greg Stein wrote:
> > (And even with my patch to APR, I still get a
> > warning, about not being able to load libsvn_ra_local.so, every time I
> > do anything with the client. Maybe my patch should throw away the error
> > instead of printing it?)
>
> Hmm? What is printing that warning? I don't see any code in ra_loader.c that
> would do that.
It was my patch printing that warning (instead of Darwin that used to
print the warning before exiting). See below...
> >...
> > +/*
> > + * Under Darwin, we need to have a linkEdit error handler, or else if
> > + * NSAddLibrary() fails, it will exit the whole program. This function prints
> > + * the same message that the OS would, but does not exit the program.
> > + */
> > +#if defined(DSO_USE_DYLD)
> > +APR_DECLARE(void) apr_dso_load_linkEdit_errorhander(NSLinkEditErrors errorClass,
> > + int errorNumber,
> > + const char *filename,
> > + const char *errorString)
> > +{
> > + if (errorString != NULL) {
> > + fprintf(stderr, "%s", errorString);
> > + } else {
> > + fprintf(stderr, "LinkEdit error! errorno = %d\n", errorNumber);
> > + }
>
> The APR library is not allowed to use stderr. The only thing you can do is
> return errors.
>
Thanks, Greg. See, I told ya I don't know much about APR. I printed the
error message just like Darwin does. (Actually it uses fd 2, instead of
stderr, but I doubt that APR should do that either.) I'll take the
printing out of my patch.
I don't know how to get the message back to the client, though. The
message is passed to the error-handler callback, and not returned on the
NSAddLibrary() call. Maybe the callback should store the pointer to the
message in some static variable that the NSAddLibrary can return as the
error? The thread-safety-conscious Java programmer in me doesn't like
that very much, but maybe it would be okay? Pseudo code:
static char* last_error_message = NULL;
void apr_dso_load_linkedit_error_handler(const char* msg, ...)
{
last_error_message = msg;
}
apr_status_t apr_dso_load(...)
{
char* err_msg = NULL;
...
else if (NSAddLibrary(path) == TRUE) {
...
} else {
err_msg = last_error_message ? last_error_message :
"cannot create object file image or add library";
last_error_message = NULL;
}
...
}
This doesn't seem safe, but I can't think of another way to get the OS
error message out. (But it's been a *long* time since I've coded in C,
maybe I'm missing something.) It'd be a shame to just lose the OS error
with its useful information (file not found, e.g.) and replace it with
"cannot add library".
Ideas & suggestions welcome.
-David Mankin
Re: [APR PATCH] Bootstrapping problem on Mac OS X
Posted by David Mankin <ma...@ants.com>.
[2 replies to your message, Greg, so that svn-only stuff doesn't bore
the APR folks.]
On Mon, 10 Jun 2002, Greg Stein wrote:
> On Mon, Jun 10, 2002 at 01:44:05AM -0700, David Mankin wrote:
> >...
> > I configured and built svn with the --enable-maintainer-mode and
> > --disable-shared.
> >...
> > However, I think there might also be a bug (or several) in Subversion.
> > I compiled with --disable-shared, and yet subversion is still trying to
> > load a dynamic library. I'm trying to do an HTTP checkout, and yet it's
> > trying to load a dynamic library for RA local. Both of these seem like
> > they might be problems.
>
> Not a problem, actually.
>
> The RA layer knows that ra_dav was linked in, and that ra_local is *not*
> linked in. Thus, it attempts to load it dynamically since the DSO facilities
> are available in APR.
>
> The --disable-shared switch controls whether shared libraries are *built*.
> It doesn't control whether SVN will attempt to find RA modules that were not
> linked into the app.
Since --disable-shared doesn't prevent module loading, I wonder if there
is a good reason to have a --don't-try-to-load-modules flag on the
compilation or running of the svn client. I can easily envision a case
where a particular version of svn (e.g. 1.0) is installed (with shared
libraries accessible in /usr/local/lib, e.g.) but after compiling a
static svn at a different version (1.1) without ra_local, you wouldn't
want it loading in the installed libraries just because they're there...
But maybe I've just got too-active an imagination.
> > [A fourth thing that may be an issue: when I modified dso.c and then
> > re-ran make from the top-level svn makefile, it didn't re-link the svn
> > binary, even though the apr.la (?) library had changed. I had to touch
> > clients/cmdline/main.c in order to force make to rebuild svn.]
>
> Hmm. That does seem to be a problem. Could you file an issue about that?
Will do.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [APR PATCH] Bootstrapping problem on Mac OS X
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Jun 10, 2002 at 01:44:05AM -0700, David Mankin wrote:
>...
> I configured and built svn with the --enable-maintainer-mode and
> --disable-shared.
>...
> However, I think there might also be a bug (or several) in Subversion.
> I compiled with --disable-shared, and yet subversion is still trying to
> load a dynamic library. I'm trying to do an HTTP checkout, and yet it's
> trying to load a dynamic library for RA local. Both of these seem like
> they might be problems.
Not a problem, actually.
The RA layer knows that ra_dav was linked in, and that ra_local is *not*
linked in. Thus, it attempts to load it dynamically since the DSO facilities
are available in APR.
The --disable-shared switch controls whether shared libraries are *built*.
It doesn't control whether SVN will attempt to find RA modules that were not
linked into the app.
> (And even with my patch to APR, I still get a
> warning, about not being able to load libsvn_ra_local.so, every time I
> do anything with the client. Maybe my patch should throw away the error
> instead of printing it?)
Hmm? What is printing that warning? I don't see any code in ra_loader.c that
would do that.
> [A fourth thing that may be an issue: when I modified dso.c and then
> re-ran make from the top-level svn makefile, it didn't re-link the svn
> binary, even though the apr.la (?) library had changed. I had to touch
> clients/cmdline/main.c in order to force make to rebuild svn.]
Hmm. That does seem to be a problem. Could you file an issue about that?
>...
> +/*
> + * Under Darwin, we need to have a linkEdit error handler, or else if
> + * NSAddLibrary() fails, it will exit the whole program. This function prints
> + * the same message that the OS would, but does not exit the program.
> + */
> +#if defined(DSO_USE_DYLD)
> +APR_DECLARE(void) apr_dso_load_linkEdit_errorhander(NSLinkEditErrors errorClass,
> + int errorNumber,
> + const char *filename,
> + const char *errorString)
> +{
> + if (errorString != NULL) {
> + fprintf(stderr, "%s", errorString);
> + } else {
> + fprintf(stderr, "LinkEdit error! errorno = %d\n", errorNumber);
> + }
The APR library is not allowed to use stderr. The only thing you can do is
return errors.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [APR PATCH] Bootstrapping problem on Mac OS X
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Jun 10, 2002 at 01:44:05AM -0700, David Mankin wrote:
>...
> I configured and built svn with the --enable-maintainer-mode and
> --disable-shared.
>...
> However, I think there might also be a bug (or several) in Subversion.
> I compiled with --disable-shared, and yet subversion is still trying to
> load a dynamic library. I'm trying to do an HTTP checkout, and yet it's
> trying to load a dynamic library for RA local. Both of these seem like
> they might be problems.
Not a problem, actually.
The RA layer knows that ra_dav was linked in, and that ra_local is *not*
linked in. Thus, it attempts to load it dynamically since the DSO facilities
are available in APR.
The --disable-shared switch controls whether shared libraries are *built*.
It doesn't control whether SVN will attempt to find RA modules that were not
linked into the app.
> (And even with my patch to APR, I still get a
> warning, about not being able to load libsvn_ra_local.so, every time I
> do anything with the client. Maybe my patch should throw away the error
> instead of printing it?)
Hmm? What is printing that warning? I don't see any code in ra_loader.c that
would do that.
> [A fourth thing that may be an issue: when I modified dso.c and then
> re-ran make from the top-level svn makefile, it didn't re-link the svn
> binary, even though the apr.la (?) library had changed. I had to touch
> clients/cmdline/main.c in order to force make to rebuild svn.]
Hmm. That does seem to be a problem. Could you file an issue about that?
>...
> +/*
> + * Under Darwin, we need to have a linkEdit error handler, or else if
> + * NSAddLibrary() fails, it will exit the whole program. This function prints
> + * the same message that the OS would, but does not exit the program.
> + */
> +#if defined(DSO_USE_DYLD)
> +APR_DECLARE(void) apr_dso_load_linkEdit_errorhander(NSLinkEditErrors errorClass,
> + int errorNumber,
> + const char *filename,
> + const char *errorString)
> +{
> + if (errorString != NULL) {
> + fprintf(stderr, "%s", errorString);
> + } else {
> + fprintf(stderr, "LinkEdit error! errorno = %d\n", errorNumber);
> + }
The APR library is not allowed to use stderr. The only thing you can do is
return errors.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [APR PATCH] Bootstrapping problem on Mac OS X
Posted by Justin Erenkrantz <je...@apache.org>.
On Mon, Jun 10, 2002 at 01:44:05AM -0700, David Mankin wrote:
>
> This weekend I tried to bootstrap subversion from the r1868 tarball.
> However, I ran into a Mac OS X related stopper. Every time I tried to
> run svn to checkout the repository, it exited with this error:
>
> dyld: svn can't open library: libsvn_ra_local.so (No such file or directory, errno = 2)
>
> I configured and built svn with the --enable-maintainer-mode and
> --disable-shared.
Please try with the latest of APR and SVN (remember a bootstrap
isn't meant to do anything other than get the latest of SVN). There
have been some fixes to APR's handling of Darwin DSOs recently. I'm
not sure if it fixes this or not, but it might. Please try that
though.
I believe that Pier's patch that we added to call NSAddLibrary is a
tad bogus. I think it should only call NSAddLibrary if and only if
NSCreateObjectFileImageFromFile returns NSObjectFileImageFormat.
That would be my guess as to Pier's failure case for loading
the JVM shared libraries. (Pier, if you are reading this, can you
please check if this is indeed what is returned? I don't know how
to reproduce your case.)
I will attempt to reproduce this later tonight. My problem with
OS X and SVN is that the DAV client does not work properly. This
problem is nasty to investigate because the process enters an
unkillable state where I can't do anything to it except reboot
the machine. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [APR PATCH] Bootstrapping problem on Mac OS X
Posted by Eric Gillespie <ep...@pretzelnet.org>.
"Sander Striker" <st...@apache.org> writes:
> Hmmm, I don't have access to an OS X box, so I won't be messing with this.
> Crosspost to dev@apr.apache.org, someone there will pick it up. Justin, do
> you have access to an OS X box and is this reproducable?
I can reproduce this.
--
Eric Gillespie <*> epg@pretzelnet.org
Conformity is a sin.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: [APR PATCH] Bootstrapping problem on Mac OS X
Posted by Sander Striker <st...@apache.org>.
> From: David Mankin [mailto:mankin@ants.com]
> Sent: 10 June 2002 10:44
> This weekend I tried to bootstrap subversion from the r1868 tarball.
> However, I ran into a Mac OS X related stopper. Every time I tried to
> run svn to checkout the repository, it exited with this error:
>
> dyld: svn can't open library: libsvn_ra_local.so (No such file or directory, errno = 2)
[...]
> If people want, I can provide the patch as a diff against APR HEAD so
> that someone (Sander?) can apply it or pass it off the the APR folks.
Hmmm, I don't have access to an OS X box, so I won't be messing with this.
Crosspost to dev@apr.apache.org, someone there will pick it up. Justin, do
you have access to an OS X box and is this reproducable?
> -David Mankin
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org