the tocgrib utility uses the NCEPLIBS-w3emc subroutine w3as00(), which depends on mysterious subroutines

[edwardhartnett]

In NCEPLIBS-w3emc we have a cmake option:

option(BUILD_WITH_EXTRA_DEPS "Build w3emc with subprograms which call unknown dependencies" ON)

One of these subroutines is w3as00() and it is used in tocgrib.

It should be noted that it is impossible to build the shared libraries with unresolved dependencies.

[edwardhartnett]

@AlexanderRichert-NOAA , @GeorgeVandenberghe-NOAA and @Hang-Lei-NOAA I'm not sure what, if anything to do about this.

NOAA operational code is built static only, so this is not a problem, but tocgrob2 cannot be built with shared libraries. Is that a problem for anyone? Is there any way we can fix it by tracking down where this code is being called from?

[GeorgeVandenberghe-NOAA]

Run ldd on all production executables to find it, then look at the build for those that come up positive.

I think I am preaching to the choir when I assert we are going to have to be able to run production with shared libraries to support much improved NetCDF compression options available only with runtime selection. (and this preaching is from someone who otherwise despises shared library APIs)

[GeorgeVandenberghe-NOAA]

tocgrib2 is used extensively in operations to produce various grib2 products so our hopes that this would be something dead are not realized.

…

On Tue, May 28, 2024 at 5:01 PM Edward Hartnett ***@***.***> wrote: @AlexanderRichert-NOAA <https://github.com/AlexanderRichert-NOAA> , @GeorgeVandenberghe-NOAA <https://github.com/GeorgeVandenberghe-NOAA> and @Hang-Lei-NOAA <https://github.com/Hang-Lei-NOAA> I'm not sure what, if anything to do about this. NOAA operational code is built static only, so this is not a problem, but tocgrob2 cannot be built with shared libraries. Is that a problem for anyone? Is there any way we can fix it by tracking down where this code is being called from? — Reply to this email directly, view it on GitHub <#280 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANDS4FSS66O3X2CCGV5NKL3ZESZ5XAVCNFSM6AAAAAA5OJWOL6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZVG4ZDMOBVGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- George W Vandenberghe *Lynker Technologies at * NOAA/NWS/NCEP/EMC 5830 University Research Ct., Rm. 2141 College Park, MD 20740 ***@***.*** 301-683-3769(work) 3017751547(cell)

[AlexanderRichert-NOAA]

Here's what I've come up with as far as the 'missing' subroutines in w3emc (i.e., the subroutines that are undefined when I try to build w3emc as a shared lib):

• iargc/getarg: There seems to be some quirkiness in src/args_mod.f, which frankly I'm not sure I understand the point of. I have a sneaking suspicion we could remove that file from w3emc entirely (it's wrapping Fortran intrinsics, which should probably be replaced with modern equivalents of those subroutines (command_argument_count() and get_command_argument()) in w3as00.
• int2ch: converts integer to character string. We could probably replace the two calls to this subroutine (both in src/w3fq07.f) with write....
• consol: seems to just print or in some way output strings with statuses. I suspect these calls could be replaced with print statements.
• w3fi33: converts array of first 8 identification words into an array of 27 data field identifiers. The code is available at https://ntrs.nasa.gov/api/citations/19820002778/downloads/19820002778.pdf, so we could just add this to w3emc.

For the last three, I'm going to look in the operational executables and see if any of them use these subroutines. Something tells me they're unused, in which case maybe the way to go is to just remove them. In any case I'll plan to put in a PR to w3emc to resolve this stuff...

[edwardhartnett]

Awesome.