Mailing List Archive: ModPerl: Dev

RELEASE CANDIDATE] mod_perl-1.31 RC1

Index | Next | Previous | View Threaded

gozer at ectoplasm

Dec 21, 2007, 11:41 PM

Post #1 of 25 (7465 views)
Permalink

RELEASE CANDIDATE] mod_perl-1.31 RC1

The mod_perl 1.31 release candidate "Works with Perl 5.10" is ready. It can be downloaded here:

http://www.apache.org/~gozer/mp1/mod_perl-1.31-rc1.tar.gz

MD5: 7cda8676120ff6654bcbe923a2ff5747
SHA1: d8d2d4ad36d134a098601083ed4826664bb8a6cf

The summary of what has changed since 1.30 are (from Changes):

Avoid possible segfault when PerlFreshRestart is On.
[Michael Rendell <michael [at] cs>]

Fix shared libary extensions on Win32 to be .dll not .so
[Nikolay Ananiev <ananiev [at] thegdb>]

Patch to mod_perl.dsp to remove /D _WINSOCK2API_ on Win32
for perl >= 5.8.6 [Steve Hay]

--
Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5
http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/

Attachments:

signature.asc (0.24 KB)

perrin at elem

Dec 21, 2007, 11:46 PM

Post #2 of 25 (7346 views)
Permalink

Re: RELEASE CANDIDATE] mod_perl-1.31 RC1 [In reply to]

All tests pass on Fedora 7 with apache 1.3.39 and perl 5.8.8.

- Perrin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl

SteveHay at planit

Jan 2, 2008, 9:50 AM

Post #3 of 25 (7313 views)
Permalink

RE: RELEASE CANDIDATE] mod_perl-1.31 RC1 [In reply to]

Philippe M. Chiasson wrote:
> The mod_perl 1.31 release candidate "Works with Perl 5.10" is ready.
> It can be downloaded here:
>
> http://www.apache.org/~gozer/mp1/mod_perl-1.31-rc1.tar.gz
>
> MD5: 7cda8676120ff6654bcbe923a2ff5747
> SHA1: d8d2d4ad36d134a098601083ed4826664bb8a6cf
>
> The summary of what has changed since 1.30 are (from Changes):

There is no mention in the Changes file of the change that prompted this
release to be made, namely:

http://svn.apache.org/viewvc?view=rev&revision=555908

(I'm not familiar with how/when the Changes file gets written/generated.
Should I have changed it when I committed that change, or is it
generated from svn logs somehow?)

Aside from that, I have two other problems with this rc1:

1. Randy's patch here:

http://marc.info/?l=apache-modperl-dev&m=117547002021789&w=2

was never applied, which means that "nmake test" just hangs for me.

2. modules/regex.t still fails test 4 for me, as first described in my
reply to the email above:

http://marc.info/?l=apache-modperl-dev&m=117552448731570&w=2

(I'm now using a fresh build of 5.10.0 + 1.3.39 using VC6.)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl

randy at theoryx5

Jan 2, 2008, 10:21 AM

Post #4 of 25 (7308 views)
Permalink

RE: RELEASE CANDIDATE] mod_perl-1.31 RC1 [In reply to]

On Wed, 2 Jan 2008, Steve Hay wrote:

> Aside from that, I have two other problems with this rc1:
>
> 1. Randy's patch here:
>
> http://marc.info/?l=apache-modperl-dev&m=117547002021789&w=2
>
> was never applied, which means that "nmake test" just hangs for me.

If someone on Unix could verify that this patch works
OK there, I'll apply it - thanks.

--
best regards,
Randy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl

gozer at ectoplasm

Jan 10, 2008, 1:19 AM

Post #5 of 25 (7287 views)
Permalink

Re: RELEASE CANDIDATE] mod_perl-1.31 RC1 [In reply to]

Steve Hay wrote:
> Philippe M. Chiasson wrote:
>> The mod_perl 1.31 release candidate "Works with Perl 5.10" is ready.
>> It can be downloaded here:
>>
>> http://www.apache.org/~gozer/mp1/mod_perl-1.31-rc1.tar.gz
>>
>> MD5: 7cda8676120ff6654bcbe923a2ff5747
>> SHA1: d8d2d4ad36d134a098601083ed4826664bb8a6cf
>>
>> The summary of what has changed since 1.30 are (from Changes):
>
> There is no mention in the Changes file of the change that prompted this
> release to be made, namely:
>
> http://svn.apache.org/viewvc?view=rev&revision=555908
>
> (I'm not familiar with how/when the Changes file gets written/generated.
> Should I have changed it when I committed that change, or is it
> generated from svn logs somehow?)

