On 07/11/2013 11:06 AM, Jan Kaluža wrote:
The error is:
libaprext.lib(modperl_error.obj) : error LNK2001: unresolved external
symbol _perl_module
..\..\..\blib\arch\auto\APR\Brigade\Brigade.dll : fatal error LNK1120:
1 unresolved externals
On Windows we build a static library called libaprext.lib containing
various symbols otherwise found in mod_perl.lib/dll for APR DLLs to
link against so that they don't have a dependency on mod_per.dll --
see the comments in the top-level Makefile.PL around line 187.
The list of source files whose objects are put in this library (given
by ModPerl::Code::src_apr_ext()) is:
modperl_error.c
modperl_bucket.c
modperl_common_util.c
modperl_common_log.c
So the problem here is that modperl_error.c is included in
libaprext.lib, but it references the symbol "perl_module", which is
defined in mod_perl.c, but that isn't included in libaprext.lib, so
the symbol is unresolved when linking APR/Brigade.dll (and presumably
any other APR/*.dll which links against libaprext.lib).
Simply throwing mod_perl.c into libaprext.lib too doesn't work because
it references many, many other symbols which are also not included.
So I think we need to move the definition of "perl_module" to some
other file which either already is or else can be included in
libaprext.lib, but I'm not sure where would be best right now.
I think moving it to different file is not possible. perl_module struct
contains pointers to methods which later call another methods which
really need all those symbols. So to define perl_module, you basically
need all that stuff included in mod_perl.h.
I think what you could do is to create dummy .c file and just add dummy
perl_module definition there. No source code mentioned above (in
libaprext.lib) actually needs perl_module, so it should be OK to do
that. You wouldn't be able to use perl_module properly from external
library anyway if I'm right.
It's not ideal way, but I'm not sure I see better solution. I've done
that in ModPerl::Const:
http://jkaluza.fedorapeople.org/mod_perl/0023-Define-perl_module-in-Const.xs.patch
When thinking about it, it's really strange we have problems with
perl_module in httpd24 branch, because that part of code didn't change
at all in httpd24 branch.
In trunk, the perl_module in mod_perl.h is declared as extern too and
the files used to link libaprext.lib are also the same. Maybe there are
different compler/linker flags in use when building with 2.4 causing
this behaviour?
I think that could be worth checking too.
Regards,
Jan Kaluza
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
For additional commands, e-mail: dev-h...@perl.apache.org
Regards,
Jan Kaluza
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
For additional commands, e-mail: dev-h...@perl.apache.org
