Subject: Re: Netatalk 1.6.2 locking errors on -current?
To: Frederick Bruckman <firstname.lastname@example.org>
From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
Date: 09/29/2003 22:50:15
At 14:14 Uhr -0500 29.9.2003, Frederick Bruckman wrote:
>Look in "config.log" for the actual error:
> configure:9735: checking sys/mount.h usability
> configure:9748: cc -c -O2 -I/usr/pkg/include -I/usr/pkg/include
> conftest.c >&5
> In file included from /usr/include/sys/mount.h:43,
> from configure:9813:
> /usr/include/sys/ucred.h:47: error: `NGROUPS' undeclared here (not in
> /usr/include/sys/ucred.h:55: error: `NGROUPS' undeclared here (not in
> configure:9751: $? = 1
> configure: failed program was:
> | #line 9738 "configure"
> | /* confdefs.h. */
>It looks like <sys/ucred.h> should really include <sys/param.h> near
>the top. In principle, all headers should be able to stand alone, but
>it's not always the case.
From a small machines' owner's POV, no, they shouldn't. Teaches prohrammers
to know and include what they need, too. Agreed, it' sless convenient.
>The application programmer (or porting
>programmer) always has a simple work-around, which is, of course, to
>include the needed file explicitly. It's evidently not a problem for
>netatalk, or the build would have failed. No doubt, <sys/param.h> is
>getting pulled in some other way. It's only a potential problem when
>you see "implicit definintion" in the build log", and even then, if
>the return type of the implicitly defined function is int, there are
>generally no consequences.
>Now, if "autoconf" ever backs up it's threat to go with the compiler
>result, then the netatalk configure script would fail to define
>SYS_MOUNT_H, and the afpd build would surely break. In that case, the
>autoconf macros would just have to be fixed to include <sys/param.h>
>in the appropriate places.
Good. And, thanks for the explanation. Although I've messed with
autoconf/automake some months ago, "that is still a very evil place; we do
not go that way." [LoTR,I-2] ;)
Next results: 1.6.3 shows the very same access problem; and the problem
also shows up with mosx 10.2.something. What I shall try now is a build
'outside' of pkgsrc. If that runs fine, my suspect is the buildlink maze;
if it doesn't, the autoconf maze.
/~\ The ASCII Ribbon Campaign
\ / No HTML/RTF in email
X No Word docs in email
/ \ Respect for open standards