Re: [netcdfgroup] Difficulty configuring NETCDF on Linux QEMU

  • To: Dave Allured - NOAA Affiliate <dave.allured@xxxxxxxx>
  • Subject: Re: [netcdfgroup] Difficulty configuring NETCDF on Linux QEMU
  • From: Alvaro Fernandez <afernandez@xxxxxxxxxxxxxxx>
  • Date: Tue, 27 May 2025 21:00:26 +0000
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=inspiresemi.com; dmarc=pass action=none header.from=inspiresemi.com; dkim=pass header.d=inspiresemi.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=aM1YiCnyjeEoJVKDgXO+sZDZbiGSUyE4+Vg7EjGUeGM=; b=RKndZIpKVTnWQ1N/G8udJ0MHQRVc+ucd9Gah7e0KRkKjAdKFdD5fpvCLlZuktN57pfbz0Or3XcDnqVNO/pVIvdcNdP8plUM46MA8OINa/NT/iJYdbtEtCUC8qmqoVZ0NQXRGitqu4UetTtuLHNA0MzyqPRD6WGorAYdSJQdQIBt+2ZZhetoPcf0M5kLy53ME/Tkl8YQmw0KI3NyzSTYByW1Xrb3c4RKkNMmvP/u17aBJ57Hfnh08w5c+d9UY4cjXOqQDF3XAhl02acM3mv6UluErbqw1mNE5p5tR6gX8YJALMaBykOphWLM1cMJFdCxHdt+o9qQijo1ldEE/uXN64A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=vo3pT1Vne3rX9UZpqMyluQ4VSTNcD+gSq3wlOgmIpWKk5MYrRMNIC4k3t84g5Jmf7kDhcwNXRXJekhS20XkCuWtekK6YR9MYxvH8BZJxLF8GcD5Qt/36n+L0NwZcrVORbDwTqxPghLEgjyJ/CeSm72uapkdVn9TIr3LoRODqdeWVevfYsJ/ObMlLAVv01FE7hRIG4SGTCkvuV5uA8Vnd5Ni/qv1eXknxTYdM5D7doiAafEjUh10aj/Xmr1RBblDteu071nUyQTgyLpJKemD5k0aq7lEJvxkVluojN1a5V093X6PnSXOFi3qvVm6snTmg0sA/QHtCPRH7wsxMk4vJwQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=inspiresemi.com;
  • Msip_labels:
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
  • 2025 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdfgroup archives: