Re: mod_perl.c:61: `my_perl' undeclared under Cygwin

[prev] [thread] [next] [Date index for 2005/01/06]

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