Re: [Libevent-users] IRIX build failure in regress_util.c

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Mon, Nov 22, 2010 at 6:59 PM, Kevin Bowling <kevin.bowling@xxxxxxxxxx> wrote:
> On Mon, Nov 22, 2010 at 9:54 AM, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:
>>
>> On Mon, Nov 22, 2010 at 4:06 AM, Kevin Bowling <kevin.bowling@xxxxxxxxxx>
>> wrote:
>> > IRIX 6.5.29, latest MIPSpro compiler and various GNU utilities from
>> > Nekochan
>> > repository.  libevent-2.0.8rc.  I don't see anything wrong with the
>> > code,
>> > especially a line termination one.  Any ideas?
>>
>> My guess would be that somewhere, in system some header file,
>> sa_family is #defined to something else, such that naming a struct
>> member "sa_family" will not work.
>>
>> To see if I'm right, try renaming the member (and references to it in
>> the function below) to something like addr_family?  Be careful not to
>> change too many "sa_family" instances, of course: some will still
>> refer to the field in struct sockaddr.
>
> Good call!  I pushed the change on github.

Merged it.

> I've attached the test output since there are some unrelated failures.
>  Could the failures be related to some of the conversion compiler warnings
> that I have uploaded here https://gist.github.com/710891?  A quick look and
> IRIX defines separate mmap64 and off64_t.  If you think this is the right
> track, I will try to come up with and test a patch.

It could be; I'm not entirely sure.  Some of those warnings are
completely spurious (like casting a pointer to a uintptr_t), but some
of them (like implicitly casting a larger int to a smaller int) could
cause problems.

I'm going to fix a few of them tonight (mainly the ones about unused
values, signed int field:1, and stupid pointer tricks.  If you want to
nail down any others, that would be great.  github works fine for
organizing patches; ideally, having each commit solve a separate kind
of bug/warning would be best in case we need to discus & cherry pick.

> It otherwise works for some simple uses involving buffer events and evhttp
> that I have tried so far.  I'll give AIX with XL C a go later this week.
>
> Regards,
> Kevin Bowling
>
> kev009@IRIS ~/libevent-2.0.8-rc $ make check
>         make  check-recursive
> Making check in .
> Making check in include
> Making check in sample
> Making check in test
>         make  check-am
>         make  check-TESTS
> Running tests:
> KQUEUE
> Skipping test
> DEVPOLL
> test-eof:OKAY
> test-weof:OKAY
> test-time:OKAY
> test-changelist:OKAY
> regress:
>   NOTE regress.c:1912: Can't fake unsetenv; skipping test
>   FAIL regress_buffer.c:918: assert(sum == evbuffer_get_length(buf)):
> 5356000 vs 5324005evbuffer/iterative:
>   [iterative FAILED]

I don't know what's up here, but the numbers involved aren't even
close to 1<<31, so I doubt it's a 64-bit issue.  Something else is
probably going on.

>   FAIL regress_util.c:389: assert(r == 18): 15 vs 18util/evutil_snprintf:
>   [evutil_snprintf FAILED]

This is pretty serious; if evutil_snprintf isn't working right, this
could be a reason for some other tests failing.

I'm not sure what's up with the other tests.  You can get a more
detailed view of the regression tests by running ./test/regress.  To
see a particular test in detail, run ./test/regress --verbose
[testname]  (e.g., ./test/regress --verbose util/evutil_snprintf) .

If the answer's nontrivial, it's probably best to open up a ticket on
the bugtracker; my inbox is a very leaky task management system.

peace,
-- 
Nick
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.