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

960905: netcdf-3.1a "configure" problems

Annette,

> To: address@hidden
> cc: address@hidden
> From: address@hidden ()
> Subject: netcdf-3.1a "configure" problems
> Organization: Pacific Northwest Laboratory
> Keywords: 199609051434.AA17837

In the above message you wrote:

> I have installed the prerelease version (C only) of netcdf version 3.1a on
> our Sun Solaris system. Here's the "uname" info:
> 
> SunOS radius 5.5 Generic sun4m sparc SUNW,SPARCstation-20
> 
> 
> I encountered some syntax problems in the configure file. There were
> several instances of syntax that looked like
> 
>   if test $variable = yes
> 
> or
> 
>   if test $variable = no
> 
> that resulted in errors like
> 
>   test ... missing argument.
> 
> 
> I changed the above syntax to look like:
> 
>    if test "$variable" = yes
> or
>    if test "$variable" = no
> 
> and this seemed to correct the problem. After that, installation went OK,
> and the "make test" worked just fine. Also note that we are using GNU
> C for the compiler.

Interesting.  This shouldn't happen.  The following candidates for the
problem you describe exist in the `configure' script:

    ~/upc/netcdf-3/src: grep 'if[   ][      ]*test' configure | grep ac_cv
    if test $ac_cv_struct_st_blksize = yes; then
    if test $ac_cv_c_ieeefloat = no; then
    if test $ac_cv_header_stdc = yes; then
    if test $ac_cv_header_stdc = yes; then
    if test $ac_cv_header_stdc = yes; then
    if test $ac_cv_header_stdc = yes; then
    if test $ac_cv_type_size_t = no; then
    if test $ac_cv_type_off_t = no; then
    if test $ac_cv_type_ssize_t = no; then
    if test $ac_cv_type_ptrdiff_t = no; then
    if test $ac_cv_type_uchar = no; then
    if test $ac_cv_c_char_unsigned = yes && test "$GCC" != yes; then
    if test $ac_cv_c_bigendian = unknown; then
    if test $ac_cv_c_bigendian = yes; then

The only way the the problem could manifest itself is for one or more of
the above variables to be set to a blank string.  These variables are
completely managed by the autoconf-generated configure script, which
never sets them to blank strings.  It therefore seems that some of them
must have been set to blank strings outside the `configure' script.  I,
therefore, have the following questions for you and hope that you'll
respond so that we can eliminate this problem.

    1.  Do any of the above variables exist as environment variables?

    2.  Was the cache file for the `configure' script (config.cache) 
        edited, setting the values to blank strings?

    3.  Did a `config.cache' file exist from an (possibly aborted)
        previous attempt?

--------
Steve Emmerson   <address@hidden>