This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
John, > I had the same problem with the interactive patch with the native > patch program. The 2.1 gnu-patch worked fine except that it reported > the errors I mentioned previously. And here the 2.1 gnu-patch worked fine, and reported no errors using the same patches, on the same sources (both from the FTP directory), on the same platform (OSF/1 Alpha). Since I can't reproduce the problem here, I'm giving up on that one. > > However, I would think you should be using "g++" rather than > > "gcc" for the compiler. Have you tried compiling the C++ interface by > > invoking > > > > make CCC=g++ > > As far as I know all version 2 and higher gcc compilers are C and C++ > (if you build them that way, which I did) so the g++ is only a link to > gcc; they are the same program. Yes, but it makes a difference whether you invoke the compiler as "gcc" or as "g++" on the same source, even if g++ is a link to gcc. The compiler actually checks argv[0] to see how it was invoked and behaves differently in the two cases, since C++ is not just a superset of standard C. For example, compiling and running the following program would have to return a different value if you used gcc (4) than if you used g++ (1), because it is impossible to tell from the source whether it is C or C++, and the program behaves differently depending on whether it is interpreted to be ANSI C or C++: int main() { return sizeof('a'); } If you want to compile C++ code with gcc, you have to invoke it as "g++". ______________________________________________________________________________ Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu