Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Steve Hay wrote: [...] Having a pointer to where the mod_perl.lib library was installed would be useful. I'm not sure calling it MODPERL_STATIC_LIB_LOCATION would be the best thing on Win32, as it's not a static library as such, but something could be come up with ... Well, if ModPerl::MM does the right thing, a developer will not even need to know where it is located. So probably leaving it as it's now is fine. The only misleading part is that MODPERL_LIB_LOCATION points to the build dir, so it should probably be renamed to reflect that. I'm not sure that's the *only* mis-leading part, but, as you say, if it all works then it shouldn't really matter too much. What other misleading parts are we talking about? The main thing is to get mod_perl.lib installed in the first place under mp1. I remember someone wanted to port ModPerl::MM to mp1, if that happens, than it'd become a non-issue as well ;) __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Stas Bekman wrote: Steve Hay wrote: [...] Having a pointer to where the mod_perl.lib library was installed would be useful. I'm not sure calling it MODPERL_STATIC_LIB_LOCATION would be the best thing on Win32, as it's not a static library as such, but something could be come up with ... Well, if ModPerl::MM does the right thing, a developer will not even need to know where it is located. So probably leaving it as it's now is fine. The only misleading part is that MODPERL_LIB_LOCATION points to the build dir, so it should probably be renamed to reflect that. I'm not sure that's the *only* mis-leading part, but, as you say, if it all works then it shouldn't really matter too much. What other misleading parts are we talking about? I'm just getting confused with changes in Apache itself, I think. Apache 1 used to have lib, libexec and modules: lib stored the static .lib's, libexec stored the import libraries for various dll's, and modules stored the .so (aka .dll) files for Apache modules. But with Apache 2, I have only lib and modules. The latter still (rightly) contains just the .so files for Apache modules, so presumably all the static *and* import libraries are thrown together into lib now? Now, my mp2's Apache::BuildConfig contains this: 'MODPERL_AP_LIBDIR' = 'C:\\apache2/lib', 'MODPERL_AP_LIBEXECDIR' = 'C:\\apache2/modules', which I find confusing. The first line there is fine, but the second line seems wrong. One would think that MODPERL_AP_LIBEXECDIR specifies where Apache's libexec directory is, but there isn't one any more! Furthermore, it seems that the files that would have been in it are now in lib? So maybe MODPERL_AP_LIBEXECDIR should say C:\\apache2/lib (that's an ugly mess of back- and forward slashes too), and that should be used as the location to install mod_perl.lib into (since mod_perl.lib is one of these import library things). That would be wrong as things stand, though, because MODPERL_AP_LIBEXECDIR seems to be used as the location to install mod_perl.so, which should indeed be C:\\apache2/modules. Perhaps the simplest thing would be to rename MODPERL_AP_LIBEXECDIR to MODPERL_AP_MODDIR since it specifies where Apache's modules directory is and there isn't a libexec anymore? - Steve
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Steve Hay wrote: [...] What other misleading parts are we talking about? I'm just getting confused with changes in Apache itself, I think. Apache 1 used to have lib, libexec and modules: lib stored the static .lib's, libexec stored the import libraries for various dll's, and modules stored the .so (aka .dll) files for Apache modules. But with Apache 2, I have only lib and modules. The latter still (rightly) contains just the .so files for Apache modules, so presumably all the static *and* import libraries are thrown together into lib now? Now, my mp2's Apache::BuildConfig contains this: 'MODPERL_AP_LIBDIR' = 'C:\\apache2/lib', 'MODPERL_AP_LIBEXECDIR' = 'C:\\apache2/modules', which I find confusing. The first line there is fine, but the second line seems wrong. One would think that MODPERL_AP_LIBEXECDIR specifies where Apache's libexec directory is, but there isn't one any more! Furthermore, it seems that the files that would have been in it are now in lib? So maybe MODPERL_AP_LIBEXECDIR should say C:\\apache2/lib (that's an ugly mess of back- and forward slashes too), and that should be used as the location to install mod_perl.lib into (since mod_perl.lib is one of these import library things). That would be wrong as things stand, though, because MODPERL_AP_LIBEXECDIR seems to be used as the location to install mod_perl.so, which should indeed be C:\\apache2/modules. Perhaps the simplest thing would be to rename MODPERL_AP_LIBEXECDIR to MODPERL_AP_MODDIR since it specifies where Apache's modules directory is and there isn't a libexec anymore? It's the problem with apxs then, since mp2 just uses the same names as apxs: ~/httpd/prefork/bin/apxs -q LIBEXECDIR /home/stas/httpd/prefork/modules ~/httpd/prefork/bin/apxs -q LIBDIR /home/stas/httpd/prefork/lib I'm not sure if we want to contradict apxs on that. My suggestion is to remove the need for developers to know about those dirs/vars and have it all abstracted behind ModPerl::MM (which already does most of it). If it gets ported to mp1 and uses the same API then no matter what happens behind the scenes it'll do the right thing for the developer. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Hi!
On Thu, Sep 11, 2003 at 10:24:20PM -0500, Randy Kobes wrote:
Here's a patch against the Apache-Dispatch Makefile.PL to
allow it to build on Win32 - I've also put up a ppm package
Oh, great! Thanks Randy! I'll put this into the next release, which should
happen in a few days...
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Randy Kobes wrote: On Thu, 11 Sep 2003, Geoffrey Young wrote: The problem you described before with the missing symbols can be resolved by linking against the mod_perl.lib built when you build mod_perl.so. This can be done by adding in a LIBS attribute to WriteMakefile() in Makefile.PL with a value of ' -L/Path/to/mod_perl_lib -lmod_perl'. ah, right. thanks randy. examples of this can be found in Apache::WinBitHack, for example, the format of which should probably go in Apache::Dispatch (as well as just about all Apache:: modules to make sure they are Win32 compliant :) Here's a patch against the Apache-Dispatch Makefile.PL to allow it to build on Win32 Your patch does the trick for me, except that I had to rebuild mod_perl too. The problem is that my installed mod_perl setup (Apache in C:\apache, Perl in C:\perl5) didn't contain the mod_perl.lib required. The MODPERL_LIB entry in Apache::MyConfig said C:/Temp/mod_perl-1.28/src/modules/win32/Release, which is, of course, where it was when I was building mod_perl. I believe that mod_perl 2 now installs the mod_perl.lib somewhere to solve that kind of problem. Is there an option in the mod_perl 1 build process to thave that library installed, or could that be added to the next release? Anyway, Apache::Dispatch is now up and running for me. Thanks, Randy! - Steve
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
On Fri, 12 Sep 2003, Steve Hay wrote: Randy Kobes wrote: [ .. ] Here's a patch against the Apache-Dispatch Makefile.PL to allow it to build on Win32 Your patch does the trick for me, except that I had to rebuild mod_perl too. The problem is that my installed mod_perl setup (Apache in C:\apache, Perl in C:\perl5) didn't contain the mod_perl.lib required. The MODPERL_LIB entry in Apache::MyConfig said C:/Temp/mod_perl-1.28/src/modules/win32/Release, which is, of course, where it was when I was building mod_perl. I believe that mod_perl 2 now installs the mod_perl.lib somewhere to solve that kind of problem. Is there an option in the mod_perl 1 build process to thave that library installed, or could that be added to the next release? That's a good suggestion - you're right that mod_perl 2 installs the mod_perl.lib under the Apache2/ tree, and it would make sense for mod_perl 1 to do the same, with Apache::MyConfig adjusted to reflect that. I'll look into putting together something to do that. -- best regards, randy
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Randy Kobes wrote:
On Fri, 12 Sep 2003, Steve Hay wrote:
Randy Kobes wrote:
[ .. ]
Here's a patch against the Apache-Dispatch Makefile.PL to
allow it to build on Win32
Your patch does the trick for me, except that I had to
rebuild mod_perl too.
The problem is that my installed mod_perl setup (Apache in
C:\apache, Perl in C:\perl5) didn't contain the
mod_perl.lib required. The MODPERL_LIB entry in
Apache::MyConfig said
C:/Temp/mod_perl-1.28/src/modules/win32/Release, which is,
of course, where it was when I was building mod_perl.
I believe that mod_perl 2 now installs the mod_perl.lib
somewhere to solve that kind of problem. Is there an
option in the mod_perl 1 build process to thave that
library installed, or could that be added to the next
release?
That's a good suggestion - you're right that mod_perl 2
installs the mod_perl.lib under the Apache2/ tree, and it
would make sense for mod_perl 1 to do the same, with
Apache::MyConfig adjusted to reflect that. I'll look into
putting together something to do that.
Does it? According to Apache::Build, it should be installed under the apache
tree's lib:
sub modperl_libs_MSWin32 {
my $self = shift;
# mod_perl.lib will be installed into MP_AP_PREFIX/lib
# for use by 3rd party xs modules
$self-{cwd}/src/modules/perl/$self-{MP_LIBNAME}.lib;
}
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Stas Bekman wrote: Randy Kobes wrote: On Fri, 12 Sep 2003, Steve Hay wrote: I believe that mod_perl 2 now installs the mod_perl.lib somewhere to solve that kind of problem. Is there an option in the mod_perl 1 build process to thave that library installed, or could that be added to the next release? That's a good suggestion - you're right that mod_perl 2 installs the mod_perl.lib under the Apache2/ tree, and it would make sense for mod_perl 1 to do the same, with Apache::MyConfig adjusted to reflect that. I'll look into putting together something to do that. Does it? According to Apache::Build, it should be installed under the apache tree's lib: Yes, in my Apache2 setup (the one that I can't get working with Perl 5.8.1...) I have mod_perl.lib in C:\Apache2\lib. I didn't change any of the installation locations. I'd assumed that's what Randy meant, actually - Apache2/lib being under the Apache2/ tree :-) Having said that, the BuildConfig.pm doesn't actually seem to refer to the location that the library has been installed into -- like mp1, it refers to the location in which it was built! I have: 'MODPERL_LIB_LOCATION' = 'C:/Temp/modperl-2.0/src/modules/perl/mod_perl.lib', in BuildConfig.pm. Wouldn't it be better for that to be 'C:/Apache2/lib/mod_perl.lib'? - Steve
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
On Fri, 12 Sep 2003, Stas Bekman wrote: Steve Hay wrote: Stas Bekman wrote: Randy Kobes wrote: On Fri, 12 Sep 2003, Steve Hay wrote: I believe that mod_perl 2 now installs the mod_perl.lib somewhere to solve that kind of problem. Is there an option in the mod_perl 1 build process to thave that library installed, or could that be added to the next release? That's a good suggestion - you're right that mod_perl 2 installs the mod_perl.lib under the Apache2/ tree, and it would make sense for mod_perl 1 to do the same, with Apache::MyConfig adjusted to reflect that. I'll look into putting together something to do that. Does it? According to Apache::Build, it should be installed under the apache tree's lib: Yes, in my Apache2 setup (the one that I can't get working with Perl 5.8.1...) I have mod_perl.lib in C:\Apache2\lib. I didn't change any of the installation locations. I'd assumed that's what Randy meant, actually - Apache2/lib being under the Apache2/ tree :-) what is mod_perl.lib? a static library? (I guess an equivalent of mod_perl.lo on unix). We don't install it on unix yet, but I think that for consistency it should go to the same place where mod_perl.so is installed to. Which is under the Apache tree. This mod_perl.lib (on Win32) isn't a true static library, containing all the symbol definitions; from what I understand, it just contains the minimal information on symbols needed to allow the application it's being linked with to find the symbols in the dynamic library (in this case, mod_perl.so). I put it under Apache2/lib/ because that's where the Apache2 libs (eg, apr.lib, libapr.lib, mod_dav.lib) are placed. The dynamic libraries are placed either under Apache2/modules/, if it's a module (eg, mod_dav.so), or under Apache2/bin/, such as libapr.dll. Having said that, the BuildConfig.pm doesn't actually seem to refer to the location that the library has been installed into -- like mp1, it refers to the location in which it was built! I have: 'MODPERL_LIB_LOCATION' = 'C:/Temp/modperl-2.0/src/modules/perl/mod_perl.lib', in BuildConfig.pm. Wouldn't it be better for that to be 'C:/Apache2/lib/mod_perl.lib'? Nope, it uses this attribute as a source dir in cp from to: $install .= 'EOI'; # install mod_perl.lib @$(MKPATH) $(MODPERL_AP_LIBDIR) $(MODPERL_TEST_F) $(MODPERL_LIB_LOCATION) \ $(MODPERL_CP) $(MODPERL_LIB_LOCATION) $(MODPERL_AP_LIBDIR) EOI And as you can see it should install the static lib under $(MODPERL_AP_LIBDIR) (which is under the apache tree) purhaps it should be fixed to have a more intuitive name then (s/MODPERL_LIB_LOCATION/MODPERL_LIB_SOURCE_LOCATION/?) or BUILD_LOCATION I'd suggest an even more intuitive: MODPERL_STATIC_LIB_BUILD_LOCATION, since it's a static lib. Purhaps adding a new var MODPERL_STATIC_LIB_LOCATION pointing to where the static lib was installed to will be useful. Having a pointer to where the mod_perl.lib library was installed would be useful. I'm not sure calling it MODPERL_STATIC_LIB_LOCATION would be the best thing on Win32, as it's not a static library as such, but something could be come up with ... -- best regards, randy
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Randy Kobes wrote: On Fri, 12 Sep 2003, Stas Bekman wrote: Steve Hay wrote: Stas Bekman wrote: Randy Kobes wrote: On Fri, 12 Sep 2003, Steve Hay wrote: I believe that mod_perl 2 now installs the mod_perl.lib somewhere to solve that kind of problem. Is there an option in the mod_perl 1 build process to thave that library installed, or could that be added to the next release? That's a good suggestion - you're right that mod_perl 2 installs the mod_perl.lib under the Apache2/ tree, and it would make sense for mod_perl 1 to do the same, with Apache::MyConfig adjusted to reflect that. I'll look into putting together something to do that. Does it? According to Apache::Build, it should be installed under the apache tree's lib: Yes, in my Apache2 setup (the one that I can't get working with Perl 5.8.1...) I have mod_perl.lib in C:\Apache2\lib. I didn't change any of the installation locations. I'd assumed that's what Randy meant, actually - Apache2/lib being under the Apache2/ tree :-) what is mod_perl.lib? a static library? (I guess an equivalent of mod_perl.lo on unix). We don't install it on unix yet, but I think that for consistency it should go to the same place where mod_perl.so is installed to. Which is under the Apache tree. This mod_perl.lib (on Win32) isn't a true static library, containing all the symbol definitions; from what I understand, it just contains the minimal information on symbols needed to allow the application it's being linked with to find the symbols in the dynamic library (in this case, mod_perl.so). I put it under Apache2/lib/ because that's where the Apache2 libs (eg, apr.lib, libapr.lib, mod_dav.lib) are placed. The dynamic libraries are placed either under Apache2/modules/, if it's a module (eg, mod_dav.so), or under Apache2/bin/, such as libapr.dll. Ah, so it's all cool. I have confused Apache2/ with perl's lib sub-directory. Having said that, the BuildConfig.pm doesn't actually seem to refer to the location that the library has been installed into -- like mp1, it refers to the location in which it was built! I have: 'MODPERL_LIB_LOCATION' = 'C:/Temp/modperl-2.0/src/modules/perl/mod_perl.lib', in BuildConfig.pm. Wouldn't it be better for that to be 'C:/Apache2/lib/mod_perl.lib'? Nope, it uses this attribute as a source dir in cp from to: $install .= 'EOI'; # install mod_perl.lib @$(MKPATH) $(MODPERL_AP_LIBDIR) $(MODPERL_TEST_F) $(MODPERL_LIB_LOCATION) \ $(MODPERL_CP) $(MODPERL_LIB_LOCATION) $(MODPERL_AP_LIBDIR) EOI And as you can see it should install the static lib under $(MODPERL_AP_LIBDIR) (which is under the apache tree) purhaps it should be fixed to have a more intuitive name then (s/MODPERL_LIB_LOCATION/MODPERL_LIB_SOURCE_LOCATION/?) or BUILD_LOCATION I'd suggest an even more intuitive: MODPERL_STATIC_LIB_BUILD_LOCATION, since it's a static lib. Purhaps adding a new var MODPERL_STATIC_LIB_LOCATION pointing to where the static lib was installed to will be useful. Having a pointer to where the mod_perl.lib library was installed would be useful. I'm not sure calling it MODPERL_STATIC_LIB_LOCATION would be the best thing on Win32, as it's not a static library as such, but something could be come up with ... Well, if ModPerl::MM does the right thing, a developer will not even need to know where it is located. So probably leaving it as it's now is fine. The only misleading part is that MODPERL_LIB_LOCATION points to the build dir, so it should probably be renamed to reflect that. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Hi!
On Thu, Sep 11, 2003 at 08:33:31AM +0100, Steve Hay wrote:
I posted this problem the other day, deep inside a thread about
something else, and didn't get any replies; maybe nobody spotted it?
Does anybody have Apache::Dispatch working on Windows with Perl 5.8.0?
Randy?
Randy posted this some time ago:
I just made one up, which you can install as
C:\ ppm install
http://theoryx5.uwinnipeg.ca/ppmpackages/Apache-Dispatch.ppd
Maybe this works for you?
See:
http://www.gossamer-threads.com/archive/mod_perl_C1/modperl_F7/Looking_for_Apache::Dispatch_PPD_P73122/
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Hi!
On Thu, Sep 11, 2003 at 08:59:23AM +0100, Steve Hay wrote:
I would rather be able to build the module myself anyway, rather than
using a PPM package.
I guess (and Geoffrey (who BTW transfered maintainership of Apache::Dispatch
to me..) suggested something) the problem lies within the custom configuration
directives used by Apache::Dispatch.
I'm planning to make these optional in the next release of Apache::Dispatch,
so you could either use
DispatchPrefix Bar
(which needs compiling)
or
PerlSetVar DispatchPrefix Bar
(which doesn't need compiling and should thus make installation easier)
BTW, do other people have it working under Perl 5.8.0 on other
platforms? I'm not sure if this problem is Windows-related or
5.8.0-related.
There is one FAIL reported on:
http://testers.cpan.org/show/Apache-Dispatch.html
I complied it without problem on Linux Perl 5.8.0 and 5.6.1.
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
On Thu, 11 Sep 2003, Steve Hay wrote: Thomas Klausner wrote: On Thu, Sep 11, 2003 at 08:33:31AM +0100, Steve Hay wrote: I posted this problem the other day, deep inside a thread about something else, and didn't get any replies; maybe nobody spotted it? Does anybody have Apache::Dispatch working on Windows with Perl 5.8.0? Randy? Randy posted this some time ago: I just made one up, which you can install as C:\ ppm install http://theoryx5.uwinnipeg.ca/ppmpackages/Apache-Dispatch.ppd Maybe this works for you? Sadly, no - that URL is now a 404. The directory there still exists, but there's no Apache-Dispatch.ppd in it. Sorry about that - that package apparently didn't survive a disc crash we had. I'll make up a new one and put it up there tonight. However, this will be for Perl-5.6.1, so won't be compatible with 5.8.0. I would rather be able to build the module myself anyway, rather than using a PPM package. The problem you described before with the missing symbols can be resolved by linking against the mod_perl.lib built when you build mod_perl.so. This can be done by adding in a LIBS attribute to WriteMakefile() in Makefile.PL with a value of ' -L/Path/to/mod_perl_lib -lmod_perl'. -- best regards, randy
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
The problem you described before with the missing symbols can be resolved by linking against the mod_perl.lib built when you build mod_perl.so. This can be done by adding in a LIBS attribute to WriteMakefile() in Makefile.PL with a value of ' -L/Path/to/mod_perl_lib -lmod_perl'. ah, right. thanks randy. examples of this can be found in Apache::WinBitHack, for example, the format of which should probably go in Apache::Dispatch (as well as just about all Apache:: modules to make sure they are Win32 compliant :) --Geoff
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
On Thu, 11 Sep 2003, Geoffrey Young wrote:
The problem you described before with the missing symbols
can be resolved by linking against the mod_perl.lib built
when you build mod_perl.so. This can be done by adding in
a LIBS attribute to WriteMakefile() in Makefile.PL with a
value of ' -L/Path/to/mod_perl_lib -lmod_perl'.
ah, right. thanks randy.
examples of this can be found in Apache::WinBitHack, for
example, the format of which should probably go in
Apache::Dispatch (as well as just about all Apache::
modules to make sure they are Win32 compliant :)
Here's a patch against the Apache-Dispatch Makefile.PL to
allow it to build on Win32 - I've also put up a ppm package
at http://theoryx5.uwinnipeg.ca/ppmpackages/ (for ActivePerl
6xx).
=
--- Makefile.PL.origWed Dec 27 09:01:04 2000
+++ Makefile.PL Thu Sep 11 22:16:00 2003
@@ -4,6 +4,9 @@
use Apache::ExtUtils qw(command_table);
use Apache::src ();
use strict;
+use Config;
+
+my $is_win32 = ($^O =~ /Win32/i);
require 5.005;
@@ -75,10 +78,26 @@
command_table([EMAIL PROTECTED]);
+my %config;
+
+$config{INC} = Apache::src-new-inc;
+
+if ($is_win32) {
+ require Apache::MyConfig;
+
+ $config{DEFINE} = ' -D_WINSOCK2API_ -D_MSWSOCK_ ';
+ $config{DEFINE} .= ' -D_INC_SIGNAL -D_INC_MALLOC '
+if $Config{usemultiplicity};
+
+ $config{LIBS} =
+qq{ -L$Apache::MyConfig::Setup{APACHE_LIB} -lApacheCore } .
+qq{ -L$Apache::MyConfig::Setup{MODPERL_LIB} -lmod_perl};
+}
+
WriteMakefile(
'NAME' = __PACKAGE__,
'VERSION_FROM' = 'Dispatch.pm',
- 'INC' = Apache::src-new-inc,
'PREREQ_PM'= { mod_perl = 1.2401, },
'clean'= { FILES = '*.xs*' },
+ %config,
);
--
best regards,
randy
