Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Date: Sun, 16 May 2004 23:53:59 -0500 (CDT)
From: Randy Kobes <randy@theoryx5.uwinnipeg.ca>
To: Stas Bekman <stas@stason.org>
cc: mod_perl Dev <dev@perl.apache.org>,
   apreq Developers <apreq-dev@httpd.apache.org>
Subject: Re: [mp2 patch] getting APR to work w/o modperl
In-Reply-To: <40A83A9C.4000409@stason.org>
Message-ID: <Pine.LNX.4.56.0405162326210.32753@theoryx5.uwinnipeg.ca>
References: <40997B19.3070608@stason.org> <4099C363.8000807@stason.org>
 <Pine.LNX.4.56.0405070019440.18598@theoryx5.uwinnipeg.ca>
 <409B2798.5020901@stason.org>
 <Pine.LNX.4.56.0405070127280.19335@theoryx5.uwinnipeg.ca>
 <409B323D.2090405@stason.org>
 <409B353E.8000102@stason.org>
 <Pine.LNX.4.56.0405070857270.25176@theoryx5.uwinnipeg.ca>
 <409BC20E.60701@stason.org>
 <Pine.LNX.4.56.0405100018150.9568@theoryx5.uwinnipeg.ca>
 <409F1DCA.5010806@stason.org>
 <Pine.LNX.4.56.0405102256350.31815@theoryx5.uwinnipeg.ca>
 <40A07177.40102@stason.org>
 <Pine.LNX.4.56.0405151611130.6178@theoryx5.uwinnipeg.ca>
 <40A691C1.8060305@stason.org>
 <Pine.LNX.4.56.0405161442120.26850@theoryx5.uwinnipeg.ca>
 <Pine.LNX.4.58.0405161730290.12135@rabbit.stason.org>
 <Pine.LNX.4.56.0405162215140.31968@theoryx5.uwinnipeg.ca>
 <40A83A9C.4000409@stason.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sun, 16 May 2004, Stas Bekman wrote:

[ ... ]
> That's excellent. So you link APR/Foo.so against APR.so
> which contains the minimal amount of modperl_xxx.o in it
> which is already provided by my patch (you only need to
> arrange linking against APR.lib instead of mod_perl.lib).
> APR/Foo.pm then must make sure that APR.pm (and so APR.so)
> are loaded before it loads its own APR/Foo.so. But this
> could be done later, for now let's say that we do it
> manually, by doing
>
>    PerlModule APR
>
> immediately after
>
>    LoadModule mod_perl.so
>
> Now the question is, whether the same could work for all
> other platforms. I was sure that's it's not possible to
> load two objects with the same symbols, but I could be
> wrong. Do you know whether this is true for all platforms?

I'm not sure at the moment, but here's the test case
I used with VC++ (I'll try it tomorrow on linux).
First build a.dll that exports a symbol testit():
==================================================
#include "a.h"
#include <stdio.h>
void testit(void) {
  printf("Hello from a\n");
}
=================================================
which is compiled as
  cl -c a.c
  link -dll a.obj ... -def:a.def -out:a.dll

Then build b.dll that exports 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");
}
=================================================
which is compiled as
  cl -c b.c
  link -dll b.obj ... -def:b.def -out:b.dll

Now build a 3rd dll c.dll that exports printit()
and imports testit() and testit_again():
=================================================
// file c.c
#include "c.h"
#include "a.h"
#include "b.h"
void printit(void) {
  testit();
  testit_again();
}
=================================================
which is compiled as
   cl -c c.c
but linked in one of two ways:
   1) link -dll c.obj a.lib b.lib ... -def:c.def -out:c.dll
   1) link -dll c.obj b.lib a.lib ... -def:c.def -out:c.dll

An application testit.c is then built which is linked
against c.lib:
================================================
// file testit.c
#include "c.h"

int main(void) {
  printit();
  return 0;
}
===============================================
   cl testit.c c.lib

If c.lib is built the 1st way (a.lib b.lib), then
testit outputs
   Hello from a
   Hello again from b
and requires c.dll, a.dll, and b.dll to be available. Thus,
even though both a.dll and b.dll both contain testit(), and
both dlls get loaded in the application, c.dll uses the
testit() from a.dll, since it was specified first at link
time.

On the other hand, if c.lib is built the 2nd way (b.lib
a.lib), then testit outputs
   Hello from b
   Hello again from b
and requires c.dll and b.dll to be available. In this
case all symbols get resolved by b.dll, as it was
specified first at link time, and so a.dll is ignored.

-- 
best regards,
randy