perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: BUG REPORT: modperl(dev) make fails at "`APR_SO_TIMEOUT' undeclared"
Date Wed, 03 Dec 2003 02:26:39 GMT
Geoffrey Young wrote:
>>I just tested and it seems to work fine for me under 'root'. Notice that
>>all files under t are chowned to the user/group the server is running
>>under (not-root) before the tests are run.
> 
> 
> yes, for me too, but on linux.  did you test any OSX variant, though?
> 
> richard, are you on darwin or panther?  I have access to darwin but not
> panther, so my debugging is limited.

Richard is on darwin, please see the original report:
http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=106989642826330&w=2

>>I think I remember about a similar problem discussed on p5p
>>
>>    # testing : $r->finfo->user()
>>    # expected: 4294967294
>>    # received: -2
>>    not ok 7
>>    # testing : $r->finfo->group()
>>    # expected: 4294967294
>>    # received: -2
>>
>>Notice that the expected values are not very good. 
> 
> 
> but they match what Apache-Test is doing.  from richard's output
> 
>   ** root mode: changing the files ownership to 'nobody' (4294967294:4294967294)
> 
> so perl is being consistent with itself, at least.  apr  merely reports back
> the result from an fstat call, so the issue really does seem to be with the
> underlying OS.

Cool, I've missed that. It just looked weird. I guess they use 2*32-1 for 
nobody, so they can accomodate 2*32-2 users ;)

>>Here it is:
>>http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2002-01/msg01530.html
> 
> 
> those are good links.  however, according to nick in the first thread, they
> all seem to be talking about c/mtime, not uid/gid.

if you look at that perl test, they don't test uid/gid at all. So I won't be 
surprised if that's the same case.

BTW, why Finfo doesn't use uid/gid but user/group? because of the C data 
struct names? It's probably more intuitive to rename them to be uid/gid, since 
they return the ids and not names.

>>and we also need to document that that finfo doesn't give a valid
>>user/group under Darwin/UFS.
> 
> 
> I think that's premature at this point.  we can just keep skipping failing
> platforms, I suppose, but I'd rather find someone who really understands
> this OSX biz before we simply proclaim that the results are meaningless on
> that platform.  that it works fine as non-root (with sensical 501:0 values)
> leads me to believe that something else is going on.

sure, I suggested to do that if that's indeed the problem.

>>Geoff, you are taking care of this?
> 
> 
> haven't I been?

I thought you bailed out, saying that we should document that the tests are 
not to be run as root. Hence I was asking, so I won't step on your toes.

> I'll piddle around on moof a bit, but underlying POSIX stuff (or whatever it
> is) really isn't my strong point.

How does perl handles that on darwin/UFS? We should just do the same.

__________________________________________________________________
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


Mime
View raw message