On Fri, Apr 24, 2009 at 10:48:09PM -0500, Geoffrey Furnish wrote: > Alan W. Irwin writes: > > When running into a component problem like this where you are not > interested > > in the component (and also for speed) just disable the componenent, e.g., > > -DENABLE_f95=OFF > > I did, and kept going. > > > Thanks for that fortran 95 error report. > > > > However, I don't think we should change anything in PLplot to deal with > this > > issue. > > Well, something needs to change, because the build failed, and I did nothing > to select any "experimental features". A default build should just work on > most common platforms. > > > The exit statements in examples/f95/x20f.f90 are causing the trouble for > > your f95 compiler. Those are very different from "call exit". The bare > > exit command is used to escape loops in Fortran 95. Modern gfortran > > implements it as does the Intel compiler (and presumably all other > > commercial Fortran compilers). Apparently, you have some old version of > > gfortran that doesn't have bare exit implemented yet. Our Fortran 95 > > examples build and work great here with gfortran (GNU Fortran (Debian > > 4.3.2-1.1) 4.3.2). > > > > I am now going to rant just a little about one of my pet peeves, the > > so-called enterprise editions of Linux distributions. Those distributions > > are filled with out-dated software which I think you are the victim of in > > this case since you have mentioned RHEL version 4 in other contexts. > > I said in the report of the fortran build failure that I was running on > Fedora 8. > > > I think the source of the trouble is corporate IT departments which have > > been conditioned to demand non-changing software by proprietary software > > vendors. They have made similar demands of Linux distribution vendors, > > and as a result the enterprise edition of Linux was born. But the whole > > idea should have been aborted instead since it is fundamentally not > > consistent with the pace of development for Linux. Linux is not and never > > will be a toaster. > > > > I assume every 3 years or so these corporate IT departments are forced to > > change their enterprise Linux version. There must be huge training costs > > associated with such enormous change attempted all at once. There has got > > to be a better way of having a steady diet of reliable, well-tested change > > that keeps up with Linux development for just the key libraries and apps > > that a particular corporation wants. The idea would be to give > > corporation workers the chance to adjust to the steady change associated > > with Linux without having huge training costs associated with large abrupt > > changes. You also avoid the hidden costs of old Linux software that > > sometimes (as above) just doesn't cut it. > > > > End rant. > > So, I share your frustration. When I brought up "enterprise Linux" the other > day, I wasn't endorsing it, just observing that it is widespread and > entrenched. But I don't like it either. > > Trying not to descend into a rant here myself, what I can say is that there > is some economic sense behind the whole notion of stable enterprise platforms > and deployments. In the industry that I and Maurice are in, for example, the > costs of manufacture for integrated circuits, and the computer aided design > tools that support such design and manufacturing, are very large. Typical > software tooling is multi-hunderd thousand USD per engineer per year. The > vendors of these tools certify on Linux, specific "enterprise" versions, and > the customers run the platforms the tools are certified on, because they need > to be able to get suppport. Too much money is riding on the line, for them > to jeopardize their support options by not running the certified platform. > And too much money is riding on the line for the tool vendors to not do the > rigorous testing required to provide meaningful certification on at least > some platforms. > > Now, there is a roadmap for driving tools onto newer platforms, and > essentially every tool I personally us, is currently certified on RHEL5, > which is years newer than RHEL4. But, there are still *some* tools in the > design and manufacturing toolchain which are *not* certified on RHEL5, hence > the need to keep RHEL4 deployed. > > Anyway, to my thinking, this is all both interesting (albeit annoying), and > simultaneously somewhat irrelevant to the point, at least the point I'm > trying to make. > > The point I'm trying to make is that PLplot should configure (cmake) and > compile on reasonably common platforms. IMO, Fedora 8 should qualify. So, > if the default/stock gfortran isn't good enough to compile the PLplot source > code, then in my opinion, the PLplot configuration system (cmake) should > check the gfortran version, and if it's not good enough, automatically > disable the g95 option. > > I really don't have a point of view on the validity of the Fortran example 20 > in question. If it was wrong, it should be fixed. But if it was right and > the compiler on F8 is too weak, then the CBS should detect that the gfortran > is not of the required minimum version, and turn of F95 support in the > build. > > I think there should also be a way to override any auto-shut-off, so that a > user who wants to experiment with either differnet tools, or changing the > source code, is not prevented from doing so. If your compiler is too weak, > CBS should disable it (whatever feature is affected) by default, but provide > a manual overide for those determined to press on. > > My $.02.
Geoff, Testing has shown that this is a result of a bug in gfortran versions <= 4.1 when both the fortran exit command and the instrinsic exit subroutine are used in the same program. I have committed a simple work-around in example 20 which should fix compilation for you. Could you check this? Andrew ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
