apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Kobes <ra...@theoryx5.uwinnipeg.ca>
Subject Perl glue to APR
Date Thu, 20 May 2004 20:16:28 GMT
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

Mime
View raw message