On Thu, 6 Jan 2005, Nick *** wrote:
> >>>> > /usr/src/mp2/xs/APR/Base64/APR__Base64.h: In function
> >>>> > `MPXS_apr_base64_encode':
> >>>> > /usr/src/mp2/xs/APR/Base64/APR__Base64.h:37: static
> >>>> > symbol `MPXS_apr_base64_enco de' is marked dllexport
[ ... ]
> I've found the source of all evil with some googling and
> searching the archives! :))) About the dllexport thing -
> it seems this is a bug in cygwin's gcc version. I'll wait
> for the next binary release (3.3.3 or 3.4.3), because I
> can't build 3.4.3 from source - I get some errors.
That's great that that's been resolved.
> About the undefined symbols when linking mod_perl.so - as
> Stas said, these symbols should be resolved at runtime,
> but as much as I understand (by googling), windows doesn't
> allow this. These sybbols should be defined/resolved
> (don't know what's the difference) at linking time. The
> good news is that under cygwin you can link very easily to
> an already compiled .dll file. And the one that we need is
> called libhttpd.dll. What's the bad news? Apache 1.xx had
> this configure option: --enable-rule=SHARED_CORE, which
> builds the server and libhttpd.dll, which contains the
> whole core.
> I don't know if this option is still valid for Apache
> 2.xx. Does anyone know? I can't test it, because when I
> execute ./configure --enable-rule=SHARED_CORE or
> ./configure --enable-so or anything other than
> --prefix=/path I get some errors not related to an invalid
> 'enable-rule=SHARED_CORE' option. Maybe it's a bug in
> apache's configure script. I've written to apache's
> mailing list about this problem.
>
> Anyway, if you are sure that enable-rule=SHARED_CORE is
> available for apache 2.x and does the same as for apache
> 1.x, I suggest that when configuring mp2 under cygwin, the
> process tests whether apache was compiled with
> --enable-rule=SHARED_CORE and if not - suggest to the user
> to compile the server with this option and then die.
>
> When linking mod_perl.so the current command is this:
[ .. ]
> The new command should look like this:
> ld2 -L/usr/local/lib \
[ ... ]
> -lperl -lcrypt -lgdbm_compat /home/admin/httpd/bin/libhttpd.dll
I didn't quite follow this - was the libhttpd.dll you used
built as a result of a "standard" Apache build (without
trying to invoke the enable-rule=SHARED_CORE configuration
option)? If not, how did you build it?
Also, is there a libhttpd.lib installed, perhaps under
$APACHE2/lib/, created either with a "standard" or
"non-standard" build? If not, is there a library there
with the same name but a different extension?
Can you try the following patch against lib/Apache/Build.pm
in the mod_perl-2 sources, to see if this adds the needed
dlls to the linking phase?
===========================================================
Index: lib/Apache/Build.pm
===================================================================
--- lib/Apache/Build.pm (revision 124393)
+++ lib/Apache/Build.pm (working copy)
@@ -31,6 +31,7 @@
use constant HPUX => $^O eq 'hpux';
use constant OPENBSD => $^O eq 'openbsd';
use constant WIN32 => $^O eq 'MSWin32';
+use constant CYGWIN => $^O eq 'cygwin';
use constant MSVC => WIN32() && ($Config{cc} eq 'cl');
@@ -1486,6 +1487,13 @@
"@libs";
}
+sub apache_libs_cygwin {
+ my $self = shift;
+ my $prefix = $self->apxs(-q => 'PREFIX');
+ my @libs = map { "$prefix/bin/lib$_.dll" } qw(apr aprutil httpd);
+ "@libs";
+}
+
sub apache_libs {
my $self = shift;
my $libs = \&{"apache_libs_$^O"};
=====================================================================
And if there is a $APACHE2/lib/libhttpd.lib installed,
does changing
+ my @libs = map { "$prefix/bin/lib$_.dll" } qw(apr aprutil httpd);
to
+ my @libs = map { "$prefix/lib/lib$_.lib" } qw(apr aprutil httpd);
in the above patch work? If a different prefix for the
library other than .lib used, this change should be modified
accordingly.
--
best regards,
randy
