On 2014-02-11 09:41-0800 Alan W. Irwin wrote: > On 2014-02-11 14:10-0000 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: <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. </quote> 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 to the swig bug tracker. To me it is really important goal that you are able to replicate my MinGW/MSYS success since that test result would provide MinGW/MSYS users (who have probably never heard of Wine) a lot more confidence in this release. So normally I would be tempted to extend the release date by "as long as it takes" to do the above before the release. But I also realize you are up against another deadline this weekend and will be unavailable to work on PLplot some time after that so that is why I am going to put off the above fundamental fix until after the present release. IMPORTANT: So unless something extraordinary develops I plan to make this release something like 24 hours from now (e.g., near 2014-02-12T12:00-08:00 or 2014-02-12T20:00-00:00). Nevertheless if you have any time in the next 24 hours to work on PLplot, that still gives you an opportunity to meet the important goal of getting a comprehensive noninteractive test done with epa_build on your MinGW/MSYS platform before the release. From the above discussion the key would be for you to also use MinGW-4.7.x for your test which makes your test platform substantially more similar to mine and which from my experience is not as strict about checking code compliance when the -ansi compiler flag is used. So assuming MinGW-4.7.x is already installed on your computer (or assuming you can install it), please go ahead and try to get that comprehensive test done in time so I can put those MinGW-4.7.x results in README.release for this release. 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
