#1144 Wrong autotonf detection of _Bool still in 4.6.0

Other (155)


the error reported in #3129839 still persists in gnuplot 4.6.0 on Solaris 10 Sparc with Sun Studio 12u1. The described workaround still works. Please let me know if you need access to a Solaris system, lots of GNU projects already do so:

Best regards -- Dago


  • Mojca Miklavec

    Mojca Miklavec - 2012-07-11

    Which "described workaround" are you talking about?

    I also had problems with _Bool on Mac OS X in 4.6.0, but the problem goes away as soon as newer version of autotools is used to generate ./configure script (the person who runs ./prepare script needs a newer version of autotools). Ethan said that he upgraded the tools on his machine where he generates configure script before the release.

    That said, I'm not sure if you are experiencing the same problem as I did. You can take a look at this patch on Mac OS X (ignoring the Carbon-specific patches): http://trac.macports.org/browser/trunk/dports/math/gnuplot/files/patch-configure-qt.diff

  • Mojca Miklavec

    Mojca Miklavec - 2012-07-11

    Can you please explain more details:
    - which version of Solaris (9, 10, 11)
    - which C & C++ compiler, or any other relevant parameters/flags that you set while compiling (without the explicit flag to override results of configure)
    - what is the expected behaviour of
    checking for stdbool.h that conforms to C99... [yes|no]
    checking for _Bool... [yes|no]
    and what is the answer that you get and believe to be wrong.
    - what exactly happens/what is the error (apart from wrong detection of _Bool presence)/how can one reproduce it

  • Mojca Miklavec

    Mojca Miklavec - 2012-08-24

    I now tried to use

    CC=/opt/SUNWspro/bin/cc \ CXX=/opt/SUNWspro/bin/CC \ PKG_CONFIG_PATH=/opt/csw/lib/pkgconfig \ CFLAGS="-L/opt/csw/lib" \ LDFLAGS="-R/opt/csw/lib" \ ./configure

    The problem is the following: C knows about _Bool, while C++ doesn't. Convincing the configure script to believe that _Bool is missing is easy in principle (provided that C++ exists on machine at all), you just do the test with C++:


    The function AM_STDBOOL_H seems to work properly to me.

    But after I do this, the build still fails, only with C this time:

    /opt/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I.. -I../term -I../term -DBINDIR=\"/usr/local/bin\" -DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/4.7\" -DQT_DRIVER_DIR=\"/usr/local/libexec/gnuplot/4.7\" -DGNUPLOT_SHARE_DIR=\"/usr/local/share/gnuplot/4.7\" -DGNUPLOT_PS_DIR=\"/usr/local/share/gnuplot/4.7/PostScript\" -DGNUPLOT_JS_DIR=\"/usr/local/share/gnuplot/4.7/js\" -DGNUPLOT_LUA_DIR=\"/usr/local/share/gnuplot/4.7/lua\" -DCONTACT=\"gnuplot-bugs@lists.sourceforge.net\" -DHELPFILE=\"/usr/local/share/gnuplot/4.7/gnuplot.gih\" -DGNUPLOT_X11=\"`echo gnuplot_x11 | sed 's,x,x,'`\" -DXAPPLRESDIR=\"/etc/X11/app-defaults/\" -I/usr/openwin/include -I/opt/csw/include -I/opt/csw/include -D_REENTRANT -D_PTHREADS -I/opt/csw/include/cairo -I/opt/csw/include/pango-1.0 -I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -D_REENTRANT -D_PTHREADS -I/opt/csw/include/cairo -I/opt/csw/include/pango-1.0 -I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -L/opt/csw/lib -c alloc.c
    "syscfg.h", line 349: invalid type combination
    "syscfg.h", line 349: warning: useless declaration
    "syscfg.h", line 349: warning: typedef declares no type name
    cc: acomp failed for alloc.c
    gmake[3]: *** [alloc.o] Error 2

    The build continued if I commented out the line

    typedef unsigned char _Bool;

    which gets executed when in C and when _Bool is not defined (when it's defined, nothing happens).

    The only sane workaround I can imagine is defining HAVE_C__BOOL and HAVE_CXX__BOOL separately. This would probably need an extension to AM_STDBOOL_H macro, or at least running the macro twice and storing the value for C and C++ compilers separately into different variables.

    (Your workaround seems to suggest that if compiler figures out that _Bool is missing the code works, but that doesn't agree with my observation on Solaris 9 Sparc. The C compiler chucks.)

    The other option is hardcoding the knowledge about (non-)existance of _Bool on Solaris somewhere ... but I have no idea where, and it would be awfully ugly no matter what.

    Further on, wxt fails to compile for me anyway.

  • Mojca Miklavec

    Mojca Miklavec - 2012-08-27

    It turns out that mac users with Xcode 2.4 have the same problem (just reported on the MacPorts users mailing list):

    checking for stdbool.h that conforms to C99... no
    checking for _Bool... yes

    and then _Bool is undefined in C++.

    Something really has to be done about it.

  • Mojca Miklavec

    Mojca Miklavec - 2012-08-28

    The following code for src/syscfg.h fixes the problem for me, but I'm not confident that it really works in all situations:

    # include <stdbool.h>
    # ifndef __cplusplus
    # if ! HAVE__BOOL
    typedef unsigned char _Bool;
    # endif
    # define bool _Bool
    # endif
    # define false 0
    # define true 1
    # define __bool_true_false_are_defined 1

  • Bastian Märkisch

    There may be a related issue on Windows: MSVC chokes on the definition bool in syscfg.h when compiling C++ code.
    See also [patches:#600]



    Patches: #600

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks