[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20010814: netcdf-3.5.0 configure problem with gcc 3.0

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)