Hi Andrew:
If I specify
export CFLAGS='-O3 -std=c99 -pedantic -Wall -Wextra
-Wmissing-prototypes -Wstrict-prototypes -Wnested-externs -Wconversion
-Wshadow -Wcast-qual -Wcast-align -Wwrite-strings'
(a combination of options which you recommended in 2011 for testing our code)
and attempt to build PLplot from scratch, the xwin device driver fails
to build with gcc.
After that error, I attempted to build xwin using "make VERBOSE=1
xwin", and again the error occurred. I then replicated that build
command by hand, and did some experimentation with removing
gcc options until I discovered that the critical flag above
that caused the xwin build error was
-std=c99.
The bits of code in xwin.c that appear to be relevant
to the error with --std=c99 are the following:
#ifdef PL_HAVE_PTHREAD
#include <pthread.h>
#include <signal.h>
....
#ifdef PL_HAVE_PTHREAD
static void
events_thread( void *pls )
{
if ( usepthreads )
{
PLStream *lpls = (PLStream *) pls;
XwDev *dev = (XwDev *) lpls->dev;
XwDisplay *xwd = (XwDisplay *) dev->xwd;
PLStream *oplsc;
struct timespec delay;
XEvent event;
long event_mask;
sigset_t set;
....
The compiler chokes on that last sigset_t type for --std=c99 (as if
the above #include <signal.h> was never seen), but checking with
plplot_config.h, PL_HAVE_PTHREAD is not defined so gcc --std=c99
should just ignore both the #include <signal.h> and the above events_thread
code.
Furthermore if I just replace that with -std=gnu99 (c99 + some
GNU extensions to that standard) in the hand compilation
the build error goes away.
Note the hand-compilation qualifier above since it turns out if I
build from scratch with the above CFLAGS except that c99 is replaced
by gnu99, then PL_HAVE_PTHREAD is #defined properly, and under those
circumstances as well, xwin builds without issues. That change in
PL_HAVE_PTHREAD delivered by our build system depending on whether c99
or gnu99 is used is an additional symptom which might or might not be
related to the above issue exposed by hand-crafted compilations for a
given build-system environment.
Anyhow, from these symptoms for hand-crafted compilations for a build that
had PL_HAVE_PTHREAD undefined, I am pretty sure I am encountering a gcc bug in
how --std=c99 (but not --std=gnu99) is implemented because I don't see
how a GNU extension could normally affect whether the pre-processor
ignores #ifdef PL_HAVE_PTHREAD in one part of the xwin code but not in
other parts.
My gcc version details are
irwin@raven> gcc --version
gcc (Debian 4.9.2-10) 4.9.2
....
I would appreciate you and others here attempting to replicate this issue with
whatever gcc version you have access to, and if you feel there
is some other obvious explanation of this issue, please let me know.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
