Re: [Plplot-devel] Still roughly on track for a February 12th release of 5.10.0
Hi Alan,
I wrote a small test program to determine where the compile errors with SWIG
were coming from and to ensure that my MinGW/MSYS installation is indeed 32
bits. The program is this:
/* test-compile.c --
Test a few things with regards to the problems to compile SWIG
under MinGW/MSYS
-DSTAT: compile with the "struct stat" structure
In any case: check the size of a pointer
*/
#include
#ifdef STAT
#include
#endif
int main( int argc, char *argv[] ) {
#ifdef STAT
struct stat st;
#endif
printf("Size of pointer: %d\n", sizeof(void *));
#ifdef STAT
printf("Size of struct stat: %d\n", sizeof(st));
#endif
}
I tried building this program under various environments with the -DSTAT flag.
They all succeeded - no compile errors. The output from the programs was rather
varied:
- Cygwin: pointer size 8, struc stat size 128 -- this is a 64-bits environment
- Windows+gcc 4.5.2: pointer size 4, struc stat size 36 -- a 32-bits environment
- Windows+MSVC/C++, 64-bits: pointer size 4, struc stat size 48 -- a 64-bits
environment
- MinGW/MSYS+gcc 4.8.1: pointer size 4, struct stat size 48 - definitely a
32-bits environment!
The error messages with SWIG come from the flag -ansi:
$ gcc -o test-compile test-compile.c -DSTAT -ansi
test-compile.c: In function 'main':
test-compile.c:18:17: error: storage size of 'st' isn't known
struct stat st;
^
The real question is: where is the flag -ansi coming from? It appears together
with -Wall -pedantic in the make files but I can not find its origins anywhere
in PLplot or CMake (I have not checked the CMake executables, assuming all that
sort of flags would be contained in the configuration files instead).
Okay, sofar that analysis. Now I will try your receipe.
Regards,
Arjen
> -Original Message-
> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> Sent: Monday, February 10, 2014 11:24 PM
> To: Arjen Markus
> Cc: PLplot development list
> Subject: Re: [Plplot-devel] Still roughly on track for a February 12th
> release of 5.10.0
>
> Hi Arjen:
>
> Please use the improved epa_build instructions you get with revision 12993.
> I have
> replaced the old ENABLE_COMPREHENSIVE_PLPLOT_TEST cmake option with
> COMPREHENSIVE_PLPLOT_TEST_INTERACTIVE and
> COMPREHENSIVE_PLPLOT_TEST_NONINTERACTIVE to make it more
> convenient to split up interactive and noninteractive testing.
>
> This morning I finally got around to doing
> COMPREHENSIVE_PLPLOT_TEST_INTERACTIVE=ON testing for
> MinGW/MSYS/Wine and I discovered some issues. All but one of those are fixed
> as
> of revision 12993. So for example, the test_c_ntk, test_c_wingcc, and
> test_tclsh_standard_examples targets (all dependencies of the
> test_interactive target)
> all work correctly. However, the test_pltcl_standard_examples target (also
> currently
> a dependency of the test_interactive target) generates an error with message
> "wine:
> Unhandled page fault on read access to 0x00867490 at address 0x867490 (thread
> 0034)" right near the end of the final page of example 33 (or perhaps just
> after that
> final page is completed). So this issue might be similar to
> http://sourceforge.net/p/plplot/bugs/139/. But there the wish environment
> failed while
> the plserver did not show the issue, while for the present case it is pltcl
> that shows
> the issue, while tclsh does not.
>
> I am now wondering whether this is just a Wine issue or a symptom of a a more
> general PLplot memory management issue whenever pltcl, plserver, tclsh, or
> wish
> exit from the standard examples case. Of course, as with any memory management
> issue, you sometimes get symptomless (i.e., good) results despite the memory
> management issue.
> So this hypothesis would explain why we get both good and bad results on
> different
> platforms and depending on whether the standard examples are being run by
> pltcl,
> tclsh, plserver, or wish. But, of course, the variety of results we are
> getting for the
> standard examples do not completely prove the hypothesis so the hypothesis is
> just
> something to keep in mind.
>
> From this bad interactive result for MinGW/MSYS/Wine your priority for this
> release
> should be to make sure
> COMPREHENSIVE_PLPLOT_TEST_NONINTERACTIVE=ON works for the 32-bit
> Windows case like it currently does for MinGW/MSYS/Wine. Your second priority
> after that (if you have time before Wednesday) should be to try
> COMPREHENSIVE_PLPLOT_TEST_INTERACTIVE=ON just to see if the same
> issue I just discovered on Wine shows up on 32-bit Microsoft Windows as well
> or
> whether you can get all the way through the comprehensive interactive tests
> on that
> platform.
>
> 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
Re: [Plplot-devel] Still roughly on track for a February 12th release of 5.10.0
Hi Alan,
I forgot to mention that the flag -ansi does not cause this error message under
Cygwin.
Regards,
Arjen
> -Original Message-
> From: Arjen Markus [mailto:arjen.mar...@deltares.nl]
> Sent: Tuesday, February 11, 2014 10:13 AM
> To: Alan W. Irwin
> Cc: PLplot development list
> Subject: Re: [Plplot-devel] Still roughly on track for a February 12th
> release of 5.10.0
>
> Hi Alan,
>
> I wrote a small test program to determine where the compile errors with SWIG
> were
> coming from and to ensure that my MinGW/MSYS installation is indeed 32 bits.
> The
> program is this:
>
> /* test-compile.c --
>Test a few things with regards to the problems to compile SWIG
>under MinGW/MSYS
>
>-DSTAT: compile with the "struct stat" structure
>
>In any case: check the size of a pointer */ #include
>
> #ifdef STAT
> #include
> #endif
>
> int main( int argc, char *argv[] ) {
>
> #ifdef STAT
> struct stat st;
> #endif
>
> printf("Size of pointer: %d\n", sizeof(void *));
>
> #ifdef STAT
> printf("Size of struct stat: %d\n", sizeof(st)); #endif }
>
>
> I tried building this program under various environments with the -DSTAT
> flag. They
> all succeeded - no compile errors. The output from the programs was rather
> varied:
>
> - Cygwin: pointer size 8, struc stat size 128 -- this is a 64-bits environment
> - Windows+gcc 4.5.2: pointer size 4, struc stat size 36 -- a 32-bits
> environment
> - Windows+MSVC/C++, 64-bits: pointer size 4, struc stat size 48 -- a 64-bits
> environment
> - MinGW/MSYS+gcc 4.8.1: pointer size 4, struct stat size 48 - definitely a
> 32-bits
> environment!
>
> The error messages with SWIG come from the flag -ansi:
>
> $ gcc -o test-compile test-compile.c -DSTAT -ansi
> test-compile.c: In function 'main':
> test-compile.c:18:17: error: storage size of 'st' isn't known
> struct stat st;
> ^
>
> The real question is: where is the flag -ansi coming from? It appears
> together with -
> Wall -pedantic in the make files but I can not find its origins anywhere in
> PLplot or
> CMake (I have not checked the CMake executables, assuming all that sort of
> flags
> would be contained in the configuration files instead).
>
> Okay, sofar that analysis. Now I will try your receipe.
>
> Regards,
>
> Arjen
>
> > -Original Message-
> > From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca]
> > Sent: Monday, February 10, 2014 11:24 PM
> > To: Arjen Markus
> > Cc: PLplot development list
> > Subject: Re: [Plplot-devel] Still roughly on track for a February 12th
> > release of 5.10.0
> >
> > Hi Arjen:
> >
> > Please use the improved epa_build instructions you get with revision
> > 12993. I have replaced the old ENABLE_COMPREHENSIVE_PLPLOT_TEST
> cmake
> > option with COMPREHENSIVE_PLPLOT_TEST_INTERACTIVE and
> > COMPREHENSIVE_PLPLOT_TEST_NONINTERACTIVE to make it more
> convenient to
> > split up interactive and noninteractive testing.
> >
> > This morning I finally got around to doing
> > COMPREHENSIVE_PLPLOT_TEST_INTERACTIVE=ON testing for
> MinGW/MSYS/Wine
> > and I discovered some issues. All but one of those are fixed as of
> > revision 12993. So for example, the test_c_ntk, test_c_wingcc, and
> > test_tclsh_standard_examples targets (all dependencies of the
> > test_interactive target) all work correctly. However, the
> > test_pltcl_standard_examples target (also currently a dependency of the
> test_interactive target) generates an error with message "wine:
> > Unhandled page fault on read access to 0x00867490 at address 0x867490
> > (thread 0034)" right near the end of the final page of example 33 (or
> > perhaps just after that final page is completed). So this issue might
> > be similar to http://sourceforge.net/p/plplot/bugs/139/. But there
> > the wish environment failed while the plserver did not show the issue,
> > while for the present case it is pltcl that shows the issue, while tclsh
> > does not.
> >
> > I am now wondering whether this is just a Wine issue or a symptom of a
> > a more general PLplot memory management issue whenever pltcl,
> > plserver, tclsh, or wish exit from the standard examples case. Of
> > course, as with any memory management issue, you sometimes get
> > symptomless (i.e., good) results despite the memory management issue.
> > So this hypothesis would explain why we get both good and bad results
> > on different platforms and depending on whether the standard examples
> > are being run by pltcl, tclsh, plserver, or wish. But, of course, the
> > variety of results we are getting for the standard examples do not
> > completely prove the hypothesis so the hypothesis is just something to keep
> > in
> mind.
> >
> > From this bad interactive result for MinGW/MSYS/Wine your priority for
> > this release should be to make sure
> > COMPREHENSIVE_PLPLOT_TEST_NONINTERACTIVE=ON works for the 32-bit
> > Windows case like it currently does for MinGW/MSYS/Wine. Your second
> > priority after
Re: [Plplot-devel] Still roughly on track for a February 12th release of 5.10.0
On 2014-02-11 09:12- Arjen Markus wrote: > The error messages with SWIG come from the flag -ansi: > > $ gcc -o test-compile test-compile.c -DSTAT -ansi > test-compile.c: In function 'main': > test-compile.c:18:17: error: storage size of 'st' isn't known > struct stat st; > ^ > > The real question is: where is the flag -ansi coming from? It appears > together with -Wall -pedantic in the make files but I can not find its > origins anywhere in PLplot or CMake (I have not checked the CMake > executables, assuming all that sort of flags would be contained in the > configuration files instead). > Remember, although epa_build is configured with CMake, that is just a convenient but rather thin layer over the configure and build done by a project's native build system. In the swig case, that native build system is autotools, and the configuration is done with a "configure" script that is set up by autotools. That script is where the above flags are coming from. However, those flags gave me absolutely no trouble for the swig build on MinGW/MSYS/Wine. I hope that explanation helps. 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 __ -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Still roughly on track for a February 12th release of 5.10.0
Hi Alan, > -Original Message- > From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca] > > Remember, although epa_build is configured with CMake, that is just a > convenient > but rather thin layer over the configure and build done by a project's native > build > system. In the swig case, that native build system is autotools, and the > configuration > is done with a "configure" > script that is set up by autotools. That script is where the above flags are > coming > from. However, those flags gave me absolutely no trouble for the swig build > on > MinGW/MSYS/Wine. > > I hope that explanation helps. > That does indeed help. I was simply looking in the wrong place. However, if it works for you, then is it possible you have a different version of GCC? Mine is (output from "gcc -v"): Using built-in specs. COLLECT_GCC=c:\mingw\bin\gcc.exe COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=mingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto --enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gmp-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T Thread model: win32 gcc version 4.8.1 (GCC) Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Still roughly on track for a February 12th release of 5.10.0
On 2014-02-11 14:10- Arjen Markus wrote: > Hi Alan, > >> -Original Message- >> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca] >> >> Remember, although epa_build is configured with CMake, that is just a >> convenient >> but rather thin layer over the configure and build done by a project's >> native build >> system. In the swig case, that native build system is autotools, and the >> configuration >> is done with a "configure" >> script that is set up by autotools. That script is where the above flags are >> coming >> from. However, those flags gave me absolutely no trouble for the swig build >> on >> MinGW/MSYS/Wine. >> >> I hope that explanation helps. >> > > That does indeed help. I was simply looking in the wrong place. > > However, if it works for you, then is it possible you have a different > version of GCC? > Mine is (output from "gcc -v"): > > Using built-in specs. > COLLECT_GCC=c:\mingw\bin\gcc.exe > COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/lto-wrapper.exe > Target: mingw32 > Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 > --build=mingw32 --without-pic --enable-shared --enable-static --with-gnu-ld > --enable-lto --enable-libssp --disable-multilib > --enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-sjlj-exceptions > --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug > --enable-version-specific-runtime-libs > --with-gmp=/usr/src/pkg/gmp-5.1.2-1-mingw32-src/bld > --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --with-mpfr= > --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-libgomp > --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/mingw > --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T > Thread model: win32 > gcc version 4.8.1 (GCC) > I used gcc-4.7.2 (see the description of my test in README.release). So that _could_ be a source of a possible difference between us, but that seems fairly unlikely to me. However, in your previous post you did seem able to prove that MinGW was definitely producing 32-bit results for your present environment. And you went on to say > Okay, sofar that analysis. Now I will try your receipe. Does that mean you have gone ahead with the epa_build comprehensive test? If so, what are those results? 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 __ -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Release planned for approximately 24 hours from now
On 2014-02-11 09:41-0800 Alan W. Irwin wrote: > On 2014-02-11 14:10- Arjen Markus wrote: > >> Hi Alan, >> >>> -Original Message- >>> From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca] >>> >>> Remember, although epa_build is configured with CMake, that is just a >>> convenient >>> but rather thin layer over the configure and build done by a project's >>> native build >>> system. In the swig case, that native build system is autotools, and the >>> configuration >>> is done with a "configure" >>> script that is set up by autotools. That script is where the above flags >>> are coming >>> from. However, those flags gave me absolutely no trouble for the swig >>> build on >>> MinGW/MSYS/Wine. >>> >>> I hope that explanation helps. >>> >> >> That does indeed help. I was simply looking in the wrong place. >> >> However, if it works for you, then is it possible you have a different >> version of GCC? >> Mine is (output from "gcc -v"): >> >> Using built-in specs. >> COLLECT_GCC=c:\mingw\bin\gcc.exe >> COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/lto-wrapper.exe >> Target: mingw32 >> Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 >> --build=mingw32 --without-pic --enable-shared --enable-static --with-gnu-ld >> --enable-lto --enable-libssp --disable-multilib >> --enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-sjlj-exceptions >> --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug >> --enable-version-specific-runtime-libs >> --with-gmp=/usr/src/pkg/gmp-5.1.2-1-mingw32-src/bld >> --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --with-mpfr= >> --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-libgomp >> --enable-threads --with-libiconv-prefix=/mingw32 >> --with-libintl-prefix=/mingw --disable-bootstrap LDFLAGS=-s >> CFLAGS=-D_USE_32BIT_TIME_T >> Thread model: win32 >> gcc version 4.8.1 (GCC) >> > > I used gcc-4.7.2 (see the description of my test in README.release). > So that _could_ be a source of a possible difference between us, but > that seems fairly unlikely to me. > > However, in your previous post you did seem able to prove that > MinGW was definitely producing 32-bit results for your present > environment. And you went on to say > >> Okay, sofar that analysis. Now I will try your receipe. > > Does that mean you have gone ahead with the epa_build comprehensive > test? If so, what are those results? Hi Arjen: Never mind. I have reread what you said, and I think I understand it better now. You assumed my new recipe might help out with the swig build issue, but in fact the new recipe only introduces some convenience options for the -DBUILD_THE_BUILDTOOLS=OFF case so should have no effect for the -DBUILD_THE_BUILDTOOLS=ON case (which is used for the swig build). Furthermore, I assumed you were testing a new configuration of your MinGW-4.8.1 compiler, but in fact I now believe you were testing the old configuration that generated the build errors for swig. So basically your tests have proved the swig build issue you have found some time ago was for a 32-bit platform and therefore could not have anything to do with possible 64-bit issues. So now I have done what I should have done long ago which was to do a google search for your swig build error message: unknown type name 'off64_t' The first hit is http://sourceforge.net/p/mingw/bugs/2104/ which is classified as a duplicate of http://sourceforge.net/p/mingw/bugs/2046/. The comments on bug 2046 are interesting. There appears to be no fundamental MinGW 4.8.1 bug here except possibly the need to implement a more user-friendly way to deal with detected violations of compiler standards by the package being compiled (in this case swig) when standards compliancy is being checked by compiling the code with a standards-compliant flag such as -ansi (or -std=c99). Finally there is this quote: FWIW, I also consider it to be a build system bug, when any such conformity checking option is unconditionally applied to a release build; they are intended primarily for developers, to allow them to check for non-conforming usage in their code, so that it may be compiled by the widest possible range of compilers. They are not intended to create obstacles for users of more capable compilers. So from the MinGW developer perspective, the -ansi flag introduced by the autotools-based build system used to build swig is a fundamental bug for that build system. And I must say I agree. Just because -ansi produced no errors for some compiler the swig developers checked (say MinGW-4.7.2) does not mean an even stricter compiler (such as MinGW-4.8.1) might find something else that was not ansi compliant. And I particularly agree with the last sentence of the quote above! So I think the fundamental solution here is for epa_build to patch the swig autotools build system so it does not generate the -ansi flag. And assuming that works for us, we should send that patch t
