Re: [Nmh-workers] 1.4 build failures on RHEL/CentOS 5
Ken wrote: > So ... I think all we need to do is change configure to error if it > can't find a curses library. Done. David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 1.4 build failures on RHEL/CentOS 5
So let me summarize: - We should definitely fail in configure if we don't find a curses library, since that's required to build nmh. - From a distribution tarball you don't need lex/flex; what happened to you was the old "make distclean" target removed dtimep.c (and as David Levine pointed out the new distclean target doesn't do that). So ... I think all we need to do is change configure to error if it can't find a curses library. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 1.4 build failures on RHEL/CentOS 5
Tethys wrote: > Oooh, you're right. It was there in the tar archive, but not in my > directory. I'm guessing it was removed by the "make distclean" that > I did to try and rebuild from a pristine state after I'd installed > ncurses-devel. sbr/dtimep.c is now (since the automake conversion) removed by "make maintainer-clean". So it will survive "make distclean". David ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 1.4 build failures on RHEL/CentOS 5
ra...@hep.wisc.edu writes: > > I don't have one of those. From the savannah tarball: > > > > local@riva:~/nmh-1.4% find . -name 'dtimep*' -print > > ./sbr/dtimep.lex > >Really? > >$ wget http://download.savannah.nongnu.org/releases/nmh/nmh-1.4.tar.gz >[...] >$ tar -ztvf nmh-1.4.tar.gz | grep dtimep.c >-rw-r--r-- kenh/kenh 79419 2012-01-01 11:15:52 nmh-1.4/sbr/dtimep.c Oooh, you're right. It was there in the tar archive, but not in my directory. I'm guessing it was removed by the "make distclean" that I did to try and rebuild from a pristine state after I'd installed ncurses-devel. Tet ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 1.4 build failures on RHEL/CentOS 5
On Sun, 05 Feb 2012 11:16:20 EST, David Levine said: > 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. Doing an exit 1 and letting the user install stuff one at a time seems to be the de-facto standard among other packages. I'd rather do that than chase through a zillion lines of configure output, install the 7 packages it said I needed, and then be *really* mystified because I manage to miss the eighth one... pgp1b1dsVju63.pgp Description: PGP signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 1.4 build failures on RHEL/CentOS 5
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: > > local@riva:~/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 ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 1.4 build failures on RHEL/CentOS 5
> >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: > > local@riva:~/nmh-1.4% find . -name 'dtimep*' -print > ./sbr/dtimep.lex Really? $ wget http://download.savannah.nongnu.org/releases/nmh/nmh-1.4.tar.gz [...] $ tar -ztvf nmh-1.4.tar.gz | grep dtimep.c -rw-r--r-- kenh/kenh 79419 2012-01-01 11:15:52 nmh-1.4/sbr/dtimep.c steve -- ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 1.4 build failures on RHEL/CentOS 5
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. >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: local@riva:~/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. 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 != 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? Tet ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] 1.4 build failures on RHEL/CentOS 5
>On CentOS 5, I get the following compile time errors: >reference to `tgetnum' termsbr.c:(.text+0x132): undefined >[...] >reference to `tgetnum' termsbr.o: In function `SOprintf': >termsbr.c:(.text+0x1be): undefined reference to `tputs' >termsbr.c:(.text+0x1f9): undefined reference to `tputs' >termsbr.o: In function `clear_screen': termsbr.c:(.text+0x2a5): >undefined reference to `tputs' collect2: ld returned 1 exit >status make: *** [mhlist] Error 1 > >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? >reference to `dparsetime' collect2: ld returned 1 exit status >make[1]: *** [forw] Error 1 make[1]: Leaving directory >`/local/home/install/nmh-1.4/uip' make: *** [all-recursive] >Error 1 > >I haven't got to the bottom of that one yet. There's a prototype for it >in tws.h and the definition claims to be in dtimep.lex, but it's been >nearly 20 years since I last did anything with lex, and I'm rusty enough >that I can't immediately see what's wrong (or even what's meant to be >happening!) You want to look at dtimep.c (the generated output from dtimep.lex). And from the 1.4 tarball ... yes, it's in there. Well, specifically, there is this: #define YY_DECL struct tws *dparsetime(char *lexstr) And YY_DECL is used as a function prototype later for the scanner. So I'm puzzled by this one. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
