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
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: [...] 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: 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. 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. The main thing is to get mod_perl.lib installed in the first place under mp1. - Steve
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
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
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. 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. __ 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
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
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 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
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-:+-$"-g&&print$_.$/}
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
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, 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
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-:+-$"-g&&print$_.$/}
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Thomas Klausner wrote: 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? Sadly, no - that URL is now a 404. The directory there still exists, but there's no Apache-Dispatch.ppd in it. I would rather be able to build the module myself anyway, rather than using a PPM package. 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. - Steve
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-:+-$"-g&&print$_.$/}
Can't build Apache::Dispatch on Windows / Perl 5.8.0
Hi, 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? I'm trying to build it on Windows XP (MSVC++ 6) with Perl 5.8.0 / Apache 1.3.27 / mod_perl 1.28, but I get these errors: [...] link -out:blib\arch\auto\Apache\Dispatch\Dispatch.dll -dll -nologo -node faultlib -release -libpath:"C:\perl5\lib\CORE" -machine:x86 Dispatch.obj C:\ perl5\lib\CORE\perl58.lib libeay32.lib oldnames.lib kernel32.lib user32.lib gdi 32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.li b netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib o dbccp32.lib msvcrt.lib -def:Dispatch.def Creating library blib\arch\auto\Apache\Dispatch\Dispatch.lib and object blib\ arch\auto\Apache\Dispatch\Dispatch.exp Dispatch.obj : error LNK2001: unresolved external symbol _perl_perl_merge_dir_co nfig Dispatch.obj : error LNK2001: unresolved external symbol _perl_cmd_perl_TAKE1 Dispatch.obj : error LNK2001: unresolved external symbol __imp__ap_register_clea [EMAIL PROTECTED] Dispatch.obj : error LNK2001: unresolved external symbol _perl_perl_cmd_cleanup Dispatch.obj : error LNK2001: unresolved external symbol __imp__ap_null_cleanup Dispatch.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] Dispatch.obj : error LNK2001: unresolved external symbol _perl_clear_symtab Dispatch.obj : error LNK2001: unresolved external symbol __imp__ap_remove_module @4 Dispatch.obj : error LNK2001: unresolved external symbol __imp__ap_find_linked_m [EMAIL PROTECTED] Dispatch.obj : error LNK2001: unresolved external symbol _perl_get_startup_pool Dispatch.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] blib\arch\auto\Apache\Dispatch\Dispatch.dll : fatal error LNK1120: 11 unresolved externals NMAKE : fatal error U1077: 'link' : return code '0x460' Stop. Any ideas? - Steve