apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Mankin <man...@ants.com>
Subject Re: [APR PATCH] Bootstrapping problem on Mac OS X
Date Tue, 11 Jun 2002 06:01:57 GMT
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


Mime
View raw message