On Sat, 16 Dec 2000 19:26:02 -0800 (PST), Ti Kan wrote:

>As promised I downloaded 0.92.1 and tested with UnixWare's cc instead of
>gcc.  Things actually went mostly well after I hit a snag.  I was getting
>symbol undefined errors for _Xconst in various libXm files.  I went
>looking and found that _Xconst is defined in <X11/Xfuncproto.h> as follows:
>
>------------------
>#ifndef NeedFunctionPrototypes
>#if defined(FUNCPROTO) || __STDC__ || defined(__cplusplus) || defined(c_plusplus)
>#define NeedFunctionPrototypes 1
>#else
>#define NeedFunctionPrototypes 0
>#endif
>#endif /* NeedFunctionPrototypes */
>
>...
>
>#if NeedFunctionPrototypes
>
>#ifndef _Xconst
>#if __STDC__ || defined(__cplusplus) || defined(c_plusplus) || (FUNCPROTO&4)
>#define _Xconst const
>#else
>#define _Xconst
>#endif
>#endif /* _Xconst */
>
>...
>------------------
>
>I found that NeedFunctionPrototypes was not being set to 1, therefore
>the _Xconst definition wasn't being exposed.  I looked further and found
>that UnixWare's cc compiler defines __STDC__, but sets its value to 0.
>It's set to 1 only if cc -Xc option is used.   This is in contrast to gcc
>where the default has __STDC__ defined to be 1.
>
>I also checked the <X11/Xfuncproto.h> on Linux and found the code is like
>this:
>
>------------------
>#ifndef NeedFunctionPrototypes
>#if defined(FUNCPROTO) || defined(__STDC__) || defined(__cplusplus) || 
>defined(c_plusplus)
>                          ^^^^^^^^^^^^^^^^^ note the difference
>#define NeedFunctionPrototypes 1
>...
>------------------
>
>Argh.  That would have worked.  I don't know why USL/SCO made this change.
>But more basically, I think this may be a X11 base problem.  Why should
>_Xconst be defined only when NeedFunctionPrototypes is set to 1?  I would
>think _Xconst should be defined to the appropriate thing under all conditions.
>
>At any rate, I found that if I use cc -Xc I get too many compile warnings,
>because the compiler enforces strict ANSI and there is a lot of code in
>various places that seems to violate that.  I finally decided to add
>-DFUNCPROTO instead, and that made everything compile fine.  I don't know
>whether this is something lesstif's configure script should deal with.
>Maybe it should be in the README or release notes for platform-specific stuff.
[...]

We demand an ANSI conforming compiler and libc for building LessTif.
Our configure has (?!) the standard mechanisms of encouraging compilers
to switch to this mode not more. 

Lots of warnings WRT ANSI violation "can not be" ...
We have now some "ignores const" warnings (caused by the stupid X11 stuff
which still remains pre-ANSI and never uses const even if more than
appropriate) and some cast and comparison problems.
What else is there "wrong"? (ok, that's low priority for now)


---
Alexander Mai
[EMAIL PROTECTED]


Reply via email to