You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Randy Kobes <ra...@theoryx5.uwinnipeg.ca> on 2004/05/20 22:16:28 UTC
Perl glue to APR
Hi,
Currently mod_perl 2 provides some APR::* modules
(APR::Pool, APR::Table, ...) as perl interfaces to some apr
functions. Right now they require the mod_perl.so module for
some functions this provides, but we would like to change
this so the modules work outside of mod_perl/httpd (for
example, for a cgi interface to apreq-2). A question came up
on this which perhaps someone can help with.
How it's being planned to divorce APR::* from mod_perl.so
is to include the sources for the relevant symbols currently
in mod_perl.so in building an APR.so, and then load APR.so
when using an APR::* module. However, this leads to the
possibility of someone loading both mod_perl.so and APR.so,
which would contain identical symbols. The question is then
if this would be a problem in general, or perhaps on
specific platforms?
I don't know if the following answers this question
in general, but I tried the following example. Suppose
there's a file a.c that provides a symbol testit():
=====================================================
// file a.c
#include "a.h"
#include <stdio.h>
void testit(void) {
printf("Hello from a\n");
}
=====================================================
and another that provides two symbols testit() and
testit_again():
=====================================================
// file b.c
#include "b.h"
#include <stdio.h>
void testit(void) {
printf("Hello from b\n");
}
void testit_again(void) {
printf("Hello again from b\n");
}
=====================================================
and a 3rd file c.c that provides printit() that uses
testit() and testit_again():
=====================================================
// file c.c
#include "c.h"
#include "a.h"
#include "b.h"
void printit(void) {
testit();
testit_again();
}
=====================================================
These were compiled as
export LD_LIBRARY_PATH=$HOME
gcc -c -fPIC a.c
gcc -shared -fPIC -o libmya.so a.o
gcc -c -fPIC b.c
gcc -shared -fPIC -o libmyb.so b.o
gcc -c -fPIC c.c
and libmyc.so made in two ways:
1) gcc -shared -fPIC -o libmyc.so -L$HOME -lmya -lmyb
2) gcc -shared -fPIC -o libmyc.so -L$HOME -lmyb -lmya
An application was then made using libmyc:
=====================================================
// file testit.c
#include "c.h"
int main(void) {
printit();
return 0;
}
======================================================
which was compiled as
gcc -o testit testit.c -L$HOME -lmyc
Using the 1st way of making libmyc.so (-lmya -lmyb)
has testit producing
Hello from a
Hello again from b
whereas the 2nd way (-lmyb -lmya) yields
Hello from b
Hello again from b
So, at least in this example, the 1st way of compiling
libmyc.so shows that one can have an application that uses
two libs that have a common symbol (testit), and which one
is used depends on the order of the libraries passed in at
link time.
The above worked on Linux, and also the equivalent on Win32,
using VC++. But I'm worried that this example may be too
simplistic, and problems may arise in more complex
situations, and/or such things can't be done on other OSs.
Any comments, pointers, etc. would be welcome. Thanks.
--
best regards,
randy kobes
Re: Perl glue to APR
Posted by Stas Bekman <st...@stason.org>.
Joe Orton wrote:
> On Thu, May 20, 2004 at 03:16:28PM -0500, Randy Kobes wrote:
>
>> How it's being planned to divorce APR::* from mod_perl.so
>>is to include the sources for the relevant symbols currently
>>in mod_perl.so in building an APR.so, and then load APR.so
>>when using an APR::* module. However, this leads to the
>>possibility of someone loading both mod_perl.so and APR.so,
>>which would contain identical symbols. The question is then
>>if this would be a problem in general, or perhaps on
>>specific platforms?
>
>
> AFAIK it wouldn't be a problem on any Unix using dlopen(), I'm not sure
> about AIX though, it's not very Unixy in this respect. Dunno about
> non-Unixes either.
Yeah, AIX is like windows. Any AIX experts here?
> Because if the way dlopen() is used in both httpd and Perl/DynaLoader
> (both passing the flags RTLD_GLOBAL|RTLD_NOW), you do get behaviour
> which is consistent with the ordering of the libraries passed to cc, and
> so you have to be careful, as I understand it:
On most unices perl doesn't pass RTLD_NOW. I know it does on MacOSX.
> There is a global symbol table for each process; in dlopen, any newly
> loaded .so files will have their undefined symbols resolved using that
> table. Any remaining newly defined symbols in the .so will then be
> added to that global symbol table.
>
> So if you have both mod_perl.so and some APR/Foo.so defining a global
> function 'foo', when mod_perl/Perl/Dynaloader loads the APR/Foo.so, all
> it's references to the function 'foo' will use the foo already loaded in
> mod_perl.so. Hence, obviously, you must make sure that any duplicate
> functions between the two objects really are the same function. Use of
> static data must be done carefully from such functions.
Good point. Though we should try hard to avoid using any static data at all in
the apr land, because of the threaded environment.
> Does that make sense and/or answer your question?
I suppose we could try to do that and if that doesn't work on certain
platforms, either provide a separate solution for those platforms or revert to
where things are now.
That's great. So pretty soon you will be able to write your favorite APR code
in perl w/o needing to have Apache/mod_perl around.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Perl glue to APR
Posted by Joe Orton <jo...@manyfish.co.uk>.
On Thu, May 20, 2004 at 03:16:28PM -0500, Randy Kobes wrote:
> How it's being planned to divorce APR::* from mod_perl.so
> is to include the sources for the relevant symbols currently
> in mod_perl.so in building an APR.so, and then load APR.so
> when using an APR::* module. However, this leads to the
> possibility of someone loading both mod_perl.so and APR.so,
> which would contain identical symbols. The question is then
> if this would be a problem in general, or perhaps on
> specific platforms?
AFAIK it wouldn't be a problem on any Unix using dlopen(), I'm not sure
about AIX though, it's not very Unixy in this respect. Dunno about
non-Unixes either.
Because if the way dlopen() is used in both httpd and Perl/DynaLoader
(both passing the flags RTLD_GLOBAL|RTLD_NOW), you do get behaviour
which is consistent with the ordering of the libraries passed to cc, and
so you have to be careful, as I understand it:
There is a global symbol table for each process; in dlopen, any newly
loaded .so files will have their undefined symbols resolved using that
table. Any remaining newly defined symbols in the .so will then be
added to that global symbol table.
So if you have both mod_perl.so and some APR/Foo.so defining a global
function 'foo', when mod_perl/Perl/Dynaloader loads the APR/Foo.so, all
it's references to the function 'foo' will use the foo already loaded in
mod_perl.so. Hence, obviously, you must make sure that any duplicate
functions between the two objects really are the same function. Use of
static data must be done carefully from such functions.
Does that make sense and/or answer your question?
joe