ungrib compiling error

GervyWRF

New member
Hi, I updated my Linux Fedora 36 to Fedora 37, kernel 6.1.14-200.fc37.x86_64 and I also updated my intel compiler to Intel® oneAPI HPC Toolkit (version 2023.0).

I cannot more build ungrib.exe. I obtain the error:

Code:
ld: ./ngl/libg2_4.a(dec_jpeg2000.o): in function `dec_jpeg2000_':
dec_jpeg2000.c:(.text+0x20): undefined reference to `jpc_decode'
make[1]: [Makefile:19: ungrib.exe] Errore 1 (ignorato)
make[1]: uscita dalla directory «/home/master/WPSV3/ungrib/src»

How ca i fix?

Thank you very much,
Fabio.
 

kwerner

Administrator
Staff member
Hi,
Can you issue a "clean -a" and then reconfigure and then recompile WPS. After that, please attach the new configure.wps file, as well as the full compile log. Thanks!
 

GervyWRF

New member
Hi, thank you for reply. The required files are attached.
 

Attachments

  • configure.wps
    3.3 KB · Views: 2
  • compile_wps.log
    80.6 KB · Views: 2

kwerner

Administrator
Staff member
Thanks for sending those. In your configure.wps file, you have these two lines:

Code:
COMPRESSION_LIBS    = -L/glade/u/home/wrfhelp/UNGRIB_LIBRARIES/lib -ljasper -lpng -lz
COMPRESSION_INC     = -I/glade/u/home/wrfhelp/UNGRIB_LIBRARIES/include

These are the default settings that point to NCAR's HPC (glade). You need to set these to the actual paths where your jasper, libpng, and zlib libraries are installed. Do another 'clean -a' and then reconfigure. Then modify the configure.wps file to the correct paths. Save the file, and then try recompiling to see if that makes a difference.
 

GervyWRF

New member
I don't know exactly where they are. I've never needed to specify it and I've always compiled without problems. I'm attaching a compilation made on another computer, where as you can see, the paths you specified to me haven't been changed, yet they point to NCAR's HPC. What do you think?
 

Attachments

  • configure.wps
    3.3 KB · Views: 2
  • compile_wps.log
    76.7 KB · Views: 0

kwerner

Administrator
Staff member
I'm not sure how that would have been able to compile correctly?

I know you're trying to compile V4.2, but beginning in WPSV4.4, there is an option to have the WPS program automatically build the GRIB2 libraries for you, and then you don't need to point to any paths for them. Do you mind trying that version (it shouldn't make a difference which WPS version you use, as long as you're using a V4+ with any V4+ version of WRF)? To compile WPS with the automatic library build, configure with this command:

Code:
./configure --build-grib2-libs

and then compile the code. Let me know if you're able to get ungrib.exe when you do that.
 

GervyWRF

New member
Hi, using version 4.4 and your command (./configure --build-grib2-libs), even worse... :-(
 

Attachments

  • compile_wps.log
    109.8 KB · Views: 5

kwerner

Administrator
Staff member
Can you send me the following 3 files?

Your new configure.wps file
external/libpng-1.6.37/config.log
external/jasper-1.900.29/config.log

Thanks!
 

kwerner

Administrator
Staff member
Thanks for sending those. I could be wrong, as I'm not a software engineer, but I believe the issue seems to be related to your C compiler(s). Can you issue the commands

Code:
which icc >& icc.log

which cpp >& cpp.log

and while you're at it, issue

Code:
echo $NETCDF_PATH >& netcdf.log
***EDIT: This command should have been 'echo $NETCDF'***

and send me those three *.log files. Thanks!
 

GervyWRF

New member
Ok.

the netcdf log is empty, but consider that wrf compiles fine.
 

Attachments

  • cpp.log
    13 bytes · Views: 3
  • icc.log
    58 bytes · Views: 2

GervyWRF

New member
Thanks for sending those. I could be wrong, as I'm not a software engineer, but I believe the issue seems to be related to your C compiler(s). Can you issue the commands

Code:
which icc >& icc.log

which cpp >& cpp.log

and while you're at it, issue

Code:
echo $NETCDF_PATH >& netcdf.log
***EDIT: This command should have been 'echo $NETCDF'***

and send me those three *.log files. Thanks!

the "echo $NETCDF" command returns:

[master@hp-15sfq5017nl ~]$ echo $NETCDF
/home/master/netcdf

Having changed my computer a month ago, I have the newest intel compiler.

About the environment variables, I usually use the following:

export CC=icc
export FC=ifort
export F9X=ifort
export F90=ifort
export F77=ifort
export CXX=icpc
export CFLAGS='-O3 -ip -no-prec-div'
export FFLAGS='-O3 -ip -no-prec-div'
export CXXFLAGS='-O3 -ip -no-prec-div'
export CPP='icc -E'
export CXXCPP='icpc -E'

export F90=''
export F90FLAGS=''

without problems...
 

kwerner

Administrator
Staff member
Thanks for sending those files and output. I'm asking one of our software engineers to take a look at this and will hopefully get an answer to you soon.
 

mgduda

Administrator
Staff member
The issue looks like it may be related to the C pre-processor that's specified in the configure.wps file.

In the compile.log file (for WPS v4.4 with --build-grib2-libs):
configure: error: in `/home/master/WPSV3/external/libpng-1.6.37':
configure: error: C preprocessor "/lib/cpp -P -traditional" fails sanity check
See `config.log' for more details
And in the config.log file from external/libpng-1.6.37:
configure:4766: /lib/cpp -P -traditional conftest.c
In file included from /usr/include/features.h:491,
from /usr/include/assert.h:36,
from conftest.c:15:
/usr/include/sys/cdefs.h:31:3: error: #error "You need a ISO C or C++ conforming compiler to use the glibc headers"
Since `which cpp` returns /usr/bin/cpp, it may be worth trying to specify that for the CPP variable in the configure.wps file to see if that helps.

Could you start with a clean copy of the WPS v4.4 source, configure and choose the same options as before. However, before compiling, could you try changing
CPP = /lib/cpp -P -traditional
in the configure.wps file to
CPP = /usr/bin/cpp -P -traditional
?
 

GervyWRF

New member
The issue looks like it may be related to the C pre-processor that's specified in the configure.wps file.

In the compile.log file (for WPS v4.4 with --build-grib2-libs):

And in the config.log file from external/libpng-1.6.37:

Since `which cpp` returns /usr/bin/cpp, it may be worth trying to specify that for the CPP variable in the configure.wps file to see if that helps.

Could you start with a clean copy of the WPS v4.4 source, configure and choose the same options as before. However, before compiling, could you try changing

in the configure.wps file to

?
Hi!

I tried your suggestion, like this:

$ ./clean -a

$ ./configure
and I choosed 17

I changed CPP = /lib/cpp -P -traditional to CPP = /usr/bin/cpp -P -traditional into configure.wps file

But the built result is in attachment... (no external lib log produced...)
 

Attachments

  • compile_wps.log
    102 KB · Views: 1

mgduda

Administrator
Staff member
From your new compile_wps.log, it looks like you may have written "/user/bin/cpp" rather than "/usr/bin/cpp":
/bin/sh: riga 1: /user/bin/cpp: File o directory non esistente
Can you verify that your configure.wps file has
CPP = /usr/bin/cpp -P -traditional
(without an "e" in "usr")?
 

GervyWRF

New member
Sorry for the mistake!

I attach the file logs using configure like this:

1) without options and then choosing 17 (no external lib logs)
2) by "--build-grib2-libs" option and then selecting 9

