nmh-workers
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]