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
> 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.
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?