#824 v4.5 wxt_gui.cpp problems with Sun Studio 12.1

[Anonymous]

I am attempting to build the latest development version (12/16/09) of gnuplot using Sun Studio 12.1, and wxGTK-2.8.10 (with patches applied from http://trac.wxwidgets.org/ticket/10660\). During the make process, I get errors during the compilation of wxterminal/wxt_gui.cpp that look like the same kinds of errors I got when trying to build wxGTK before adding the patches. I see that someone came up with a patch for gnuplot 4.2.6 that addressed these issues (Bug Tracker ID: 2883574). Has someone come up with an analogous patch for v4.5? The source for wxt_gui.cpp seems to have removed references to the _T( ) macro, so I'm not sure why I'm still seeing conflicts [/opt/sunstudio12.1/prod/include/CC/Cstd/./memory line 107, etc.].

Don

[Ethan Merritt]

I am confused.
The patch intended to fix building with Sun Studio was applied to 4.4 and 4.5, but not to 4.2. But you are saying that 4.2.6 works and 4.5 does not? I think you will need to provide the complete error messages. The one you quote above refers only to a system include file, not to a gnuplot source file.

[Anonymous]

make errors with wxt_gui.cpp

[Anonymous]

I only references v4.2.6 because it seemed like someone had similar issues with wxt_gui.cpp and Sun Studio with that version and found a patch that worked for ID: 2883574. I have not tried v4.2.6 + patch to see if it works because we need the functionality of v4.5 for our task. While the errors are in system include files, if you look at the line referenced in the error message, it has the _T( ) macro, which indicated to me that it was another wxt vs. Sun Studio issue.

[Anonymous]

I've attached a text file with the make errors.

[Ethan Merritt]

There are no _T() macros remaining in the gnuplot source code to either version 4.4 or 4.5.

Can you persuade the Sun compiler to produce more informative output? Even in the full listing you attached, there are no line references to indicate the problem site in the actual gnuplot source code. Until, that is, it starts complaining about the "mouse.h" header file and the lack of a definition for _Bool. That seems to indicate the problem may be with the definition of TBOOLEAN, but I can't tell whether this is also the cause of the earlier error messages. Also, I would have thought that a problem with booleans would have produced error messages in many gnuplot files, not just wxt_gui. I'm afraid that without more informative error messages, I don't know where to look for the problem.

[Anonymous]

wxt_gui.cpp make errors with --verbose=all flag passed to CC

[Anonymous]

I uploaded the output of make with the --verbose=all flag passed to the Sun compiler. As you mention below, the errors seem to be centered around the lack of a _Bool definition.

[Ethan Merritt]

The relevant lines seem to be these, from syscfg.h:
#if HAVE_STDBOOL_H
# include <stdbool.h>
#else
# if ! HAVE__BOOL
# ifdef __cplusplus
typedef bool _Bool;
# else
typedef unsigned char _Bool;
# endif
# endif
# define bool _Bool
# define false 0
# define true 1
# define __bool_true_false_are_defined 1
#endif

They are supposed to guarantee that _Bool is defined, but for some reason this is failing on your machine. You would have to look deeper into the output of the configure script to determine, for example, if HAVE_STDBOOL_H was set during configuration, and you would have to look in your system's stdbool.h header to see if it indeed contains a definition for _Bool.

It is possible that everything will work correctly if you replace the definition of TBOOLEAN on line 443 in syscfg.h:
/* #define TBOOLEAN bool */
#define TBOOLEAN unsigned char

[Anonymous]

make errors after syscfg.h mod

[Anonymous]

system stdbool.h

[Anonymous]

Thank you for looking into this!

I searched in config.log for HAVE_STDBOOL_H and did not find it. Searching instead for STDBOOL, I found the following messages:

Checking for stdbool.h that conforms to c99
/opt/sunstudio12.1/bin/cc -c -g -I/usr/openwin/include/conftest.c>&5
"usr/include/stdbool.h", line 42:#error: "use of <stdbool.h> is valid only in a c99 compilation environment."
cc: acomp failed for conftest.c
.
.
.
ac_cv_header_stdbool_h=no

I looked into the stdbool.h file referenced above and it seems to define bool as _Bool. I've attached it.

I made your suggested mod to syscfg.h and that did clear up the prior make errors from mouse.h etc., but there were more _Bool errors in wxterminal/wxt_gui.h. I've attached a text file with the make error messages after the mod.

[Ethan Merritt]

> Checking for stdbool.h that conforms to c99
> /opt/sunstudio12.1/bin/cc -c -g -I/usr/openwin/include/conftest.c>&5
> "usr/include/stdbool.h", line 42:#error: "use of <stdbool.h> is valid only
> in a c99 compilation environment."
> cc: acomp failed for conftest.c

Could this be telling you that you need an additional flag in CFLAGS to enable c99 support?
I don't know exactly what that flag would be, but I would look for compiler options like -c99 or -std=c99.
You may also need to add -xCC in this case.

[Anonymous]

There is indeed a flag for the sun studio C compiler to force C99 compatibility (-xc99). I added this to the configuration command line (e.g. ./configure CC="/opt/sunstudio12.1/bin/cc -xc99" ...), and the resulting config.log does end up with HAVE_STDBOOL_H 1. However, the same error occurs during make where it complains about stdbool.h and c99 when compiling wxt_gui.cpp. This seems to be because CC, not cc, is called when compiling wxt_gui.cpp, and there is no C99 compatibility flag for the C++ compiler.

[Anonymous]

Whoops! I mispoke. Their C++ compiler does have a flag to force C99 compatibility (-xlang=c99), however even adding that to the configure command line (e.g. ./configure ... CXX="/opt/sunstudio12.1/bin/CC -xlang=c99 --verbose=all" ...) still produces the same error during make.

[Ethan Merritt]

That seems wrong.
The section of header code that I quoted before is supposed to be detecting this and executing the lines
#ifdef __cplusplus
typedef bool _Bool;

If you could sort out what combination of tests and flags is causing the logic to fail, that might tell us how to fix it.

On the basis of the log output you sent, I am guessing that the following patch would fix things for you. Possibly you need to go back to not including the -xc99 flag. But it isn't an answer to the question of how to make the auto-configuration work properly on its own.

--- gnuplot/src/syscfg.h 2008-09-10 11:12:34.000000000 -0700
+++ gnuplot-sunstudio/src/syscfg.h 2010-01-05 12:48:27.000000000 -0800
@@ -440,6 +440,7 @@ typedef unsigned char _Bool;
#undef FALSE
#define FALSE false

+#define bool unsigned char
#define TBOOLEAN bool

#endif /* !SYSCFG_H */

[Anonymous]

excerpt from config.log for HAVE__BOOL test.

[Anonymous]

When configuring without C99 flags, I end up with HAVE__BOOL defined as 1, and HAVE_STDBOOL_H undefined. I'm not sure how the HAVE__BOOL test could actually fail, though, based upon the relevant excerpt from the config.log (see attached).

I tried commenting out the test on HAVE__BOOL in syscfg.h to see what would happen, and received a make error there, which implied that it WAS defined somewhere. However, the error occurred on the #else part of the #ifdef __cplusplus, which makes no sense to me. The C++ compiler should be used.

[Ethan Merritt]

OK, how about this: If you can

(1) confirm that adding the line
#define bool unsigned char
is sufficient to produce a working executable in Sun Studio

and
(2) find some preprocessor symbol that indicates the Sun Studio compiler is being used

then we can add this as a special case. Something like
#if defined(SUN_STUDIO_CC) && !defined(bool)
#define bool unsigned char
#endif

[Ethan Merritt]

Does the attached patch help any?
If not, can you suggest a different preprocessor macro that might serve to detect the Sun Studio environment?

[Ethan Merritt]

Possible fix. Please test and report back.

[Ethan Merritt]

No further feedback. Put this patch into CVS and wait for fallout