Re: [nmh-workers] nmh 1.7.1 compile errors
>Apparently, the Sun compiler has sprouted internal support for 'bool'. I really thought stdbool.h was part of the standard; if we detect that then the right things should happen. --Ken -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] nmh 1.7.1 compile errors
On Mon, 03 Jun 2019 15:58:18 -, masud.anw...@hmrc.gsi.gov.uk said: > I get the following compile errors compiling on solaris 10 - sparc and I'm > not sure how to resolve it. > Sun Compiler developer studio ansi C compiler > "/usr/include/curses.h", line 86: invalid type combination > 85 #if !defined(__cplusplus) && !defined(_BOOL) > 86 typedef char bool; > 87 #endif /* !defined(__cplusplus) && !defined(_BOOL) */ Apparently, the Sun compiler has sprouted internal support for 'bool'. Adding -D_BOOL to the CCFLAGS should work around this, but I'm not sure what you're using to configure/build nmh, so it's unclear where the best place to add it is. Anybody else still using Solaris 10 with either gcc or the Sun compiler? We'll need some testing to make sure if we add this to the autoconfigure stuff, we don't break it for other Solaris/compiler combinations... pgpWXr88gPfCn.pgp Description: PGP signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] nmh 1.7.1 compile errors
>"/usr/include/curses.h", line 86: invalid type combination Quick question: does this compiler have a stdbool.h header file? If it does, does autoconf find it? (This answer should be in the configure output). I suspect that it does NOT, and you are running afoul of the following defintions in h/nmh.h: #ifdef HAVE_STDBOOL_H # include #else # define bool int # define true 1 # define false 0 #endif So that would make that line in curses.h: typedef char int Which would probably explain the exact error you are getting. So, solutions? Weeelll we use bool a lot, actually. It looks like bool was added in C99, so maybe adding -std=c99 to the compiler options would work? (be sure you do that and re-run configure). It might be the compiler doesn't "see" stdbool.h unless you do -std=c99. I suspect using gcc would also work. That may not be right answer, as I think the default is -std=c11. You could also try adding -D_BOOL=1 to CPPFLAGS. I don't know why older versions don't compile; support for bool was only added in nmh 1.7. It would probably be best to focus on the newest versions though. --Ken -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] nmh 1.7.1 compile errors
On Mon, 03 Jun 2019 15:58:18 -, masud.anw...@hmrc.gsi.gov.uk said: > 73 * bool is a built-in type in standard C++ and as such is not > 74 * defined here when using standard C++. However, the GNU compiler > 75 * fixincludes utility nonetheless creates it's own version of this > 76 * header for use by gcc and g++. In that version it adds a redundant > 77 * guard for __cplusplus. To avoid the creation of a gcc/g++ specific > 78 * header we need to include the following magic comment: Didn't fixincludes pass into the realm of myth and legend quite a while ago? (Which is why I'm worried that this is brittle system code that breaks all too easily...) pgpGdk2ZdYq5w.pgp Description: PGP signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] nmh 1.7.1 compile errors
Hi Masud, > cc -DHAVE_CONFIG_H -I. -I./sbr > -DNMHBINDIR='"/export/home/edcs/nmh/bin"' > -DNMHLIBEXECDIR='"/export/home/edcs/nmh/libexec/nmh"' > -DNMHETCDIR='"/export/home/edcs/nmh/etc/nmh"' > -DNMHDOCDIR='"/export/home/edcs/nmh/share/doc/nmh"' > -DMAILSPOOL='"/var/mail"' -DSENDMAILPATH='"/usr/sbin/sendmail"' > -g -v -errtags=yes -erroff=E_STATEMENT_NOT_REACHED -Wall -Wextra > -c -o sbr/sbr_libmh_a-terminal.o `test -f 'sbr/terminal.c' || echo > './'`sbr/terminal.c > "/usr/include/curses.h", line 86: invalid type combination > cc: acomp failed for sbr/terminal.c ... > 85 #if !defined(__cplusplus) && !defined(_BOOL) > 86 typedef char bool; > 87 #endif /* !defined(__cplusplus) && !defined(_BOOL) */ Can you confirm config.h doesn't have HAVE_STDBOOL_H #defined? h/nmh.h does #ifdef HAVE_STDBOOL_H # include #else # define bool int # define true 1 # define false 0 #endif and that's probably upsetting things. Does your Solaris C compilation environment have a stdbool.h? Is gcc available? -- Cheers, Ralph. -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
[nmh-workers] nmh 1.7.1 compile errors
Hi,
I get the following compile errors compiling on solaris 10 - sparc and I'm not
sure how to resolve it.
We are currently using version 1.3 and are looking to move to a later version
as we seems to be having some issues with nmh.
version 1.5 compiles,
version 1.6 fails
as does version 1.7.1 see the trace below for 1.7.1.
Sun Compiler developer studio ansi C compiler
Would anyone be able be help. Please.
.
.
.
.
.
cc -DHAVE_CONFIG_H -I. -I./sbr -DNMHBINDIR='"/export/home/edcs/nmh/bin"'
-DNMHLIBEXECDIR='"/export/home/edcs/nmh/libexec/nmh"'
-DNMHETCDIR='"/export/home/edcs/nmh/etc/nmh"'
-DNMHDOCDIR='"/export/home/edcs/nmh/share/doc/nmh"' -DMAILSPOOL='"/var/mail"'
-DSENDMAILPATH='"/usr/sbin/sendmail"' -g -v -errtags=yes
-erroff=E_STATEMENT_NOT_REACHED -Wall -Wextra -c -o sbr/sbr_libmh_a-terminal.o
`test -f 'sbr/terminal.c' || echo './'`sbr/terminal.c
"/usr/include/curses.h", line 86: invalid type combination
cc: acomp failed for sbr/terminal.c
make[1]: *** [Makefile:4332: sbr/sbr_libmh_a-terminal.o] Error 2
make[1]: Leaving directory '/export/home/edcs/nmh-1.7.1'
make: *** [Makefile:1643: all] Error 2
/usr/include/curses.h
1 /*
2 * Copyright (c) 1988, 2012, Oracle and/or its affiliates. All rights
reserved.
3 */
4
5 /* Copyright (c) 1988 AT&T */
6 /*All Rights Reserved */
7
8 /* THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T */
9 /* The copyright notice above does not evidence any*/
10 /* actual or intended publication of such source code. */
11
12 #ifndef _CURSES_H
13 #define _CURSES_H
14
15 #pragma ident "@(#)curses.h 1.3204/04/29 SMI" /* SVr4.0 1.58
*/
16
17 /*
18 * curses.h - this file is automatically made from caps and
19 * curses.ed. Don't make changes directly to curses.h!
20 */
21
22 #include
23
24 #include
25
26 #ifdef __cplusplus
27 extern "C" {
28 #endif
29
30 #define CSMAX 4
31
32 /*
33 * This trick is used to distinguish between SYSV and V7 systems.
34 * We assume that L_ctermid is only defined in stdio.h in SYSV
35 * systems, but not in V7 or Berkeley UNIX.
36 */
37 #ifdef L_ctermid
38 #ifdef SYSV
39 #undef SYSV
40 #endif
41 #define SYSV
42 #endif
43 /* Some V7 systems define L_ctermid - we list those here */
44 #ifdef BSD
45 #undef SYSV
46 #endif
47
48 #ifdef SYSV
49
50 #ifndef VINTR
51 #include
52 #endif /* VINTR */
53 typedef struct termio SGTTY;
54 typedef struct termios SGTTYS;
55
56 #else /* !SYSV */
57
58 #ifndef _SGTTYB_
59 #include
60 #endif /* _SGTTYB_ */
61 typedef struct sgttyb SGTTY;
62
63 /*
64 * Here we attempt to improve portability by providing some #defines
65 * for SYSV functions on non-SYSV systems.
66 */
67 #define memcpy(dst, src, len) bcopy((src), (dst), (len))
68 #define strchr index
69 #define strrchr rindex
70 #endif /* SYSV */
71
72 /*
73 * bool is a built-in type in standard C++ and as such is not
74 * defined here when using standard C++. However, the GNU compiler
75 * fixincludes utility nonetheless creates it's own version of this
76 * header for use by gcc and g++. In that version it adds a redundant
77 * guard for __cplusplus. To avoid the creation of a gcc/g++ specific
78 * header we need to include the following magic comment:
79 *
80 * we must use the C++ compiler's type
81 *
82 * The above comment should not be removed or changed until GNU
83 * gcc/fixinc/inclhack.def is updated to bypass this header.
84 */
85 #if !defined(__cplusplus) && !defined(_BOOL)
86 typedef char bool;
87 #endif /* !defined(__cplusplus) && !defined(_BOOL) */
Kind Regards
Masud Anwar
The information in this e-mail and any attachments is confidential and may be
subject to legal professional privilege. Unless you are the intended recipient
or his/her representative you are not authorised to, and must not, read, copy,
distribute, use or retain this message or any part of it. If you are not the
intended recipient, please notify the sender immediately.
HM Revenue & Customs computer systems will be monitored and communications
carried on them recorded, to secure the effective operation of the system and
for lawful purposes.
The Commissioners for HM Revenue and Customs are not liable for any personal
views of the sender.
This e-mail may have been intercepted and its information altered.
If you have any doubt about the authenticity of an email you receive which
claims to come from HM Revenue & Customs (HMRC), please do not follow any links
within the email, disclose any personal details or respon
Re: [nmh-workers] Fixed! I Could Have Sworn that the inc Command used to work.
Ken Hornstein writes: > I had written this long note about how there was NO way that that the > local-mailbox entry would affect that, but I am glad I double checked ... > because I would have been wrong. It totally does! From > sbr/mts.c:getuserinfo(): > > /* If there's a Local-Mailbox profile component, try to extract >the username from it. But don't try very hard, this assumes >the very simple User Name form. >Note that post(8) uses context_foil(), so it won't see the profile >component. */ > > If it finds a username in local-mailbox profile component, then it copies > that over to username and that's returned by getusername() which is > eventually used to construct the default maildrop name. It looks like > that was changed in commit af586ebe59b7, which was back in ... 2012. > Whoops. So yeah, your Local-Mailbox profile entry made it look in > a maildrop file named /var/mail/martin.m. That one is on us! > > Obviously this was an unintended consequence of this change; I > understand why it was done, so the mh-format functions would work > correctly with a Local-Mailbox profile component, but I think we'd all > be in agreement that the default maildrop name should be based on the > local Unix username and NOT what the user places in their Local-Mailbox > profile entry. I think the correct change should be what we did to > LocalName(); add an argument that indicates if you want something that > could come out of a config file or ONLY the Unix username. Thoughts? Wow! I am so glad I read all the rest of the messages in this thread. It makes me feel less clueless. For now, I will consider this problem solved and move on to creating new ones^H^h^H did I say that? Anyway, thanks, everyone. Martin McCormick WB5AGZ -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] I Could Have Sworn that the inc Command used to work.
>That seems worse. Linux's getlogin(3) says in Description that $LOGNAME >is often more useful, and its Bugs section is an amusing read. >getlogin(3p) from POSIX is also available for detail. I'm not so crazy on using getlogin() since this function can be called by nmh programs that do not have a controlling terminal. >getlogin() copes with multiple usernames for the same ID and finds the >one used on this controlling terminal, checking FDs 0-2 until ‘success’ >and crawling utmp. That's overkill for our purposes. $LOGNAME is in >our memory and a function call away, plus it's easy to document and >useful to override. It sure does seem like the overarching lesson from this is "think carefully about any change you make to nmh since unintended consequences abound". getusername() (the nmh function) is called by programs like slocal and rcvtty, which may not have a controlling terminal and I am unclear what LOGNAME would mean in their environment as well. We could do something like call isatty(0) before falling back to LOGNAME, but then I'd have to ask "exactly WHY are we doing that?". I am thinking that falling back to getpwuid(getuid()) is the most reasonable approach, for the following reasons: - My vague impression is that this is what most other programs who want this information do. - It is consistent with MH historical practice and is thus likely to have the fewest unintended consequences - Should generally work across program execution environments - Even though it might be useful to override the username with an environment variable, AFAICT the actual use of the username can be overridden by a command line switch in all programs that call getusername(). Thoughts? --Ken -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] I Could Have Sworn that the inc Command used to work.
Hi Bakul, > > Should we simplify the code to demand $LOGNAME exists and use that? > > You can use getlogin(3) or getlogin_r(3) as per ISO/IEC 9945-1:1996. That seems worse. Linux's getlogin(3) says in Description that $LOGNAME is often more useful, and its Bugs section is an amusing read. getlogin(3p) from POSIX is also available for detail. getlogin() copes with multiple usernames for the same ID and finds the one used on this controlling terminal, checking FDs 0-2 until ‘success’ and crawling utmp. That's overkill for our purposes. $LOGNAME is in our memory and a function call away, plus it's easy to document and useful to override. -- Cheers, Ralph. -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] I Could Have Sworn that the inc Command used to work.
On Mon, 03 Jun 2019 09:08:16 +0100 Ralph Corderoy wrote: > Hi Ken, > > > > /var/mail/$USER Location of the system mail drop. > > > > But we don't actually use $USER (we call getpwuid(getuid()) and use > > that). > > And even then it's not that simple. > > > I personally interpreted the use of $USER as "the username goes here", > > not "we use the value of the $USER environment variable". But I admit > > that this is not clear. > > I'd interpret it as being able to do `USER=notme inc'. > > Should we simplify the code to demand $LOGNAME exists and use that? > POSIX, he say > > LOGNAME > The system shall initialize this variable at the time of login > to be the user's login name. See . For a value of > LOGNAME to be portable across implementations of POSIX.1-2017, > the value should be composed of characters from the portable > filename character set. You can use getlogin(3) or getlogin_r(3) as per ISO/IEC 9945-1:1996. -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] I Could Have Sworn that the inc Command used to work.
Hi Ken, > > /var/mail/$USER Location of the system mail drop. > > But we don't actually use $USER (we call getpwuid(getuid()) and use > that). And even then it's not that simple. > I personally interpreted the use of $USER as "the username goes here", > not "we use the value of the $USER environment variable". But I admit > that this is not clear. I'd interpret it as being able to do `USER=notme inc'. Should we simplify the code to demand $LOGNAME exists and use that? POSIX, he say LOGNAME The system shall initialize this variable at the time of login to be the user's login name. See . For a value of LOGNAME to be portable across implementations of POSIX.1-2017, the value should be composed of characters from the portable filename character set. -- Cheers, Ralph. -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
