Subject: Re: Can't compile pine 3.91 under solaris 2.3 and g cc

From: [email-masked] (Neil Rickert)
Date: 19 Oct 1994 14:37:21 -0500

In <[email-masked]> [email-masked] (Carlos Reed) writes:

>It can't compile pico and pine, with pine I get an error before making
>the addresbook object.

Yes.  It is a pain.

The authors seem to have the insane idea that one can #include a few
system header files, then #define const  (i.e. redefine 'const' to
the empty string), and finally #include other header files.  The
compiler didn't like the type incompatibilities that this
introduced.

>Does any body had experienced this problem, is there any work orund to
>compile it under solaris 2.3 and gcc ?

Here are the changes I made:

In order to build the system, I used the command:

	./build sol CC=gcc LDCC=gcc OPTIMIZE=-O DEBUG=

But, before doing that, I made the following code changes:

[I also made an additional change to redefine the location of
the 'active' file]

--- 1.1	1994/10/12 21:26:06
+++ pine/osdep/os-sv4.h	1994/10/12 21:27:34
@@ -187,7 +187,7 @@
 /*----------------- Are we ANSI? ---------------------------------------*/
 /* #define ANSI          /* this is an ANSI compiler */
 
-#define	const		/* compiler doesn't support const */
+/* #define	const		/* compiler doesn't support const */
 
 /*------ If our compiler doesn't understand type void ------------------*/
 /* #define void char     /* no void in compiler */
@@ -245,8 +245,8 @@

 /*-------------- qsort argument type -----------------------------------*/
-/* #define QSType void  /* qsort arg is of type void * */
-#define QSType char  /* qsort arg is of type char * */
+#define QSType void  /* qsort arg is of type void * */
+/* #define QSType char  /* qsort arg is of type char * */

--- 1.1	1994/10/12 22:01:08
+++ pine/headers.h	1994/10/12 22:01:37
@@ -72,7 +72,7 @@
 #include "os.h"
 
 #ifndef ANSI
-#define const  /* For mail.h  */
+/* #define const  /* For mail.h  */
 #endif
 #include "../c-client/mail.h"
 #include "../c-client/osdep.h"
--- 1.1	1994/10/12 21:50:41
+++ imap/non-ANSI/c-client/Makefile	1994/10/12 21:51:08
@@ -181,7 +181,7 @@
 sol:	# Solaris
 	$(MAKE) mtest OS=sv4 EXTRADRIVERS="$(EXTRADRIVERS)" \
 		STDPROTO=bezerkproto \
-		RSHPATH=/usr/bin/rsh CFLAGS="-g -Dconst= $(EXTRACFLAGS)" \
+		RSHPATH=/usr/bin/rsh CFLAGS="-O $(EXTRACFLAGS)" \
 		RANLIB=true LDFLAGS="-lsocket -lnsl -lgen"
 
 ssn:	# Secure SUN-OS

---

From: [email-masked] (George Lindholm)
Date: 19 Oct 1994 13:46:17 -0700

>compile it under solaris 2.3 and gcc ?

Yeah. I ended up creating a new target called slg (SoLaris Gcc) that does
all the right things. I'll try and get a patch put together that I'll post.

   George

-- 
George Lindholm                                  phone:    (604) 822-4375
University Computing Services, UBC               fax:      (604) 822-5116
6356 Agricultural Road, Vancouver, B.C., Canada  internet: [email-masked]
V6T 1Z2

---

From: [email-masked] (Randall S. Winchester)
Date: 20 Oct 94 14:33:51 GMT

I did not send this to the news group, yesterday when I replied, but if you
use;
 CC="gcc -traditional" LDCC=gcc 
you should not have much of a problem with the build. I did not need to 
patch anything, except I just edited pi*/makefile.sol and c-client/Makefile
by hand, but mostly because of other reasons. I am using Pine/Imapd with 
kerberos support.

Randall

---

From: Ed Greshko <[email-masked]>
Date: Sat, 29 Oct 1994 22:12:19 -0800 (GMT)

> compiler didn't like the type incompatibilities that this

	Considering a previous thread, we all know how much you 
dislike pine.  (Wonder why you seemingly waste you time on something you
seemingly detest.)  But, if you are going to answer questions in this
group it would be refreshing if you would refrain from launching into
an unprovoked diatribe.

	Your suggestions may hold merit.  Yet, you should try something
called "constructive criticism".

	Regards,

			Ed

Edward M. Greshko                       Technical Manager, Electronic Commerce
                                        Control Data Asia/Pacific Region
Voice: +886-2-715-2222 x287             6/F, 131 Nanking East Road, Section 3
FAX  : +886-2-712-9197                  Taipei, Taiwan R.O.C

---

From: Neil W Rickert <[email-masked]>
Date: Sat, 29 Oct 1994 10:18:50 -0500

>called "constructive criticism".

 -NWR

I tried that method.  I privately reported this problem on 3.90.  I
received a polite reply suggesting 3.91 would be better.  Given that
3.91 was no better, and perhaps worse, I am resorting to public
embarrassment as the only available constructive method.

'#define const' is an ugly hack.  It should never appear in public
releases.  At least put 'CONST' in place of 'const' in all of your
own declarations, and control it with '#define CONST'.  Redefining a
standard keyword is a terrible practice.

 -NWR