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.
Mike, Thanks for the information. We'll visit this problem when we have gcc 3.0 installed on one of our Linux systems. Regards, Steve Emmerson <http://www.unidata.ucar.edu> >Date: Tue, 14 Aug 2001 15:17:23 -0600 (MDT) >From: Mike Romberg <address@hidden> >Organization: UCAR/Unidata >To: Steve Emmerson <address@hidden> >Subject: 20010809: netcdf-3.5.0 configure problem with gcc 3.0 >Keywords: 200108092258.f79Mwt111020 > > >>>>> " " == Steve Emmerson <address@hidden> writes: > > Sorry for not getting back to you sooner. > > > Mike, We aren't able to duplicate your problem because we don't > > yet have gcc 3.0 installed on any of our Linux systems. When > > it's installed we'll try your problem. > > > We did encounter one difficulty in executing the configure > > script when using gcc 3.0, however. It appears absolutely > > necessary to have the pathname of the directory that contains > > the gcc 3.0 runtime libraries in the LD_LIBRARY_PATH > > environment variable. If this isn't done, then the GNU C++ > > compiler will fail to pass the configure script's reality-check > > (and rightfully so since every gcc 3.0-built program will > > fail). > > Yea. This is a new feature I'm not really happy with either. I > think it has something to do with getting exceptions to work with > shared libraries. I was able to figure this out myself. This one is > not really a netcdf problem. The gcc documentation does mention it. > But I bet lots of folks will still get bit by the problem. > > > We're surprised by the necessity for the "throw()" clause in > > the declaration of the C exit() function because C functions > > can't throw exceptions (that's a C++ construct) and the "extern > > C" clause should have covered that issue. Could it be that your > > problem is also due to an incomplete LD_LIBRARY_PATH > > environment variable? Would you be willing to test this? > > My guess is that we owe this exit() throw() thing to the new C++ > standard. It has managed to foul up quite a few other things about > the language. My guess is that the committee specified that exit() in > C++ should now be declared this way. I know that this problem has > nothing to to with the LD_LIBRARY_PATH since I've already fixed that > problem. > > The real funny thing is that if I regenerate your configure script > using the same version of autoconf on a redhat 7.1 machine, it puts in > code with the throw bit. This makes gcc-3.0 happy. So, this might > actually be a bug in autoconf. > > Mike (address@hidden)