Yes, you should have. The idea is to add a mention in the Changes files
whenever a change could be externally visible, affecting users.

Normally, commit the edit to Changes along with the code change.

In this case, it's also fine to add a mention in the Changes
file after the fact, just make sure to refer to the original
change number in the commit message.

> Aside from that, I have two other problems with this rc1:
>
> 1. Randy's patch here:
>
> http://marc.info/?l=apache-modperl-dev&m=117547002021789&w=2
>
> was never applied, which means that "nmake test" just hangs for me.

Applied as revision 610728.

> 2. modules/regex.t still fails test 4 for me, as first described in my
> reply to the email above:
>
> http://marc.info/?l=apache-modperl-dev&m=117552448731570&w=2

Can't reproduce this on *nix, so I'll assume it's a Win32 specific
problem.

Any additionnal information on that failure? error_log ?

--
Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5
http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/

Attachments:

signature.asc (0.24 KB)

SteveHay at planit

Jan 10, 2008, 2:49 AM

Post #6 of 25 (7278 views)
Permalink

RE: RELEASE CANDIDATE] mod_perl-1.31 RC1 [In reply to]

Philippe M. Chiasson wrote:
> Steve Hay wrote:
>> Philippe M. Chiasson wrote:
>>> The mod_perl 1.31 release candidate "Works with Perl 5.10" is
>>> ready. It can be downloaded here:
>>>
>>> http://www.apache.org/~gozer/mp1/mod_perl-1.31-rc1.tar.gz
>>>
>>> MD5: 7cda8676120ff6654bcbe923a2ff5747
>>> SHA1: d8d2d4ad36d134a098601083ed4826664bb8a6cf
>>>
>>> The summary of what has changed since 1.30 are (from Changes):
>>
>> There is no mention in the Changes file of the change that prompted
>> this release to be made, namely:
>>
>> http://svn.apache.org/viewvc?view=rev&revision=555908
>>
>> (I'm not familiar with how/when the Changes file gets
>> written/generated. Should I have changed it when I committed that
>> change, or is it generated from svn logs somehow?)
>
> Yes, you should have. The idea is to add a mention in the Changes
> files whenever a change could be externally visible, affecting users.
>
> Normally, commit the edit to Changes along with the code change.
>
> In this case, it's also fine to add a mention in the Changes
> file after the fact, just make sure to refer to the original
> change number in the commit message.

OK, sorry about that--I'm used to having the Changes file in perl
generated for me ;-)

I've added to the Changes file in r610750 now.

>
>> Aside from that, I have two other problems with this rc1:
>>
>> 1. Randy's patch here:
>>
>> http://marc.info/?l=apache-modperl-dev&m=117547002021789&w=2
>>
>> was never applied, which means that "nmake test" just hangs for me.
>
> Applied as revision 610728.

Thanks.

>
>> 2. modules/regex.t still fails test 4 for me, as first described in
>> my reply to the email above:
>>
>> http://marc.info/?l=apache-modperl-dev&m=117552448731570&w=2
>
> Can't reproduce this on *nix, so I'll assume it's a Win32 specific
> problem.
>
> Any additionnal information on that failure? error_log ?

I only get one line in the error log:

[Thu Jan 10 10:43:06 2008] [error] [client 127.0.0.1] File does not
exist: c:/temp/mod_perl-1.31-rc1/t/net/perl/cgi.pl/(yikes

There is also an xferlog containing this:

127.0.0.1 - - [10/Jan/2008:10:43:06 +0000] "GET /test.html HTTP/1.0" 200
566
127.0.0.1 - - [10/Jan/2008:10:43:06 +0000] "GET /test.html HTTP/1.0" 200
566
127.0.0.1 - - [10/Jan/2008:10:43:06 +0000] "GET
/perl/cgi.pl/(yikes?PARAM=2 HTTP/1.0" 200 5
127.0.0.1 - - [10/Jan/2008:10:43:06 +0000] "GET
/dirty-perl/cgi.pl/(yikes?PARAM=3 HTTP/1.0" 200 5
127.0.0.1 - - [10/Jan/2008:10:43:06 +0000] "GET
/ng-perl/cgi.pl/(yikes?PARAM=4 HTTP/1.0" 404 215
127.0.0.1 - - [10/Jan/2008:10:43:06 +0000] "GET
/cgi-bin/cgi.pl/(yikes?PARAM=5 HTTP/1.0" 200 5

Otherwise I only have the console output to go on:

C:\Temp\mod_perl-1.31-rc1>perl t/TEST.win32 -v modules\regex.t
Running tests with:
perl=C:\perl510\bin\perl.exe
apache=C:/apache13/Apache.exe
httpd listening on port 8529
will write error_log to: t/logs/mod_perl_error_log
letting apache warm up...
Perl/v5.10.0 Apache/1.3.39 (Win32) mod_perl/1.31-rc1 running...
done
modules\regex....module CGI is installed
1..5
ok 1
# Apache::Registry
ok 2
# Apache::PerlRun
ok 3
# Apache::RegistryNG
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>404 Not Found</TITLE>
</HEAD><BODY>
<H1>Not Found</H1>
The requested URL /ng-perl/cgi.pl/(yikes was not found on this
server.<P>
</BODY></HTML>
# mod_cgi
ok 5
FAILED test 4
Failed 1/5 tests, 80.00% okay
Failed Test Stat Wstat Total Fail List of Failed
------------------------------------------------------------------------
-------
modules\regex.t 5 1 4
Failed 1/1 test scripts. 1/5 subtests failed.
Files=1, Tests=5, 0 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00
CPU)
Failed 1/1 test programs. 1/5 subtests failed.
letting apache cool down...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl

gozer at ectoplasm

Jan 11, 2008, 12:06 AM

Post #7 of 25 (7285 views)
Permalink

Re: RELEASE CANDIDATE] mod_perl-1.31 RC1 [In reply to]

Steve Hay wrote:
> Philippe M. Chiasson wrote:
>> Steve Hay wrote:
>>> Philippe M. Chiasson wrote:
>>>> The mod_perl 1.31 release candidate "Works with Perl 5.10" is
>>>> ready. It can be downloaded here:
> [...]
>
>>> 2. modules/regex.t still fails test 4 for me, as first described in
>>> my reply to the email above:
>>>
>>> http://marc.info/?l=apache-modperl-dev&m=117552448731570&w=2
>> Can't reproduce this on *nix, so I'll assume it's a Win32 specific
>> problem.
>>
>> Any additionnal information on that failure? error_log ?
>
> I only get one line in the error log:
>
> [Thu Jan 10 10:43:06 2008] [error] [client 127.0.0.1] File does not
> exist: c:/temp/mod_perl-1.31-rc1/t/net/perl/cgi.pl/(yikes

That's very strange, notice the '(' ?

This entire test is testing for the CVE-2007-1349 problem, and it seems
Apache::RegistryNG gets tripped over the funny URL:

/cgi.pl/(yikes?PARAM=4

Funny that it passes on *nix'es, so it's got something to do with a
particularity of Win32 and RegistryNG.pm.

If you care to try to debug this, I'd like at lib/Apache/RegistryNG.pm
for a point where it returns a status code (404, presumably) early in
that case.

$> wc -l lib/Apache/RegistryNG.pm
64 lib/Apache/RegistryNG.pm

Shouldn't be too long, it's a small module.

But in all seriousness, is Apache::RegistryNG even used ?

Personally, I wouldn't consider this bug a release blocker, but that's
just me.

--
Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5
http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/

Attachments:

signature.asc (0.24 KB)

SteveHay at planit

Jan 11, 2008, 2:51 AM

Post #8 of 25 (7282 views)
Permalink

RE: RELEASE CANDIDATE] mod_perl-1.31 RC1 [In reply to]

Philippe M. Chiasson wrote:
> Steve Hay wrote:
>> Philippe M. Chiasson wrote:
>>> Steve Hay wrote:
>>>> Philippe M. Chiasson wrote:
>>>>> The mod_perl 1.31 release candidate "Works with Perl 5.10" is
>>>>> ready. It can be downloaded here:
>> [...]
>>
>>>> 2. modules/regex.t still fails test 4 for me, as first described
>>>> in my reply to the email above:
>>>>
>>>> http://marc.info/?l=apache-modperl-dev&m=117552448731570&w=2
>>> Can't reproduce this on *nix, so I'll assume it's a Win32 specific
>>> problem.
>>>
>>> Any additionnal information on that failure? error_log ?
>>
>> I only get one line in the error log:
>>
>> [Thu Jan 10 10:43:06 2008] [error] [client 127.0.0.1] File does not
>> exist: c:/temp/mod_perl-1.31-rc1/t/net/perl/cgi.pl/(yikes
>
> That's very strange, notice the '(' ?
>
> This entire test is testing for the CVE-2007-1349 problem, and it
> seems Apache::RegistryNG gets tripped over the funny URL:
>
> /cgi.pl/(yikes?PARAM=4
>
> Funny that it passes on *nix'es, so it's got something to do with a
> particularity of Win32 and RegistryNG.pm.
>
> If you care to try to debug this, I'd like at lib/Apache/RegistryNG.pm
> for a point where it returns a status code (404, presumably) early in
> that case.
>
> $> wc -l lib/Apache/RegistryNG.pm
> 64 lib/Apache/RegistryNG.pm
>
> Shouldn't be too long, it's a small module.

I had a look and found that the module didn't appear to be getting used,
suggesting that the 404 arose because the location asked for by the test
script really didn't exist.

It turns out to be a typo in the (Win32-specific!) httpd.conf file used
by the test scripts! Now fixed in r611135.

I really should have pulled my finger out and fixed that sooner, so
sorry for the hassle.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl

gozer at ectoplasm

Jan 11, 2008, 11:21 AM

Post #9 of 25 (7284 views)
Permalink

Re: RELEASE CANDIDATE] mod_perl-1.31 RC1 [In reply to]

Steve Hay wrote:
> Philippe M. Chiasson wrote:
>> Steve Hay wrote:
>>> Philippe M. Chiasson wrote:
>>>> Steve Hay wrote:
>>>>> Philippe M. Chiasson wrote:
>>>>>> The mod_perl 1.31 release candidate "Works with Perl 5.10" is
>>>>>> ready. It can be downloaded here:
>>> [...]
>>>
>>>>> 2. modules/regex.t still fails test 4 for me, as first described
>>>>> in my reply to the email above:
>>>>>
>>>>> http://marc.info/?l=apache-modperl-dev&m=117552448731570&w=2
>>>> Can't reproduce this on *nix, so I'll assume it's a Win32 specific
>>>> problem.
>>>>
>>>> Any additionnal information on that failure? error_log ?
>>> I only get one line in the error log:
>>>
>>> [Thu Jan 10 10:43:06 2008] [error] [client 127.0.0.1] File does not
>>> exist: c:/temp/mod_perl-1.31-rc1/t/net/perl/cgi.pl/(yikes
>> That's very strange, notice the '(' ?
>>
>> This entire test is testing for the CVE-2007-1349 problem, and it
>> seems Apache::RegistryNG gets tripped over the funny URL:
>>
>> /cgi.pl/(yikes?PARAM=4
>>
>> Funny that it passes on *nix'es, so it's got something to do with a
>> particularity of Win32 and RegistryNG.pm.
>>
>> If you care to try to debug this, I'd like at lib/Apache/RegistryNG.pm
>> for a point where it returns a status code (404, presumably) early in
>> that case.
>>
>> $> wc -l lib/Apache/RegistryNG.pm
>> 64 lib/Apache/RegistryNG.pm
>>
>> Shouldn't be too long, it's a small module.
>
> I had a look and found that the module didn't appear to be getting used,
> suggesting that the 404 arose because the location asked for by the test
> script really didn't exist.
>
> It turns out to be a typo in the (Win32-specific!) httpd.conf file used
> by the test scripts! Now fixed in r611135.

That's explains it all ;-) Thanks for the debugging (and fix)!

> I really should have pulled my finger out and fixed that sooner, so
> sorry for the hassle.

Guess that means we might be ready for RC2 then ?

I'll roll new tarballs over the week-end.

--
Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5
http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/

Attachments:

signature.asc (0.24 KB)

david at kineticode

Jan 16, 2008, 12:57 PM

Post #10 of 25 (7268 views)
Permalink

Re: RELEASE CANDIDATE] mod_perl-1.31 RC1 [In reply to]

On Jan 11, 2008, at 11:21, Philippe M. Chiasson wrote

> Guess that means we might be ready for RC2 then ?
>
> I'll roll new tarballs over the week-end.

Hi Philippe,

I just grabbed the RC2 tarball and got this error when I tried to
build it with Perl 5.10 on Mac OS X 10.5:

perl -ldl -lm -lutil -lc -lmm -lexpat
ld: warning in modules/perl/libperl.a, file is not of required
architecture
Undefined symbols:
"_perl_setup_env", referenced from:
_handle_perl in libstandard.a(mod_include.o)
"_perl_module", referenced from:
_ap_prelinked_modules in modules.o
_ap_preloaded_modules in modules.o
"_perl_stdout2client", referenced from:
_handle_perl in libstandard.a(mod_include.o)
"_perl_call_handler", referenced from:
_handle_perl in libstandard.a(mod_include.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[2]: *** [target_static] Error 1
make[1]: *** [build-std] Error 2
make: *** [build] Error 2

Is there something I should edit to try a fix?

Best,

David

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl

gozer at ectoplasm

Jan 16, 2008, 3:19 PM

Post #11 of 25 (7265 views)
Permalink

Re: RELEASE CANDIDATE] mod_perl-1.31 RC1 [In reply to]

David E. Wheeler wrote:
> On Jan 11, 2008, at 11:21, Philippe M. Chiasson wrote
>
>> Guess that means we might be ready for RC2 then ?
>>
>> I'll roll new tarballs over the week-end.
>
> Hi Philippe,
>
> I just grabbed the RC2 tarball and got this error when I tried to
> build it with Perl 5.10 on Mac OS X 10.5:
>
> perl -ldl -lm -lutil -lc -lmm -lexpat
> ld: warning in modules/perl/libperl.a, file is not of required
> architecture

Sounds like universal binary fun.

Can you send the exact build instructions you used for:
- perl
- httpd
- mod_perl

So I can try and reproduce ?

> Undefined symbols:
> "_perl_setup_env", referenced from:
> _handle_perl in libstandard.a(mod_include.o)
> "_perl_module", referenced from:
> _ap_prelinked_modules in modules.o
> _ap_preloaded_modules in modules.o
> "_perl_stdout2client", referenced from:
> _handle_perl in libstandard.a(mod_include.o)
> "_perl_call_handler", referenced from:
> _handle_perl in libstandard.a(mod_include.o)
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> make[2]: *** [target_static] Error 1
> make[1]: *** [build-std] Error 2
> make: *** [build] Error 2
>
> Is there something I should edit to try a fix?

$> file libstandart.a
$> file modules/perl/libperl.a

Should give you an idea of what architectures you are dealing with.

It's probably an issue of a universal binary build of Perl, against
a single-binary build of httpd ( or vice-versa )

--
Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5
http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/

Attachments:

signature.asc (0.24 KB)

david at kineticode

Jan 16, 2008, 4:47 PM

Post #12 of 25 (7272 views)
Permalink

Re: RELEASE CANDIDATE] mod_perl-1.31 RC1 [In reply to]

On Jan 16, 2008, at 15:19, Philippe M. Chiasson wrote:

> Sounds like universal binary fun.
>
> Can you send the exact build instructions you used for:
> - perl
> - httpd
> - mod_perl
>

> So I can try and reproduce ?

I compiled Perl myself, from source:

% perl -v
This is perl, v5.10.0 built for darwin-2level

The Apache and mod_perl source directories:

apache_1.3.39
mod_perl-1.31-rc2/

>> Is there something I should edit to try a fix?
>
> $> file libstandart.a
> $> file modules/perl/libperl.a
>
> Should give you an idea of what architectures you are dealing with.

% cd apache_1.3.39
% file src/modules/standard/libstandard.a
src/modules/standard/libstandard.a: current ar archive random library
% file src/modules/perl/libperl.a
src/modules/perl/libperl.a: Mach-O bundle i386

> It's probably an issue of a universal binary build of Perl, against
> a single-binary build of httpd ( or vice-versa )

HTH,

David

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl

gozer at ectoplasm

Jan 17, 2008, 12:15 AM

Post #13 of 25 (7262 views)
Permalink

Re: RELEASE CANDIDATE] mod_perl-1.31 RC1 [In reply to]

David E. Wheeler wrote:
> On Jan 16, 2008, at 15:19, Philippe M. Chiasson wrote:
>
>> Sounds like universal binary fun.
>>
>> Can you send the exact build instructions you used for:
>> - perl
>> - httpd
>> - mod_perl
>>
>
>> So I can try and reproduce ?
>
> I compiled Perl myself, from source:
>
> % perl -v
> This is perl, v5.10.0 built for darwin-2level

How did you build your perl?

I've done the same combo myself, and got 100% test
success.

$> perl -V:config_args
config_args='-des -Doptimize=-g';

So I would guess at this point it's something about how
you are building Perl.

Oh, another thing to make sure is that the httpd tree you are building
in is free of bits from a previous build attempt. Caught me once.

--
Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5
http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/

Attachments:

signature.asc (0.24 KB)

david at kineticode

Jan 17, 2008, 4:28 PM

Post #14 of 25 (7260 views)
Permalink

Re: RELEASE CANDIDATE] mod_perl-1.31 RC1 [In reply to]

On Jan 17, 2008, at 00:15, Philippe M. Chiasson wrote:

> How did you build your perl?
>
> I've done the same combo myself, and got 100% test
> success.
>
> $> perl -V:config_args
> config_args='-des -Doptimize=-g';

trigger# perl -V:config_args
config_args='-des -Dperladmin=root [at] kineticode -Dcf_email=root [at] kineticode
';

What's the -Doptimize bit you have there?

> So I would guess at this point it's something about how
> you are building Perl.
>
> Oh, another thing to make sure is that the httpd tree you are building
> in is free of bits from a previous build attempt. Caught me once.

Yep, it is. Attached is the output of a fresh attempt to build
everything.

Thanks,

David

Attachments:

mod_perl.txt (79.7 KB)

david at kineticode

Jan 21, 2008, 4:20 PM

Post #15 of 25 (7216 views)
Permalink

Re: RELEASE CANDIDATE] mod_perl-1.31 RC1 [In reply to]

I didn't see my reply to this message in the logs, so I'm sending it
again.

> David E. Wheeler wrote:
>
>> I compiled Perl myself, from source:
>>
>> % perl -v
>> This is perl, v5.10.0 built for darwin-2level
>
> How did you build your perl?
>
> I've done the same combo myself, and got 100% test
> success.
>
> $> perl -V:config_args
> config_args='-des -Doptimize=-g';

It's a pretty standard build:

# perl -V:config_args
config_args='-des -Dperladmin=root [at] kineticode -Dcf_email=root [at] kineticode
';

So what is that '-Doptimize=-g' bit you have?

> So I would guess at this point it's something about how
> you are building Perl.
>
> Oh, another thing to make sure is that the httpd tree you are building
> in is free of bits from a previous build attempt. Caught me once.

Yeah, I did it with a clean build of everything. :-(

Best,

David

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl

gozer at ectoplasm

Jan 21, 2008, 10:48 PM

Post #16 of 25 (7222 views)
Permalink

Re: RELEASE CANDIDATE] mod_perl-1.31 RC1 [In reply to]

David E. Wheeler wrote:
> I didn't see my reply to this message in the logs, so I'm sending it
> again.
>
>> David E. Wheeler wrote:
>>
>>> I compiled Perl myself, from source:
>>>
>>> % perl -v
>>> This is perl, v5.10.0 built for darwin-2level
>> How did you build your perl?
>>
>> I've done the same combo myself, and got 100% test
>> success.
>>
>> $> perl -V:config_args
>> config_args='-des -Doptimize=-g';
>
> It's a pretty standard build:
>
> # perl -V:config_args
> config_args='-des -Dperladmin=root [at] kineticode -Dcf_email=root [at] kineticode
> ';
>
> So what is that '-Doptimize=-g' bit you have?

That's just a debug build. Nothing special there.

>> So I would guess at this point it's something about how
>> you are building Perl.
>>
>> Oh, another thing to make sure is that the httpd tree you are building
>> in is free of bits from a previous build attempt. Caught me once.
>
> Yeah, I did it with a clean build of everything. :-(

Can you post the steps you are using to build everything, that way, I might
be able to reproduce it on my setup ?

--
Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5
http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/

Attachments:

signature.asc (0.24 KB)

david at kineticode

Jan 22, 2008, 9:54 AM

Post #17 of 25 (7208 views)
Permalink

Re: RELEASE CANDIDATE] mod_perl-1.31 RC1 [In reply to]

On Jan 21, 2008, at 22:48, Philippe M. Chiasson wrote:

>>> Oh, another thing to make sure is that the httpd tree you are
>>> building
>>> in is free of bits from a previous build attempt. Caught me once.
>> Yeah, I did it with a clean build of everything. :-(
>
> Can you post the steps you are using to build everything, that way,
> I might
> be able to reproduce it on my setup ?

Attached. I'll be on IRC today (#perl and #modperl).

Best,

David

Attachments:

typescript.gz (44.5 KB)

gozer at ectoplasm

Jan 22, 2008, 3:21 PM

Post #18 of 25 (7201 views)
Permalink

Re: RELEASE CANDIDATE] mod_perl-1.31 RC1 [In reply to]

David E. Wheeler wrote:
> On Jan 21, 2008, at 22:48, Philippe M. Chiasson wrote:
>
>>>> Oh, another thing to make sure is that the httpd tree you are
>>>> building
>>>> in is free of bits from a previous build attempt. Caught me once.
>>> Yeah, I did it with a clean build of everything. :-(
>> Can you post the steps you are using to build everything, that way,
>> I might
>> be able to reproduce it on my setup ?

Okay, that's a static build of mod_perl, that's probably where the
difference is. I am building dynamic.

I'll give it a shot and see if I can reproduce.

--
Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5
http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/

Attachments:

signature.asc (0.24 KB)

david at kineticode

Jan 22, 2008, 4:22 PM

Post #19 of 25 (7203 views)
Permalink

Re: RELEASE CANDIDATE] mod_perl-1.31 RC1 [In reply to]

On Jan 22, 2008, at 15:21, Philippe M. Chiasson wrote:

> David E. Wheeler wrote:
>> On Jan 21, 2008, at 22:48, Philippe M. Chiasson wrote:
>>>>> Oh, another thing to make sure is that the httpd tree you are
>>>>> building
>>>>> in is free of bits from a previous build attempt. Caught me once.
>>>> Yeah, I did it with a clean build of everything. :-(
>>> Can you post the steps you are using to build everything, that
>>> way, I might
>>> be able to reproduce it on my setup ?
>
> Okay, that's a static build of mod_perl, that's probably where the
> difference is. I am building dynamic.
>
> I'll give it a shot and see if I can reproduce.

Ah, I always thought that mp1 was better off statically compiled into
Apache. I've been doing it that way for years.

Best,

David

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl

gozer at ectoplasm

Jan 23, 2008, 12:12 AM

Post #20 of 25 (7191 views)
Permalink

Re: RELEASE CANDIDATE] mod_perl-1.31 RC1 [In reply to]

David E. Wheeler wrote:
> On Jan 22, 2008, at 15:21, Philippe M. Chiasson wrote:
>
>> David E. Wheeler wrote:
>>> On Jan 21, 2008, at 22:48, Philippe M. Chiasson wrote:
>>>>>> Oh, another thing to make sure is that the httpd tree you are
>>>>>> building
>>>>>> in is free of bits from a previous build attempt. Caught me once.
>>>>> Yeah, I did it with a clean build of everything. :-(
>>>> Can you post the steps you are using to build everything, that
>>>> way, I might
>>>> be able to reproduce it on my setup ?
>> Okay, that's a static build of mod_perl, that's probably where the
>> difference is. I am building dynamic.
>>
>> I'll give it a shot and see if I can reproduce.
>
> Ah, I always thought that mp1 was better off statically compiled into
> Apache.

I used to do it that way too for the longest time.

> I've been doing it that way for years.

I've switched to DSO a while back, mainly because it is just so much easier
to manage installations, upgrades and the like. I can easily build mod_perl
twice, debug, and non-debug, and keep both .so side-by-side.

One symlink (or configuration change), restart, and I can flip back and
forth between different flavors. It's just too practical!

Welcome to the bleeding edge!

--
Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5
http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/

Attachments:

signature.asc (0.24 KB)

david at kineticode

Jan 23, 2008, 10:23 AM

Post #21 of 25 (7188 views)
Permalink

Re: RELEASE CANDIDATE] mod_perl-1.31 RC1 [In reply to]

On Jan 23, 2008, at 00:12, Philippe M. Chiasson wrote:

>> Ah, I always thought that mp1 was better off statically compiled
>> into Apache.
>
> I used to do it that way too for the longest time.
>
>> I've been doing it that way for years.
>
> I've switched to DSO a while back, mainly because it is just so much
> easier
> to manage installations, upgrades and the like. I can easily build
> mod_perl
> twice, debug, and non-debug, and keep both .so side-by-side.
>
> One symlink (or configuration change), restart, and I can flip back
> and
> forth between different flavors. It's just too practical!
>
> Welcome to the bleeding edge!

Makes sense for a mod_perl developer, of course, but personally I'm
usually building mod_perl to run Bricolage instances, so the static
compile has always made sense. The fact that the DSO builds are more
stable nowadays is great, of course. I'll give that a try.

In the meantime, were you able to replicate the issue with a static
compile?

Thanks,

David

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl

david at kineticode

Jan 23, 2008, 10:29 AM

Post #22 of 25 (7191 views)
Permalink

Re: RELEASE CANDIDATE] mod_perl-1.31 RC1 [In reply to]

On Jan 23, 2008, at 10:23, David E. Wheeler wrote:

> Makes sense for a mod_perl developer, of course, but personally I'm
> usually building mod_perl to run Bricolage instances, so the static
> compile has always made sense. The fact that the DSO builds are more
> stable nowadays is great, of course. I'll give that a try.
>
> In the meantime, were you able to replicate the issue with a static
> compile?

I just tried again without `--disable-shared=perl` and got the same
build failure:

ld: warning in modules/perl/libperl.a, file is not of required
architecture
Undefined symbols:
"_perl_setup_env", referenced from:
_handle_perl in libstandard.a(mod_include.o)
"_perl_module", referenced from:
_ap_prelinked_modules in modules.o
_ap_preloaded_modules in modules.o
"_perl_stdout2client", referenced from:
_handle_perl in libstandard.a(mod_include.o)
"_perl_call_handler", referenced from:
_handle_perl in libstandard.a(mod_include.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[2]: *** [target_static] Error 1
make[1]: *** [build-std] Error 2
make: *** [build] Error 2

:-(

Ah, but it wasn't a DSO. So I switched to `--enabled-shared=perl` and
tried again. That worked.

So it is something to do with the static build.

Best,

David

David

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl

gozer at ectoplasm

Jan 23, 2008, 11:11 PM

Post #23 of 25 (7188 views)
Permalink

Re: RELEASE CANDIDATE] mod_perl-1.31 RC1 [In reply to]

David E. Wheeler wrote:
> On Jan 23, 2008, at 10:23, David E. Wheeler wrote:
>
>> Makes sense for a mod_perl developer, of course, but personally I'm
>> usually building mod_perl to run Bricolage instances, so the static
>> compile has always made sense. The fact that the DSO builds are more
>> stable nowadays is great, of course. I'll give that a try.

Okay, the difference is when you let mod_perl build httpd for you vs.
building it separately.

>> In the meantime, were you able to replicate the issue with a static
>> compile?

Yes, I was, and a previously patch I posted seems to do the trick.

Can you try this patch?

http://mid.gmane.org/477020A5.5060803 [at] ectoplasm

--
Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5
http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/

Attachments:

signature.asc (0.24 KB)

david at kineticode

Jan 24, 2008, 9:20 AM

Post #24 of 25 (7185 views)
Permalink

Re: RELEASE CANDIDATE] mod_perl-1.31 RC1 [In reply to]

On Jan 23, 2008, at 23:11, Philippe M. Chiasson wrote:

> Okay, the difference is when you let mod_perl build httpd for you vs.
> building it separately.

Gotcha.

>>> In the meantime, were you able to replicate the issue with a
>>> static compile?
>
> Yes, I was, and a previously patch I posted seems to do the trick.
>
> Can you try this patch?
>
> http://mid.gmane.org/477020A5.5060803 [at] ectoplasm

Now it can't find libperl.a:

i686-apple-darwin9-gcc-4.0.1: modules/perl/libperl.a: No such file or
directory
make[2]: *** [target_static] Error 1
make[1]: *** [build-std] Error 2
make: *** [build] Error 2

Terminal activity attached.

Best,

David

Attachments:

mod_perl.script.gz (7.00 KB)

david at kineticode

Feb 21, 2008, 2:31 PM

Post #25 of 25 (7001 views)
Permalink

Re: RELEASE CANDIDATE] mod_perl-1.31 RC1 [In reply to]

Hi Philippe,

If necessary, I can give you access to the box on which this happens�

Best,

David

On Jan 24, 2008, at 09:20, David E. Wheeler wrote:

> On Jan 23, 2008, at 23:11, Philippe M. Chiasson wrote:
>
>> Okay, the difference is when you let mod_perl build httpd for you vs.
>> building it separately.
>
> Gotcha.
>
>>>> In the meantime, were you able to replicate the issue with a
>>>> static compile?
>>
>> Yes, I was, and a previously patch I posted seems to do the trick.
>>
>> Can you try this patch?
>>
>> http://mid.gmane.org/477020A5.5060803 [at] ectoplasm
>
> Now it can't find libperl.a:
>
> i686-apple-darwin9-gcc-4.0.1: modules/perl/libperl.a: No such file
> or directory
> make[2]: *** [target_static] Error 1
> make[1]: *** [build-std] Error 2
> make: *** [build] Error 2
>
> Terminal activity attached.
>
> Best,
>
> David

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads