[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] 1.4 build failures on RHEL/CentOS 5
From: |
David Levine |
Subject: |
Re: [Nmh-workers] 1.4 build failures on RHEL/CentOS 5 |
Date: |
Sun, 05 Feb 2012 11:16:20 -0500 |
Tethys wrote:
> Ken Hornstein writes:
>
> >>That was fixed by installing ncurses-devel, but we should really be
> >>checking for that at configure time. Also:
> >
> >I think we do, right? I mean, we check for tgetent in configure.
> >What did configure say when you ran it without ncurses-devel installed?
>
> checking for tgetent in -ltermcap... no
> checking for tgetent in -lcurses... no
> checking for tgetent in -lncurses... no
> checking if tgetent accepts NULL... no
> checking if tgetent returns 0 on success... no
>
> But it doesn't actually complain. It still builds a makefile and lets
> me think everything is OK.
I'm not sure how best to handle this with configure. It'd
be easy to print a warning message. I doubt that would be
very effective, but maybe it's good enough. Or it'd be easy
to exit 1, but then a user might end up chasing one missing
lib at a time.
> >You want to look at dtimep.c (the generated output from dtimep.lex).
> >And from the 1.4 tarball ... yes, it's in there.
>
> I don't have one of those. From the savannah tarball:
>
> address@hidden:~/nmh-1.4% find . -name 'dtimep*' -print
> ./sbr/dtimep.lex
>
> It looks like $(LEX) is not being set, so the makefile to build dtimep.c
> isn't doing so. Ahhh, I see. I don't have flex installed. Again, from
> configure:
>
> checking for flex... no
> checking for lex... no
>
> But it still doesn't tell me that the absence of flex is problem.
As Steve noted, sbr/dtimep.c should be in the tarball. make dist
puts it there. Try downloading the latest?
> One final grumble. If I install as a non-root user (which I always
> do, unless there's a specific reason to do otherwise), I get:
>
> if test x1 !=3D x; then \
> /usr/bin/install -c -g mail -m 2755 inc =
> /local/opt/x86/linux/nmh-1.4/bin/$cmd; \
> else \
> /usr/bin/install -c inc =
> /local/opt/x86/linux/nmh-1.4/bin/$cmd; \
> fi
> /usr/bin/install: cannot change ownership of =
> `/local/opt/x86/linux/nmh-1.4/bin/inc': Operation not permitted
> make[1]: *** [install-scmds] Error 1
> make[1]: Leaving directory `/local/home/install/nmh-1.4/uip'
> make: *** [install] Error 1
>
> We should probably be catching this and failing a bit more gracefully.
> I'm not sure why inc needs to be setgid mail anyway, though, given
> that mail files are owned by the user that's running inc, they should
> surely always have permission to modify them anyway, right? Certainly
> that's true on all of my machines. Not that I use inc, so it's somewhat
> irrelevant to me. But if inc does need the setgid bit set, then surely
> shouldn't rcvstore (which I do use) also need it?
Only inc needs to be setgid, and then only 1) if using dot
locking and 2) non-world writable mail spool. configure does
the right thing if you add --with-locking=fcntl.
David