Yup, I outsmarted myself.
I put some of these objects in a different directory because I thought it'd be
"neater", then forgot to follow through on the path issue that creates.
It's a relief that it seems to be an oversight and nothing more.
Thanks,
Alvaro
________________________________
From: Dave Allured - NOAA Affiliate <dave.allured@xxxxxxxx>
Sent: Tuesday, May 27, 2025 3:40 PM
To: Alvaro Fernandez <afernandez@xxxxxxxxxxxxxxx>
Cc: netcdfgroup@xxxxxxxxxxxxxxxx <netcdfgroup@xxxxxxxxxxxxxxxx>
Subject: Re: [netcdfgroup] Difficulty configuring NETCDF on Linux QEMU
EXTERNAL EMAIL - This email was sent by a person from outside your
organization. Exercise caution when clicking links, opening attachments or
taking further action, before validating its authenticity.
Config.log shows unexpected errors that are confusing several config tests.
The actual error happens not on compile, but on execute:
> checking size of short
> gcc -o conftest -fno-strict-aliasing -I/home/root/WRF/include
> -L/home/root/WRF/lib conftest.c -lsz
> ./conftest
> error while loading shared libraries: libsz.so.2: cannot open shared object
> file: No such file or directory
This is a dynamic linking problem. It might be caused by libsz.so.2 installed
in a nonstandard location. This has come up several times on the Unidata
support list. Look for titles with "sizeof":
https://support.unidata.ucar.edu/archives/netcdf/maillist.html<https://url.avanan.click/v2/r01/___https://support.unidata.ucar.edu/archives/netcdf/maillist.html___.YXAzOmluc3BpcmVzZW1pOmE6bzoxYjgwZjg0MDYyZDI2YWNkMDJlNzZmOGMzMWU5MzhkYTo3Ojk5MGE6NGUyMGM5MDIyOGFhMzU5NWZiOTdjZTc1MTNiMDEzM2U3ZjM2NjU3YTJjZGUzMTE2YWI5MGUyOWFmOGQ4ZWZiNjpoOlQ6Tg>
Unidata's suggestion is to append a path to LD_LIBRARY_PATH. However, a web
search also suggests "sudo ldconfig" as a preferred solution on Linux.
On Mon, May 26, 2025 at 7:09 PM Alvaro Fernandez
<afernandez@xxxxxxxxxxxxxxx<mailto:afernandez@xxxxxxxxxxxxxxx>> wrote:
Dave,
Thanks for offering to take a look at the logfile.
I'm attaching it, along with the config.cache I used.
The command used was:
./configure --disable-dap --disable-libxml2 CPPFLAGS="-I/home/root/WRF/include"
LDFLAGS="-L/home/root/WRF/lib" --host=riscv64-linux-gnu
--build=riscv64-linux-gnu --cache-file=config.cache 2>&1 | tee
configure-net.out
Alvaro
From: Dave Allured - NOAA Affiliate
<dave.allured@xxxxxxxx<mailto:dave.allured@xxxxxxxx>>
Sent: Monday, May 26, 2025 2:03 PM
> configure: error: cannot compute sizeof (size_t)
There is a known generic problem in configure scripts. Internally they use a
small C program for type checking. Sometimes that test program fails for some
other reason, something like library not found; and the error message does not
report the real problem. That is probably what is happening here. A careful
examination of config.log may reveal the real problem. Feel free to post
config.log as link or attachment, and I will take a look.
Alternatively, try building netCDF with Cmake rather than configure. It uses
completely different code for testing system features.
On Mon, May 26, 2025 at 11:24 AM Alvaro Fernandez
<afernandez@xxxxxxxxxxxxxxx<mailto:afernandez@xxxxxxxxxxxxxxx>> wrote:
Hi,
I'm trying to build NETCDF on (a QEMU emulation of) a RISC-V platform we're
developing.
I've successfully built other libraries (like HDF5, zlib, etc.) on this QEMU
with gcc 14.2.0.
However, I am having difficulty completing the configuration phase of the
NETCDF build process.
This machine will not be accessing the web or pulling down anything, so I
disabled DAP and XML, and am not giving it curl.
I started with this configure command:
./configure --disable-dap --disable-libxml2 CPPFLAGS="-I/home/root/WRF/include"
LDFLAGS="-L/home/root/WRF/lib" 2>&1 | tee configure-net.out
But I get errors like:
checking size of size_t... configure: error: in
'/home/root/repos/netcdf-c-4.9.3':
configure: error: cannot compute sizeof (size_t)
See 'config.log' for more details
I reasoned that the configure script might be confused about the host or built
targets, so I decided to be explicit.
Below is the latest attempt. I added the cache file:
root@qemuriscv64:~/repos/netcdf-c-4.9.3# cat config.cache
ac_cv_sizeof_off_t=8
And then I ran:
./configure --disable-dap --disable-libxml2 CPPFLAGS="-I/home/root/WRF/include"
LDFLAGS="-L/home/root/WRF/lib" --host=riscv64-linux-gnu
--build=riscv64-linux-gnu --cache-file=config.cache 2>&1 | tee
configure-net.out
It fails with the same error.
This error is detected in line 26715 of the configure script.
I see from the comments that this test serves to guard against an error in the
HP compiler. Is this still a useful test?
I would suspect our toolchain usually, but it's built hdf5 and multiple other
applications.
Thanks in advance,
Alvaro Fernandez, PhD
Inspire Semi
