On Sat, Oct 08, 2011 at 11:45:52AM -0700, Alan Irwin wrote: > On 2011-10-08 15:55+0100 Andrew Ross wrote: > > >>> If I try the java build with the above CXXFLAGS and FFLAGS, but with > >>> > >>> export CFLAGS='-O3 -fvisibility=hidden' > >>> > >>> then there are no obvious errors or build warnings with the test_java_psc > >>> or > >>> test_noninteractive targets. > >> > >> Actually, I got ahead of myself there, and in fact there are lots of > >> build warnings about C++ non-standards compliancy in this case as well. > >> > >> So my further tests (until you can figure this out post release) will be > >> with > >> > >> export CFLAGS='-O3 -fvisibility=hidden' > >> export CXXFLAGS='-O3 -fvisibility=hidden' > >> export FFLAGS='-O3' > > > > Alan, > > > > I'll add it to my list. Currently rather snowed under with work. I > > urgently need to update the Debian packages. This will be next > > priority. > > Understood, and thanks for putting this on your ToDo list.
I have taken an initial look at this. It's a whole can of worms! Firstly, I can reproduce your java crashes with openjdk or sun jdk but not with gcj. This is a little odd. The backtraces are not entirely helpful but it appears to be related to fprintf calls in the C part of the bindings. It is also not entirely reproducible, i.e. the same example won't segfault every time. A better start is probably to work through the huge number of compiler warnings. Aside from the java issues there are a number of other issues I encountered. Several parts of plplot use features which are POSIX standard, but not part of the 1999 ISO C standard. strdup is one example, also some of the signal handling in xwin / tk drivers. The latter is not an issue since these drivers are only available on Unix like systems anyway. This just makes it a pain to compile since either we add compiler defines to allow posix features for the whole compile (not ideal) or we need to add specific compile flags for specific files which is not too easy in cmake (at least not in a quick and dirty way). FFLAGS is used for both f77 and f95 compiles which makes it hard to tailor the flags for different standards. Again, it is a limitation of cmakes handling of these things. In terms of the warnings themeselves, there are a lot related to implicit casting of int / uint / size_t. We can make this clean either by being consistent about types (best, but intrusive) or by explicit casting (which hides the problem! - but in most cases we know it is ok anyway). There are also warnings about assigning constant strings to non-const char * arrays. On the whole changing to const char * fixes this and is relatively straightforward. We don't always use prototypes for functions. Again, this is relatively easy to fix if we feel it is serious enough. It is probably good form to do so anyway. Unused parameters appear in a fair number of places. In function definitions I would tend to leave these in for clarity, even if they are not strictly necessary. Possibly uninitialized variables also appear. In all the cases I've looked at they were actually ok, but were defined inside some if ... else ... statements which the compiler cannot analyse to check they are set. Probably good form to set them explicitly to some default / null value to avoid future problems. The recent issue Alan found with qsastime is a good example of this. A number of external libraries we use (e.g. wxwidgets, cairo, python) have headers which are not clean. A favourite seems to be using "long long" which is not in ISO C++ 1998. Hard to do much about this. SWIG generated code is not very clean, which again might be tricky to deal with. Lots of examples of local variables shadowing a global variable or typedef. Probably safe, but generally not good practice. So, in short there are some possible real issues and a fair bit of noise. I've started some work tidying up bits of the code, but I certainly won't commit anything until after the next release as it is going to be pretty intrusive. Once I've cleaned up the easy parts, we can discuss what to do about the more tricky warnings. Andrew ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
