apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc M. Adkins" <Softw...@Doorways.org>
Subject Re: apr_dso_load
Date Thu, 25 Mar 2004 22:31:26 GMT
> Well, the first thing to remember is that we use native functions on all
> platforms.  So, we should follow the conventions for whatever platform you
> are on.  On Linux, you shouldn't be using NSLinkModule, you should be using
> dlopen. What distribution of Linux are you using?  To determine exactly
> which dso path you are using, check include/arch/unix/apr_private.h for
> DSO_USE.  On Linux, the DSO_USE_DLFCN macro should be the one that is
> defined, which means you are using dlopen.  According to the dlopen man
> page, it should be looking through LD_LIBRARY_PATH for libraries, which is
> the behavior I remember.

Yup, sure is.

I had forgotten or not known about apr_private.h.  I was just skimming the
dso.c code, paying little attention to all those pesky #if bits, and I missed
the efficient little dlopen() call amidst all that impressive
NextStep...wait...that's OS/X now...stuff.

I then compounded that by forgetting for the umpteenth time that I have to
'export' the environment variable and not just 'set' it.  Sigh.  So many
operating systems, so little time...

Anyway, thanks for the pointer.  I remember kind of wondering about how those
architecture files fit into the picture all those many months ago.  That
apr_private.h file is obviously the key to the puzzle.

So...I'm _almost_ working again.  But there's something funny going on with
one of my modules.  I have some static data defined:

    static gate_dispatch_table_t    table[] = {
        {   "system:hostname",  GATE_USE_STRING_LEN,    &system_hostname   
 }, {   "system:username",  GATE_USE_STRING_LEN,    &system_username    },

But the structure seems to be loaded with garbage at run-time.  Like there's
some initialization code that isn't getting executed for the DLL?  Well, I'll
figure it out eventually.  After all, it _used_ to work.  I'm probably just
missing some vital gcc flag.



View raw message