Thank you and forgive me again
 

Attachments

  • compile_wps.log
    110.2 KB · Views: 0
  • config.log
    19.9 KB · Views: 0
  • config.log
    25.4 KB · Views: 1
  • compile_wps.log
    85.3 KB · Views: 1

mgduda

Administrator
Staff member
It looks from one of your "config.log" files that the issue still concerns the C pre-processor on your system:

configure:7579: /usr/bin/cpp -P -traditional conftest.c
In file included from /usr/include/features.h:491,
from /usr/include/assert.h:36,
from conftest.c:15:
/usr/include/sys/cdefs.h:31:3: error: #error "You need a ISO C or C++ conforming compiler to use the glibc headers"

In order to make any progress, I think you'll need to locate a working C pre-processor, and to manually specify that in your configure.wps file. In case it helps, here's the test program (as far as I can tell) that the configure script for JasPer is using:

/* confdefs.h */
#define PACKAGE_NAME "jasper"
#define PACKAGE_TARNAME "jasper"
#define PACKAGE_VERSION "1.900.29"
#define PACKAGE_STRING "jasper 1.900.29"
#define PACKAGE_BUGREPORT ""
#define PACKAGE_URL ""
#define PACKAGE "jasper"
#define VERSION "1.900.29"
/* end confdefs.h. */
#ifdef __STDC__
# include <limits.h>
#else
# include <assert.h>
#endif

You can save this to a file named "conftest.c", and test whether you've located a working C pre-processor with:

cpp -P -traditional conftest.c

where "cpp" in the above command is whatever C pre-processor you believe to be correct.

Also, just as a small suggestion for the future, it may be helpful if you were to use unique filenames for attachments.
 

GervyWRF

New member
Thank you for your suggest. About C pre-processor, I obtain:

Code:
In file included from /usr/include/features.h:491,
                 from /usr/include/assert.h:36,
                 from conftest.c:15:
/usr/include/sys/cdefs.h:31:3: error: #error "You need a ISO C or C++ conforming compiler to use the glibc headers"
   31 | # error "You need a ISO C or C++ conforming compiler to use the glibc headers"
      |   ^~~~~


/usr/include/sys/cdefs.h:185: error: syntax error in macro parameter list
  185 | #define __glibc_fortify(f, __l, __s, __osz, ...) \
      |


/usr/include/sys/cdefs.h:195: error: syntax error in macro parameter list
  195 | #define __glibc_fortify_n(f, __l, __s, __osz, ...) \
      |


extern void __assert_fail (const char *__assertion, const char *__file,
               unsigned int __line, const char *__function)
     __attribute__ ((__nothrow__ , __leaf__)) __attribute__ ((__noreturn__));


extern void __assert_perror_fail (int __errnum, const char *__file,
                  unsigned int __line, const char *__function)
     __attribute__ ((__nothrow__ , __leaf__)) __attribute__ ((__noreturn__));



extern void __assert (const char *__assertion, const char *__file, int __line)
     __attribute__ ((__nothrow__ , __leaf__)) __attribute__ ((__noreturn__));
 
Top