You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Steve Hay <st...@uk.radan.com> on 2003/09/11 09:33:31 UTC
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
nup@16
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 __imp__ap_palloc@8
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
odule@4
Dispatch.obj : error LNK2001: unresolved external symbol
_perl_get_startup_pool
Dispatch.obj : error LNK2001: unresolved external symbol
__imp__ap_add_module@4
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
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Posted by Thomas Klausner <do...@zsi.at>.
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
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org 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
Posted by Steve Hay <st...@uk.radan.com>.
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
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org 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
Posted by Steve Hay <st...@uk.radan.com>.
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
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
RE: Forking w/ mod_perl 2
Posted by "Cameron B. Prince" <cp...@rideware.com>.
Hi Richard,
> IMHO, it would be better to put your report code into another perl
> program and execute it. From what I see from your snippet of
> code, it's
> not important for the parent to know what the child is going, you are
> even ignoring SIGCHLD.
>
> Also, at some point in the future (I hope at least) mp2 +
> threaded mpm's
> will become more than alpha (although I already use it extensively but
> I'm crazy) and you might want to run you code in it. Forking under
> these circumstances would be a bad.
Thanks for you reply. The report code is in another perl program that I'm
trying to execute. The code I included below was from the v1 docs:
http://perl.apache.org/docs/1.0/guide/performance.html#Forking_and_Executing
_Subprocesses_from_mod_perl
Here is the code I ended up with:
$SIG{CHLD} = 'IGNORE';
defined (my $pid = fork) or die "Cannot fork: $!\n";
unless ($pid) {
exec $command;
CORE::exit(0);
}
This seems to work and no zombies are floating around. But I've not been
able to restart Apache while the forked program is running yet to see if
it's killed.
More comments or ideas welcome.
Thanks,
Cameron
>
> 2c
>
> On Fri, 2003-09-12 at 14:40, Cameron B. Prince wrote:
> > Hi all,
> >
> > I have a report creation perl script that takes about 15
> minutes to run and
> > I need to fork it. I tried the code from v1:
> >
> > use strict;
> > use POSIX 'setsid';
> > use Apache::SubProcess;
> >
> >
> > my = shift;
> > ->send_http_header("text/plain");
> >
> > {CHLD} = 'IGNORE';
> > defined (my = fork) or die "Cannot fork: \n";
> > if () {
> > print "Parent 25481 has finished, kid's PID: \n";
> > } else {
> > ->cleanup_for_exec(); # untie the socket
> > chdir '/' or die "Can't chdir to /: ";
> > open STDIN, '/dev/null' or die "Can't read /dev/null: ";
> > open STDOUT, '>/dev/null'
> > or die "Can't write to /dev/null: ";
> > open STDERR, '>/tmp/log' or die "Can't write to /tmp/log: ";
> > setsid or die "Can't start a new session: ";
> >
> > select STDERR;
> > local $| = 1;
> > warn "started\n";
> > # do something time-consuming
> > sleep 1, warn "sh\n" for 1..20;
> > warn "completed\n";
> >
> > CORE::exit(0); # terminate the process
> > }
> >
> >
> > First problem, Apache::SubProcess doesn't seem to contain
> those methods
> > anymore.
> > Second problem is open.
> >
> > Can anyone tell me the proper way to fork with v2?
> >
> > Thanks,
> > Cameron
> --
> Richard F. Rebel
> rrebel@whenu.com
> t. 212.239.0000
>
Re: Forking w/ mod_perl 2
Posted by "Richard F. Rebel" <rr...@whenu.com>.
IMHO, it would be better to put your report code into another perl
program and execute it. From what I see from your snippet of code, it's
not important for the parent to know what the child is going, you are
even ignoring SIGCHLD.
Also, at some point in the future (I hope at least) mp2 + threaded mpm's
will become more than alpha (although I already use it extensively but
I'm crazy) and you might want to run you code in it. Forking under
these circumstances would be a bad.
2c
On Fri, 2003-09-12 at 14:40, Cameron B. Prince wrote:
> Hi all,
>
> I have a report creation perl script that takes about 15 minutes to run and
> I need to fork it. I tried the code from v1:
>
> use strict;
> use POSIX 'setsid';
> use Apache::SubProcess;
>
>
> my = shift;
> ->send_http_header("text/plain");
>
> {CHLD} = 'IGNORE';
> defined (my = fork) or die "Cannot fork: \n";
> if () {
> print "Parent 25481 has finished, kid's PID: \n";
> } else {
> ->cleanup_for_exec(); # untie the socket
> chdir '/' or die "Can't chdir to /: ";
> open STDIN, '/dev/null' or die "Can't read /dev/null: ";
> open STDOUT, '>/dev/null'
> or die "Can't write to /dev/null: ";
> open STDERR, '>/tmp/log' or die "Can't write to /tmp/log: ";
> setsid or die "Can't start a new session: ";
>
> select STDERR;
> local $| = 1;
> warn "started\n";
> # do something time-consuming
> sleep 1, warn "sh\n" for 1..20;
> warn "completed\n";
>
> CORE::exit(0); # terminate the process
> }
>
>
> First problem, Apache::SubProcess doesn't seem to contain those methods
> anymore.
> Second problem is open.
>
> Can anyone tell me the proper way to fork with v2?
>
> Thanks,
> Cameron
--
Richard F. Rebel
rrebel@whenu.com
t. 212.239.0000
Forking w/ mod_perl 2
Posted by "Cameron B. Prince" <cp...@rideware.com>.
Hi all,
I have a report creation perl script that takes about 15 minutes to run and
I need to fork it. I tried the code from v1:
use strict;
use POSIX 'setsid';
use Apache::SubProcess;
my = shift;
->send_http_header("text/plain");
{CHLD} = 'IGNORE';
defined (my = fork) or die "Cannot fork: \n";
if () {
print "Parent 25481 has finished, kid's PID: \n";
} else {
->cleanup_for_exec(); # untie the socket
chdir '/' or die "Can't chdir to /: ";
open STDIN, '/dev/null' or die "Can't read /dev/null: ";
open STDOUT, '>/dev/null'
or die "Can't write to /dev/null: ";
open STDERR, '>/tmp/log' or die "Can't write to /tmp/log: ";
setsid or die "Can't start a new session: ";
select STDERR;
local $| = 1;
warn "started\n";
# do something time-consuming
sleep 1, warn "sh\n" for 1..20;
warn "completed\n";
CORE::exit(0); # terminate the process
}
First problem, Apache::SubProcess doesn't seem to contain those methods
anymore.
Second problem is open.
Can anyone tell me the proper way to fork with v2?
Thanks,
Cameron
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org 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
Posted by Steve Hay <st...@uk.radan.com>.
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
Posted by Stas Bekman <st...@stason.org>.
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 Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org 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
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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: [mp1] win32 Makefile.PL patch
Posted by Steve Hay <st...@uk.radan.com>.
Randy Kobes wrote:
>In a thread on the mod_perl list about building
>Apache::Dispatch on Win32 using mod_perl 1, Steve raised the
>point about the entry in Apache::MyConfig pointing to
>mod_perl.lib referred to the source location. For building
>3rd party modules, it would be more convenient if
>mod_perl.lib was, first of all, installed into the Apache/
>tree, and secondly, if Apache::MyConfig pointed rather to
>this location. The patch below to the current cvs
>Makefile.PL carries this out. In order to do this, I dropped
>support for being able to build mod_perl on Win32 using an
>Apache source tree, and instead now demand that APACHE_SRC
>point to an installed Apache/ directory (which it could
>before) - otherwise, the logic of trying to figure out where
>to put what becomes pretty involved. I've also dropped
>support for Apache versions that use ApacheModulePerl.dll as
>the name of the mod_perl library, rather than mod_perl.so -
>these are quite old Apache versions, and shouldn't be used
>especially on Win32 due to security holes. If this patch is
>OK, I'll make sure to specify these in the Changes and
>INSTALL.win32 files.
>
>Steve, if you get a chance, could you try this patch
>out to see if it works for you? Thanks.
>
Yes, this patch works OK for me using the command-line:
perl Makefile.PL APACHE_SRC=C:/apache INSTALL_DLL=C:/apache/modules EAPI
However, in the light of subsequent discussions I guess you'll be
putting together a new patch?
- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp1] win32 Makefile.PL patch
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 15 Sep 2003, Steve Hay wrote:
> Randy Kobes wrote:
>
> >Having an APACHE_INST would be a good idea, as it's then
> >more intuitive of what it represents ... Perhaps a
> >combination of APACHE_INST and INSTALL_LIB would be
> >good, in order to keep the flavour of the current
> >build procedure:
> >
> >- APACHE_INST: the Apache install directory,
> > or
> >- APACHE_SRC, which can be either the Apache build or
> >install directory,
> >
> >With this,
> >- INSTALL_DLL: where to put mod_perl.so. If not given,
> >defaults to APACHE_INST/modules, or to APACHE_SRC/modules,
> >if these exist;
> >- INSTALL_LIB: where to put mod_perl.lib. If not given,
> >defaults to APACHE_INST/libexec, or to APACHE_SRC/libexec,
> >if these exist;
> >
> >In Apache::MyConfig, the location of the mod_perl lib would
> >then be the value of INSTALL_LIB, if that exists or was set;
> >if not, then it would stay at the current value of the
> >mod_perl source location.
> >
> This all sounds excellent.
>
> >
> >As for the location of the mod_perl header files in
> >Apache::MyConfig, right now for Win32 they're set as
> >/Path/to/mod_perl/sources/src/modules/perl. One instead
> >could use Apache::src->new->inc, which gives the installed
> >path (under the Perl tree). However, this wouldn't be a
> >compatible change with the current behaviour, as
> >Apache::src->new->inc is a string including the '-I' before
> >the directories, so that it can be used directly in a $(CC)
> >command. But I think it would be more convenient to use
> >Apache::src->new->inc, for the same reason as specifying an
> >installed location for the mod_perl.lib - that way, people
> >can delete the mod_perl build directory after installation.
> >What does this sound like?
> >
> >
> Setting MODPERL_INC to the installed location rather than the build
> location certainly makes a lot of sense. A definite thumbs-up to that.
>
> But I'm not so sure about introducing the '-I' if that breaks backwards
> compatibility. Depends how much you think people would be affected by
> it; I don't really know.
>
> Would it be possible to play it safe, and set MODPERL_INC to the
> installed location, but without the '-I's?
That would be possible, and probably preferable; however,
there'd still be a change in what to expect for MODPERL_INC.
Right now, being the value of src/modules/perl in the
mod_perl source location, it's a single value, but if one
uses Apache::src->new->inc, it'd become multiple values.
So, even if we stripped off the '-I's, the syntax
-I$Apache::MyConfig{MODPERL_INC}
(which works now) would break.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp1] win32 Makefile.PL patch
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Fri, 26 Sep 2003, Stas Bekman wrote:
>
>
>>I fail to apply this patch because of the tabs. Randy, can
>>you please post it as an attachment? we need to get rid of
>>the tabs next.
>
>
> Sorry about that - it's attached here.
Thanks Randy. It's not your fault. There should have been no tabs in that file
in first place. The perl source suffers from the same problem. And I always
have to remember to inline and attach my perl patches ;( Hopefully we will
keep the mp2 source nice and clean ;)
I tested that everything builds and passes the tests on linux (the usual set
of about 10 or so perl builds), so go ahead and commit it. Though please
remember to update Changes (usually it's a good idea to do that along with the
patch, so you won't forget to update it ;). And I'm sure you will update the
win32 docs as well, besides the INSTALL.win32 file ;)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp1] win32 Makefile.PL patch
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 26 Sep 2003, Stas Bekman wrote:
> I fail to apply this patch because of the tabs. Randy, can
> you please post it as an attachment? we need to get rid of
> the tabs next.
Sorry about that - it's attached here.
--
best regards,
randy
Re: [mp1] win32 Makefile.PL patch
Posted by Stas Bekman <st...@stason.org>.
I fail to apply this patch because of the tabs. Randy, can you please post it
as an attachment? we need to get rid of the tabs next.
patch -p0 < ../d/patch
patching file Makefile.PL
Hunk #2 succeeded at 376 with fuzz 1.
Hunk #4 FAILED at 1378.
Hunk #5 FAILED at 2160.
2 out of 6 hunks FAILED -- saving rejects to file Makefile.PL.rej
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp1] win32 Makefile.PL patch
Posted by Steve Hay <st...@uk.radan.com>.
Randy Kobes wrote:
>So, the patch below keeps backwards compatibility, and
>adds an INSTALL_LIB capability to 'perl Makefile.PL' to
>point to where to install mod_perl.lib, if it can't
>find the location in the installed Apache tree.
>
Sounds fair enough to me -- add the extra feature that we wanted, and
just play it safe backwards-compatibility-wise.
I've test your patch (below) and it works a treat -- Perl 5.8.0 and
5.8.1, with Apache 1.3.27 / mod_perl 1.28_01-dev. Thanks!
There is one other installation oddity that I've noticed for a while now
(it's not new), but never had time to look at properly. I find that running
perl Makefile.PL APACHE_SRC=C:/apache EAPI
(where C:/apache is my Apache installation directory) puts a 4kB file
called "perl" into C:/apache/modules. It looks like this is the typemap
file from the mp1 build tree's "Apache" sub-directory, which also gets
copied into src/modules/perl.
I think it is Makefile.PL's setup_for_static() that copies it there.
Why does it do that? We don't need it there do we?
- Steve
>================================================================
>Index: Makefile.PL
>===================================================================
>RCS file: /home/cvs/modperl/Makefile.PL,v
>retrieving revision 1.216
>diff -u -r1.216 Makefile.PL
>--- Makefile.PL 19 Aug 2003 05:07:44 -0000 1.216
>+++ Makefile.PL 25 Sep 2003 23:57:45 -0000
>@@ -330,7 +330,8 @@
>
> my $vcpp = ($Config{cc} =~ /^cl(\.exe)?$/);
> my %win32_args;
>-my %win32_accept = map {$_ => 1} qw(APACHE_SRC INSTALL_DLL DEBUG EAPI);
>+my %win32_accept = map {$_ => 1}
>+ qw(APACHE_SRC INSTALL_DLL INSTALL_LIB DEBUG EAPI);
>
> while($_ = shift) {
> ($k,$v) = split /=/, $_, 2;
>@@ -375,6 +376,10 @@
> my $w32_ap_mod = $fixed_apsrc . '/modules';
> $win32_args{INSTALL_DLL} = $w32_ap_mod if -d $w32_ap_mod;
> }
>+ unless ($win32_args{INSTALL_LIB}) {
>+ my $w32_ap_lib = $fixed_apsrc . '/libexec';
>+ $win32_args{INSTALL_LIB} = $w32_ap_lib if -d $w32_ap_lib;
>+ }
> }
>
> my %very_experimental = map {$_,1}
>@@ -1341,7 +1346,8 @@
> if($USE_APXS) {
> $add = "apxs_install";
> }
>- elsif ($win32_auto and $win32_args{INSTALL_DLL}) {
>+ elsif ($win32_auto and
>+ ($win32_args{INSTALL_DLL} or $win32_args{INSTALL_LIB})) {
> $add = 'amp_install';
> }
> elsif($USE_APACI) {
>@@ -1372,12 +1378,11 @@
> $win32_args{INSTALL_DLL} .
> ($win32_args{APACHE_VERS} < 1315 ?
> '/ApacheModulePerl.dll' : '/mod_perl.so');
>- if (-d "$win32_args{APACHE_SRC}/libexec") {
>- my $libexec = win32_fix_path($win32_args{APACHE_SRC}) . '/libexec';
>- $string .= sprintf qq{\n\t\$(CP) "%s" "%s"},
>- "$win32_path{MODPERL_LIB}/mod_perl.lib",
>- $libexec . '/mod_perl.lib';
>- }
>+ }
>+ if ($win32_args{INSTALL_LIB}) {
>+ $string .= sprintf qq{\n\t\$(CP) "%s" "%s"},
>+ "$win32_path{MODPERL_LIB}/mod_perl.lib",
>+ $win32_args{INSTALL_LIB} . '/mod_perl.lib';
> }
> return $string;
> }
>@@ -2155,7 +2160,7 @@
>
> if ($win32_args{INSTALL_DLL} ) {
> $win32_args{INSTALL_DLL} =
>- win32_fix_path($win32_args{INSTALL_DLL});
>+ win32_fix_path($win32_args{INSTALL_DLL});
> unless ( -d $win32_args{INSTALL_DLL}) {
> my @dirs = grep {-d}
> ('\Program Files\Apache Group\Apache\modules',
>@@ -2170,6 +2175,28 @@
>
> **** The Apache/modules directory was not found. *******
> **** Please install mod_perl.so manually. *******
>+
>+END
>+ }
>+ }
>+ }
>+ if ($win32_args{INSTALL_LIB} ) {
>+ $win32_args{INSTALL_LIB} =
>+ win32_fix_path($win32_args{INSTALL_LIB});
>+ unless ( -d $win32_args{INSTALL_LIB}) {
>+ my @dirs = grep {-d}
>+ ('\Program Files\Apache Group\Apache\libexec',
>+ '\Apache\libexec', '\Program Files\Apache\libexec');
>+ $win32_args{INSTALL_LIB} = find_dir(\@dirs, 'Apache/libexec');
>+ if ($win32_args{INSTALL_LIB} and -d $win32_args{INSTALL_LIB}) {
>+ $win32_args{INSTALL_LIB} =
>+ win32_fix_path($win32_args{INSTALL_LIB});
>+ }
>+ else {
>+ print <<'END';
>+
>+**** The Apache/libexec directory was not found. *******
>+**** Please install mod_perl.lib manually. *******
>
> END
> }
>Index: INSTALL.win32
>===================================================================
>RCS file: /home/cvs/modperl/INSTALL.win32,v
>retrieving revision 1.10
>diff -u -r1.10 INSTALL.win32
>--- INSTALL.win32 6 Jul 2003 13:42:56 -0000 1.10
>+++ INSTALL.win32 25 Sep 2003 23:57:45 -0000
>@@ -131,6 +131,12 @@
> (eg, \Apache\modules). If not given, a value of APACHE_SRC\modules
> will be used, if this directory exists.
>
>+=item INSTALL_LIB
>+
>+This gives the location of where to install mod_perl.lib
>+(eg, \Apache\libexec). If not given, a value of APACHE_SRC\libexec
>+will be used, if this directory exists.
>+
> =item DEBUG
>
> If true (DEBUG=1), a Debug version will be built (this assumes
>===================================================================
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp1] win32 Makefile.PL patch
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 15 Sep 2003, Steve Hay wrote:
> Randy Kobes wrote:
>
> >Having an APACHE_INST would be a good idea, as it's then
> >more intuitive of what it represents ... Perhaps a
> >combination of APACHE_INST and INSTALL_LIB would be
> >good, in order to keep the flavour of the current
> >build procedure:
> >
> >- APACHE_INST: the Apache install directory,
> > or
> >- APACHE_SRC, which can be either the Apache build or
> >install directory,
> >
> >With this,
> >- INSTALL_DLL: where to put mod_perl.so. If not given,
> >defaults to APACHE_INST/modules, or to APACHE_SRC/modules,
> >if these exist;
> >- INSTALL_LIB: where to put mod_perl.lib. If not given,
> >defaults to APACHE_INST/libexec, or to APACHE_SRC/libexec,
> >if these exist;
In the interests of not introducing another layer of
complexity, in the patch below I just added an INSTALL_LIB -
the INSTALL.win32 docs point out that APACHE_SRC can either
be the Apache source directory or the Apache install
directory, so APACHE_INST is a bit redundant (although
more descriptive). And like the installation of mod_perl.so,
which defaults to APACHE_SRC/modules (if this exists) if
INSTALL_DLL isn't given, mod_perl.lib will get installed
to APACHE_SRC/libexec (if this exists) if INSTALL_LIB isn't
given.
> >
> >In Apache::MyConfig, the location of the mod_perl lib would
> >then be the value of INSTALL_LIB, if that exists or was set;
> >if not, then it would stay at the current value of the
> >mod_perl source location.
> >
> This all sounds excellent.
> >
> >As for the location of the mod_perl header files in
> >Apache::MyConfig, right now for Win32 they're set as
> >/Path/to/mod_perl/sources/src/modules/perl. One instead
> >could use Apache::src->new->inc, which gives the installed
> >path (under the Perl tree). However, this wouldn't be a
> >compatible change with the current behaviour, as
> >Apache::src->new->inc is a string including the '-I' before
> >the directories, so that it can be used directly in a $(CC)
> >command. But I think it would be more convenient to use
> >Apache::src->new->inc, for the same reason as specifying an
> >installed location for the mod_perl.lib - that way, people
> >can delete the mod_perl build directory after installation.
> >What does this sound like?
> >
> >
> Setting MODPERL_INC to the installed location rather than the build
> location certainly makes a lot of sense. A definite thumbs-up to that.
>
> But I'm not so sure about introducing the '-I' if that breaks backwards
> compatibility. Depends how much you think people would be affected by
> it; I don't really know.
>
> Would it be possible to play it safe, and set MODPERL_INC to the
> installed location, but without the '-I's?
The values of MODPERL_LIB and MODPERL_INC in
Apache::MyConfig I ended up leaving alone, as changing them
now will break compatibility. Using Apache::src->new->inc
for MODPERL_INC (which would be the installed header
location) would be more convenient, but has the '-I'
switches already in it, and removing them would leave you
with a list of directories - both options would present
different behaviour to the current one. Changing MODPERL_LIB
to the installed directory, while more convenient, would
also break compatibility, as with the current MODPERL_LIB
both mod_perl.so and mod_perl.lib are present in that
directory, which isn't the case with the installed
directories.
If one wants to use the installed locations, one can use
Apache::src->new->inc, rather than MODPERL_INC from
Apache::MyConfig, for the headers, and then use
APACHE_LIB, rather than MODPERL_LIB, for the libraries.
So, the patch below keeps backwards compatibility, and
adds an INSTALL_LIB capability to 'perl Makefile.PL' to
point to where to install mod_perl.lib, if it can't
find the location in the installed Apache tree.
================================================================
Index: Makefile.PL
===================================================================
RCS file: /home/cvs/modperl/Makefile.PL,v
retrieving revision 1.216
diff -u -r1.216 Makefile.PL
--- Makefile.PL 19 Aug 2003 05:07:44 -0000 1.216
+++ Makefile.PL 25 Sep 2003 23:57:45 -0000
@@ -330,7 +330,8 @@
my $vcpp = ($Config{cc} =~ /^cl(\.exe)?$/);
my %win32_args;
-my %win32_accept = map {$_ => 1} qw(APACHE_SRC INSTALL_DLL DEBUG EAPI);
+my %win32_accept = map {$_ => 1}
+ qw(APACHE_SRC INSTALL_DLL INSTALL_LIB DEBUG EAPI);
while($_ = shift) {
($k,$v) = split /=/, $_, 2;
@@ -375,6 +376,10 @@
my $w32_ap_mod = $fixed_apsrc . '/modules';
$win32_args{INSTALL_DLL} = $w32_ap_mod if -d $w32_ap_mod;
}
+ unless ($win32_args{INSTALL_LIB}) {
+ my $w32_ap_lib = $fixed_apsrc . '/libexec';
+ $win32_args{INSTALL_LIB} = $w32_ap_lib if -d $w32_ap_lib;
+ }
}
my %very_experimental = map {$_,1}
@@ -1341,7 +1346,8 @@
if($USE_APXS) {
$add = "apxs_install";
}
- elsif ($win32_auto and $win32_args{INSTALL_DLL}) {
+ elsif ($win32_auto and
+ ($win32_args{INSTALL_DLL} or $win32_args{INSTALL_LIB})) {
$add = 'amp_install';
}
elsif($USE_APACI) {
@@ -1372,12 +1378,11 @@
$win32_args{INSTALL_DLL} .
($win32_args{APACHE_VERS} < 1315 ?
'/ApacheModulePerl.dll' : '/mod_perl.so');
- if (-d "$win32_args{APACHE_SRC}/libexec") {
- my $libexec = win32_fix_path($win32_args{APACHE_SRC}) . '/libexec';
- $string .= sprintf qq{\n\t\$(CP) "%s" "%s"},
- "$win32_path{MODPERL_LIB}/mod_perl.lib",
- $libexec . '/mod_perl.lib';
- }
+ }
+ if ($win32_args{INSTALL_LIB}) {
+ $string .= sprintf qq{\n\t\$(CP) "%s" "%s"},
+ "$win32_path{MODPERL_LIB}/mod_perl.lib",
+ $win32_args{INSTALL_LIB} . '/mod_perl.lib';
}
return $string;
}
@@ -2155,7 +2160,7 @@
if ($win32_args{INSTALL_DLL} ) {
$win32_args{INSTALL_DLL} =
- win32_fix_path($win32_args{INSTALL_DLL});
+ win32_fix_path($win32_args{INSTALL_DLL});
unless ( -d $win32_args{INSTALL_DLL}) {
my @dirs = grep {-d}
('\Program Files\Apache Group\Apache\modules',
@@ -2170,6 +2175,28 @@
**** The Apache/modules directory was not found. *******
**** Please install mod_perl.so manually. *******
+
+END
+ }
+ }
+ }
+ if ($win32_args{INSTALL_LIB} ) {
+ $win32_args{INSTALL_LIB} =
+ win32_fix_path($win32_args{INSTALL_LIB});
+ unless ( -d $win32_args{INSTALL_LIB}) {
+ my @dirs = grep {-d}
+ ('\Program Files\Apache Group\Apache\libexec',
+ '\Apache\libexec', '\Program Files\Apache\libexec');
+ $win32_args{INSTALL_LIB} = find_dir(\@dirs, 'Apache/libexec');
+ if ($win32_args{INSTALL_LIB} and -d $win32_args{INSTALL_LIB}) {
+ $win32_args{INSTALL_LIB} =
+ win32_fix_path($win32_args{INSTALL_LIB});
+ }
+ else {
+ print <<'END';
+
+**** The Apache/libexec directory was not found. *******
+**** Please install mod_perl.lib manually. *******
END
}
Index: INSTALL.win32
===================================================================
RCS file: /home/cvs/modperl/INSTALL.win32,v
retrieving revision 1.10
diff -u -r1.10 INSTALL.win32
--- INSTALL.win32 6 Jul 2003 13:42:56 -0000 1.10
+++ INSTALL.win32 25 Sep 2003 23:57:45 -0000
@@ -131,6 +131,12 @@
(eg, \Apache\modules). If not given, a value of APACHE_SRC\modules
will be used, if this directory exists.
+=item INSTALL_LIB
+
+This gives the location of where to install mod_perl.lib
+(eg, \Apache\libexec). If not given, a value of APACHE_SRC\libexec
+will be used, if this directory exists.
+
=item DEBUG
If true (DEBUG=1), a Debug version will be built (this assumes
===================================================================
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp1] win32 Makefile.PL patch
Posted by Steve Hay <st...@uk.radan.com>.
Randy Kobes wrote:
>Having an APACHE_INST would be a good idea, as it's then
>more intuitive of what it represents ... Perhaps a
>combination of APACHE_INST and INSTALL_LIB would be
>good, in order to keep the flavour of the current
>build procedure:
>
>- APACHE_INST: the Apache install directory,
> or
>- APACHE_SRC, which can be either the Apache build or
>install directory,
>
>With this,
>- INSTALL_DLL: where to put mod_perl.so. If not given,
>defaults to APACHE_INST/modules, or to APACHE_SRC/modules,
>if these exist;
>- INSTALL_LIB: where to put mod_perl.lib. If not given,
>defaults to APACHE_INST/libexec, or to APACHE_SRC/libexec,
>if these exist;
>
>In Apache::MyConfig, the location of the mod_perl lib would
>then be the value of INSTALL_LIB, if that exists or was set;
>if not, then it would stay at the current value of the
>mod_perl source location.
>
This all sounds excellent.
>
>As for the location of the mod_perl header files in
>Apache::MyConfig, right now for Win32 they're set as
>/Path/to/mod_perl/sources/src/modules/perl. One instead
>could use Apache::src->new->inc, which gives the installed
>path (under the Perl tree). However, this wouldn't be a
>compatible change with the current behaviour, as
>Apache::src->new->inc is a string including the '-I' before
>the directories, so that it can be used directly in a $(CC)
>command. But I think it would be more convenient to use
>Apache::src->new->inc, for the same reason as specifying an
>installed location for the mod_perl.lib - that way, people
>can delete the mod_perl build directory after installation.
>What does this sound like?
>
>
Setting MODPERL_INC to the installed location rather than the build
location certainly makes a lot of sense. A definite thumbs-up to that.
But I'm not so sure about introducing the '-I' if that breaks backwards
compatibility. Depends how much you think people would be affected by
it; I don't really know.
Would it be possible to play it safe, and set MODPERL_INC to the
installed location, but without the '-I's?
- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp1] win32 Makefile.PL patch
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 15 Sep 2003, Steve Hay wrote:
> Randy Kobes wrote:
>
> >On Sat, 13 Sep 2003, Stas Bekman wrote:
> >
> >[ ... ]
> >>So what I was saying is that we probably need to continue
> >>building *mod_perl* as before, however make mod_perl.lib
> >>and anything else needed available under the Apache source
> >>tree (or I think under the perl lib tree for mp1, since
> >>that's where we keep all our mp stuff). Does it make
> >>sense?
> >
> >Yes, that does ... We could put it under the perl tree
> >(that's where the mp1 header files go now), for example,
> >under $Config{installsitearch}/auto/mod_perl/, and then
> >record that in Apache::MyConfig. Alternatively, as with
> >mod_perl.so, we could let the user specify the location via
> >a Makefile.PL INSTALL_LIB flag (analagous to Win32's
> >INSTALL_DLL), and if this is not given, set it to be under
> >APACHE_SRC/libexec, if this exists (ie, the user has given
> >the Apache installation directory for APACHE_SRC).
> >Preferences?
> >
> I think installing mod_perl.lib somewhere under the Apache installation
> tree, rather than the Perl tree, makes more sense because it is the
> import library for mod_perl.so (aka mod_perl.dll), which, of course, is
> typically placed under the Apache tree (in the "modules"
> sub-directory). Apache's "libexec" sub-directory, where other import
> libraries are located, seems the best place to put it.
>
> The command-line that I normally use is:
>
> perl Makefile.PL APACHE_SRC=C:/apache INSTALL_DLL=C:/apache/modules EAPI
>
> (Where C:/apache is an *installed* Apache tree, which, after all,
> contains all the "source" necessary -- headers and libraries.) So,
> using your suggestion above, I would just need to make that:
>
> perl Makefile.PL APACHE_SRC=C:/apache INSTALL_DLL=C:/apache/modules
> INSTALL_LIB=C:/apache/libexec EAPI
>
> yes?
>
> It would be nice to be able to shortcut that to something like:
>
> perl Makefile.PL APACHE_INST=C:/apache EAPI
>
> The Apache installation specified is used to find the necessary headers
> and libraries, and as the location to install things into (under
> "modules" and "libexec").
>
> If that's too radical, then just your APACHE_LIB would be fine.
Having an APACHE_INST would be a good idea, as it's then
more intuitive of what it represents ... Perhaps a
combination of APACHE_INST and INSTALL_LIB would be
good, in order to keep the flavour of the current
build procedure:
- APACHE_INST: the Apache install directory,
or
- APACHE_SRC, which can be either the Apache build or
install directory,
With this,
- INSTALL_DLL: where to put mod_perl.so. If not given,
defaults to APACHE_INST/modules, or to APACHE_SRC/modules,
if these exist;
- INSTALL_LIB: where to put mod_perl.lib. If not given,
defaults to APACHE_INST/libexec, or to APACHE_SRC/libexec,
if these exist;
In Apache::MyConfig, the location of the mod_perl lib would
then be the value of INSTALL_LIB, if that exists or was set;
if not, then it would stay at the current value of the
mod_perl source location.
As for the location of the mod_perl header files in
Apache::MyConfig, right now for Win32 they're set as
/Path/to/mod_perl/sources/src/modules/perl. One instead
could use Apache::src->new->inc, which gives the installed
path (under the Perl tree). However, this wouldn't be a
compatible change with the current behaviour, as
Apache::src->new->inc is a string including the '-I' before
the directories, so that it can be used directly in a $(CC)
command. But I think it would be more convenient to use
Apache::src->new->inc, for the same reason as specifying an
installed location for the mod_perl.lib - that way, people
can delete the mod_perl build directory after installation.
What does this sound like?
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp1] win32 Makefile.PL patch
Posted by Steve Hay <st...@uk.radan.com>.
Randy Kobes wrote:
>On Sat, 13 Sep 2003, Stas Bekman wrote:
>
>[ ... ]
>
>
>>So what I was saying is that we probably need to continue
>>building *mod_perl* as before, however make mod_perl.lib
>>and anything else needed available under the Apache source
>>tree (or I think under the perl lib tree for mp1, since
>>that's where we keep all our mp stuff). Does it make
>>sense?
>>
>>
>
>Yes, that does ... We could put it under the perl tree
>(that's where the mp1 header files go now), for example,
>under $Config{installsitearch}/auto/mod_perl/, and then
>record that in Apache::MyConfig. Alternatively, as with
>mod_perl.so, we could let the user specify the location via
>a Makefile.PL INSTALL_LIB flag (analagous to Win32's
>INSTALL_DLL), and if this is not given, set it to be under
>APACHE_SRC/libexec, if this exists (ie, the user has given
>the Apache installation directory for APACHE_SRC).
>Preferences?
>
I think installing mod_perl.lib somewhere under the Apache installation
tree, rather than the Perl tree, makes more sense because it is the
import library for mod_perl.so (aka mod_perl.dll), which, of course, is
typically placed under the Apache tree (in the "modules"
sub-directory). Apache's "libexec" sub-directory, where other import
libraries are located, seems the best place to put it.
The command-line that I normally use is:
perl Makefile.PL APACHE_SRC=C:/apache INSTALL_DLL=C:/apache/modules EAPI
(Where C:/apache is an *installed* Apache tree, which, after all,
contains all the "source" necessary -- headers and libraries.) So,
using your suggestion above, I would just need to make that:
perl Makefile.PL APACHE_SRC=C:/apache INSTALL_DLL=C:/apache/modules
INSTALL_LIB=C:/apache/libexec EAPI
yes?
It would be nice to be able to shortcut that to something like:
perl Makefile.PL APACHE_INST=C:/apache EAPI
The Apache installation specified is used to find the necessary headers
and libraries, and as the location to install things into (under
"modules" and "libexec").
If that's too radical, then just your APACHE_LIB would be fine.
- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp1] win32 Makefile.PL patch
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Sat, 13 Sep 2003, Stas Bekman wrote:
>
> [ ... ]
>
>>So what I was saying is that we probably need to continue
>>building *mod_perl* as before, however make mod_perl.lib
>>and anything else needed available under the Apache source
>>tree (or I think under the perl lib tree for mp1, since
>>that's where we keep all our mp stuff). Does it make
>>sense?
>
>
> Yes, that does ... We could put it under the perl tree
> (that's where the mp1 header files go now), for example,
> under $Config{installsitearch}/auto/mod_perl/, and then
> record that in Apache::MyConfig. Alternatively, as with
> mod_perl.so, we could let the user specify the location via
> a Makefile.PL INSTALL_LIB flag (analagous to Win32's
> INSTALL_DLL), and if this is not given, set it to be under
> APACHE_SRC/libexec, if this exists (ie, the user has given
> the Apache installation directory for APACHE_SRC).
> Preferences?
Either way is fine with me as long as things are working as before and even
better ;)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp1] win32 Makefile.PL patch
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sat, 13 Sep 2003, Stas Bekman wrote:
[ ... ]
> So what I was saying is that we probably need to continue
> building *mod_perl* as before, however make mod_perl.lib
> and anything else needed available under the Apache source
> tree (or I think under the perl lib tree for mp1, since
> that's where we keep all our mp stuff). Does it make
> sense?
Yes, that does ... We could put it under the perl tree
(that's where the mp1 header files go now), for example,
under $Config{installsitearch}/auto/mod_perl/, and then
record that in Apache::MyConfig. Alternatively, as with
mod_perl.so, we could let the user specify the location via
a Makefile.PL INSTALL_LIB flag (analagous to Win32's
INSTALL_DLL), and if this is not given, set it to be under
APACHE_SRC/libexec, if this exists (ie, the user has given
the Apache installation directory for APACHE_SRC).
Preferences?
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp1] win32 Makefile.PL patch
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Fri, 12 Sep 2003, Stas Bekman wrote:
>
>
>>Randy Kobes wrote:
>>
>>>In a thread on the mod_perl list about building
>>>Apache::Dispatch on Win32 using mod_perl 1, Steve raised the
>>>point about the entry in Apache::MyConfig pointing to
>>>mod_perl.lib referred to the source location. For building
>>>3rd party modules, it would be more convenient if
>>>mod_perl.lib was, first of all, installed into the Apache/
>>>tree, and secondly, if Apache::MyConfig pointed rather to
>>>this location. The patch below to the current cvs
>>>Makefile.PL carries this out. In order to do this, I dropped
>>>support for being able to build mod_perl on Win32 using an
>>>Apache source tree, and instead now demand that APACHE_SRC
>>>point to an installed Apache/ directory (which it could
>>>before) - otherwise, the logic of trying to figure out where
>>>to put what becomes pretty involved. I've also dropped
>>>support for Apache versions that use ApacheModulePerl.dll as
>>>the name of the mod_perl library, rather than mod_perl.so -
>>>these are quite old Apache versions, and shouldn't be used
>>>especially on Win32 due to security holes. If this patch is
>>>OK, I'll make sure to specify these in the Changes and
>>>INSTALL.win32 files.
>>
>>Shooting in the dark: isn't that sort of late to do such
>>drastic changes like dropping builds against the source at
>>this point for mp1? All books out there document it as
>>working. Would it be too hard to keep it as before and fix
>>things that don't work? On the other hand it's quite
>>possible that nobody on win32 builds mp1 from source at
>>all. Just an idea...
>
>
> That is a good point ... The difficulties I was running into
> in installing mod_perl.lib, and subsequently make it useable
> for 3rd party modules, is that it's more useful when put
> into the installed Apache tree, rather than an Apache or
> mod_perl source tree, as a user may delete the sources after
> installation without realizing they may be used later for
> 3rd party modules. One could keep the option of building
> against an Apache source tree, and then prompt the user for
> an installation directory if the source directory is given,
> but then with the installation directory at hand, there's no
> use in principle for the source directory.
But now you are talking about a different thing. Above you said:
>>>In order to do this, I dropped
>>>support for being able to build mod_perl on Win32 using an
>>>Apache source tree,
whereas your real problem is about building extensions. So what I was saying
is that we probably need to continue building *mod_perl* as before, however
make mod_perl.lib and anything else needed available under the Apache source
tree (or I think under the perl lib tree for mp1, since that's where we keep
all our mp stuff). Does it make sense?
> However, as you say, it may be better not to drop the source
> support - what I could do is, if an Apache source directory
> is given, try to make a guess where the installation
> directory is, and then prompt for confirmation, if a guess
> is found, or else just prompt for the installation
> directory.
If you copy it away, you don't need to do that.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp1] win32 Makefile.PL patch
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 12 Sep 2003, Stas Bekman wrote:
> Randy Kobes wrote:
> > In a thread on the mod_perl list about building
> > Apache::Dispatch on Win32 using mod_perl 1, Steve raised the
> > point about the entry in Apache::MyConfig pointing to
> > mod_perl.lib referred to the source location. For building
> > 3rd party modules, it would be more convenient if
> > mod_perl.lib was, first of all, installed into the Apache/
> > tree, and secondly, if Apache::MyConfig pointed rather to
> > this location. The patch below to the current cvs
> > Makefile.PL carries this out. In order to do this, I dropped
> > support for being able to build mod_perl on Win32 using an
> > Apache source tree, and instead now demand that APACHE_SRC
> > point to an installed Apache/ directory (which it could
> > before) - otherwise, the logic of trying to figure out where
> > to put what becomes pretty involved. I've also dropped
> > support for Apache versions that use ApacheModulePerl.dll as
> > the name of the mod_perl library, rather than mod_perl.so -
> > these are quite old Apache versions, and shouldn't be used
> > especially on Win32 due to security holes. If this patch is
> > OK, I'll make sure to specify these in the Changes and
> > INSTALL.win32 files.
>
> Shooting in the dark: isn't that sort of late to do such
> drastic changes like dropping builds against the source at
> this point for mp1? All books out there document it as
> working. Would it be too hard to keep it as before and fix
> things that don't work? On the other hand it's quite
> possible that nobody on win32 builds mp1 from source at
> all. Just an idea...
That is a good point ... The difficulties I was running into
in installing mod_perl.lib, and subsequently make it useable
for 3rd party modules, is that it's more useful when put
into the installed Apache tree, rather than an Apache or
mod_perl source tree, as a user may delete the sources after
installation without realizing they may be used later for
3rd party modules. One could keep the option of building
against an Apache source tree, and then prompt the user for
an installation directory if the source directory is given,
but then with the installation directory at hand, there's no
use in principle for the source directory.
However, as you say, it may be better not to drop the source
support - what I could do is, if an Apache source directory
is given, try to make a guess where the installation
directory is, and then prompt for confirmation, if a guess
is found, or else just prompt for the installation
directory.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp1] win32 Makefile.PL patch
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> In a thread on the mod_perl list about building
> Apache::Dispatch on Win32 using mod_perl 1, Steve raised the
> point about the entry in Apache::MyConfig pointing to
> mod_perl.lib referred to the source location. For building
> 3rd party modules, it would be more convenient if
> mod_perl.lib was, first of all, installed into the Apache/
> tree, and secondly, if Apache::MyConfig pointed rather to
> this location. The patch below to the current cvs
> Makefile.PL carries this out. In order to do this, I dropped
> support for being able to build mod_perl on Win32 using an
> Apache source tree, and instead now demand that APACHE_SRC
> point to an installed Apache/ directory (which it could
> before) - otherwise, the logic of trying to figure out where
> to put what becomes pretty involved. I've also dropped
> support for Apache versions that use ApacheModulePerl.dll as
> the name of the mod_perl library, rather than mod_perl.so -
> these are quite old Apache versions, and shouldn't be used
> especially on Win32 due to security holes. If this patch is
> OK, I'll make sure to specify these in the Changes and
> INSTALL.win32 files.
Shooting in the dark: isn't that sort of late to do such drastic changes like
dropping builds against the source at this point for mp1? All books out there
document it as working. Would it be too hard to keep it as before and fix
things that don't work? On the other hand it's quite possible that nobody on
win32 builds mp1 from source at all. Just an idea...
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
[mp1] win32 Makefile.PL patch
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
In a thread on the mod_perl list about building
Apache::Dispatch on Win32 using mod_perl 1, Steve raised the
point about the entry in Apache::MyConfig pointing to
mod_perl.lib referred to the source location. For building
3rd party modules, it would be more convenient if
mod_perl.lib was, first of all, installed into the Apache/
tree, and secondly, if Apache::MyConfig pointed rather to
this location. The patch below to the current cvs
Makefile.PL carries this out. In order to do this, I dropped
support for being able to build mod_perl on Win32 using an
Apache source tree, and instead now demand that APACHE_SRC
point to an installed Apache/ directory (which it could
before) - otherwise, the logic of trying to figure out where
to put what becomes pretty involved. I've also dropped
support for Apache versions that use ApacheModulePerl.dll as
the name of the mod_perl library, rather than mod_perl.so -
these are quite old Apache versions, and shouldn't be used
especially on Win32 due to security holes. If this patch is
OK, I'll make sure to specify these in the Changes and
INSTALL.win32 files.
Steve, if you get a chance, could you try this patch
out to see if it works for you? Thanks.
=============================================================
Index: Makefile.PL
===================================================================
RCS file: /home/cvs/modperl/Makefile.PL,v
retrieving revision 1.216
diff -u -r1.216 Makefile.PL
--- Makefile.PL 19 Aug 2003 05:07:44 -0000 1.216
+++ Makefile.PL 13 Sep 2003 02:52:21 -0000
@@ -367,9 +367,8 @@
if ($vcpp and $win32_args{APACHE_SRC}) {
$EVERYTHING = 1;
my $fixed_apsrc = win32_fix_path($win32_args{APACHE_SRC});
- $APACHE_SRC = -d "$fixed_apsrc/include" ? $fixed_apsrc :
- (-d "$fixed_apsrc/src/include" ? $fixed_apsrc . '/src' :
- die "Cannot find the Apache include directory under $fixed_apsrc");
+ $APACHE_SRC = -d "$fixed_apsrc/include" ? $fixed_apsrc :
+ die "Cannot find the Apache include directory under $fixed_apsrc";
$win32_auto = 1;
unless ($win32_args{INSTALL_DLL}) {
my $w32_ap_mod = $fixed_apsrc . '/modules';
@@ -1369,9 +1368,7 @@
if ($win32_args{INSTALL_DLL}) {
$string .= sprintf qq{\namp_install:\n\t\$(CP) "%s" "%s"},
"$win32_path{MODPERL_LIB}/mod_perl.so",
- $win32_args{INSTALL_DLL} .
- ($win32_args{APACHE_VERS} < 1315 ?
- '/ApacheModulePerl.dll' : '/mod_perl.so');
+ $win32_args{INSTALL_DLL} . '/mod_perl.so';
if (-d "$win32_args{APACHE_SRC}/libexec") {
my $libexec = win32_fix_path($win32_args{APACHE_SRC}) . '/libexec';
$string .= sprintf qq{\n\t\$(CP) "%s" "%s"},
@@ -2059,10 +2056,11 @@
}
}
if ($win32_auto) {
- for (qw(APACHE_INC APACHE_LIB MODPERL_INC MODPERL_LIB)) {
- $my_config{$_} = $win32_path{$_};
- }
$my_config{APACHE_SRC} = $APACHE_SRC;
+ $my_config{MODPERL_INC} = Apache::src->new->inc;
+ $my_config{APACHE_INC} = '-I' . $win32_path{APACHE_INC};
+ $my_config{MODPERL_LIB} = $my_config{APACHE_LIB} =
+ $win32_path{APACHE_LIB};
}
#need this alias for Apache::src backwards compat
@@ -2118,41 +2116,21 @@
# obtain the Apache and mod_perl lib and include directories for Win32
sub win32_inc_and_lib {
- my $modperl_src = win32_fix_path(cwd) . '/src';
- $win32_path{MODPERL_INC} = $modperl_src . '/modules/perl';
- $win32_path{MODPERL_LIB} = ($win32_args{DEBUG} == 1) ?
- $modperl_src . '/modules/win32/Debug' :
- $modperl_src . '/modules/win32/Release';
-
- unless ( -d $win32_args{APACHE_SRC}) {
- opendir(DIR, '../') or die "Cannot read parent directory: $!\n";
- my @dirs = map {"../$_"}
- grep {/apache/ and -d "../$_"} readdir DIR;
- closedir DIR or die "Cannot close parent directory: $!\n";
- die "Cannot find the apache sources\n"
- unless ($win32_args{APACHE_SRC} = find_dir(\@dirs, 'apache source'));
- }
+ my $modperl_src = win32_fix_path(cwd) . '/src/modules/';
$win32_args{APACHE_SRC} = win32_fix_path($win32_args{APACHE_SRC});
if (-d "$win32_args{APACHE_SRC}/libexec") {
$win32_path{APACHE_LIB} = $win32_args{APACHE_SRC} . '/libexec';
$win32_path{APACHE_INC} = $win32_args{APACHE_SRC} . '/include';
- $win32_args{APACHE_VERS} = httpd_version($win32_path{APACHE_INC}, 1);
- }
- else {
- $win32_args{APACHE_SRC} .= '/src' unless $win32_args{APACHE_SRC} =~ /src$/;
- $win32_path{APACHE_INC} = $win32_args{APACHE_SRC} . '/include';
- $win32_args{APACHE_VERS} = httpd_version($win32_path{APACHE_INC}, 1);
- $win32_path{APACHE_LIB} = ($win32_args{DEBUG} == 1) ?
- $win32_args{APACHE_SRC} .
- ($win32_args{APACHE_VERS} < 1315 ? '/CoreD' : '/Debug') :
- $win32_args{APACHE_SRC} .
- ($win32_args{APACHE_VERS} < 1315 ? '/CoreR' : '/Release');
}
+ $win32_path{MODPERL_INC} = $modperl_src . 'perl';
+ $win32_path{MODPERL_LIB} = $modperl_src . 'win32/' .
+ ($win32_args{DEBUG} == 1 ? 'Debug' : 'Release');
+
die "Cannot find ApacheCore.lib under $win32_path{APACHE_LIB}\n"
unless -f "$win32_path{APACHE_LIB}/ApacheCore.lib";
die "Cannot find httpd.h under $win32_path{APACHE_INC}\n"
unless -f "$win32_path{APACHE_INC}/httpd.h";
-
+
if ($win32_args{INSTALL_DLL} ) {
$win32_args{INSTALL_DLL} =
win32_fix_path($win32_args{INSTALL_DLL});
@@ -2202,7 +2180,7 @@
}
elsif (/ADD CPP/) {
my $apache_inc = win32_fix_path_dsp($win32_path{APACHE_INC});
- s!(/D "WIN32")!/I "$apache_inc" /I "$apache_inc/../os/win32" /I "$perl_inc" $1!;
+ s!(/D "WIN32")!/I "$apache_inc" /I "$perl_inc" $1!;
s!(/D "WIN32")!$1 /D "EAPI" ! if $win32_args{EAPI};
print NEWDSP $_;
}
========================================================================
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Posted by Steve Hay <st...@uk.radan.com>.
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
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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.orig Wed 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(\@directives);
+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
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> 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
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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
Posted by Thomas Klausner <do...@zsi.at>.
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
Posted by Steve Hay <st...@uk.radan.com>.
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
Posted by Thomas Klausner <do...@zsi.at>.
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$_.$/}