Opened 18 months ago

Last modified 7 months ago

#67455 assigned defect

ncarg @6.6.2: disables implicit declaration of function errors

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by: tenomoto (Takeshi Enomoto)
Priority: Normal Milestone:
Component: ports Version: 2.8.1
Keywords: Cc: Dave-Allured (Dave Allured)
Port: ncarg

Description

Xcode 12 and later consider implicit declaration of functions to be an error.

The ncarg portfile contains this line to disable that error:

configure.cflags-append     -Wno-error=implicit-function-declaration

See #61275 in which this line was added.

This makes the software the port builds potentially incompatible with Apple Silicon processors.

This line should be removed and the problem should be fixed correctly: by declaring functions before using them. See WimplicitFunctionDeclaration for much more information.

The port maintainer need not be the one to do this. It is an upstream matter that should be resolved by the developers of ncarg. A good first step would be to report the problem to them and add the URL of the report to this ticket so we can keep an eye on it.

Change History (9)

comment:1 Changed 16 months ago by Dave-Allured (Dave Allured)

Cc: Dave-Allured added

comment:2 Changed 7 months ago by nilason (Nicklas Larsson)

This is now a problem at least for macOS 14/arm64, log extract from CI runner (from a rev-bump PR):

/opt/local/bin/h5cc -fPIC -D_DARWIN_C_SOURCE -Os -Wno-error=implicit-function-declaration -DH5_USE_110_API -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk  -O  -I../../.././include -I/opt/local/include/freetype2 -I/opt/local/include/udunits2 -I/opt/local/lib/hdfeos5/include -I/opt/local/lib/proj5/include -I/opt/local/include    -DSYSV -D_POSIX_SOURCE -D_XOPEN_SOURCE -D__JIRA1530__ -DByteSwapped -D__UNIXOS2__ -D_DARWIN_C_SOURCE -DNeedFuncProto    -c -o closure.o closure.c
closure.c:11:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int]
set_EFF()
^
int
closure.c:21:11: warning: passing arguments to 'allocate' without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
    EFF = NEW2(nvars * rowsize, unsigned);
          ^
./defs.h:105:32: note: expanded from macro 'NEW2'
#define NEW2(n,t)       ((t*)allocate((unsigned)((n)*sizeof(t))))
                                     ^
closure.c:39:5: warning: call to undeclared function 'reflexive_transitive_closure'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
    reflexive_transitive_closure(EFF, nvars);
    ^
closure.c:47:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int]
set_first_derives()
^
int
closure.c:63:21: warning: passing arguments to 'allocate' without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
    first_derives = NEW2(nvars * rulesetsize, unsigned) - ntokens * rulesetsize;
                    ^
./defs.h:105:32: note: expanded from macro 'NEW2'
#define NEW2(n,t)       ((t*)allocate((unsigned)((n)*sizeof(t))))
                                     ^
closure.c:102:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int]
closure(nucleus, n)
^
int
closure.c:102:1: warning: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
closure.c:172:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int]
finalize_closure()
^
int
4 warnings and 4 errors generated.
make[4]: *** [closure.o] Error 1

comment:3 in reply to:  2 Changed 7 months ago by ryandesign (Ryan Carsten Schmidt)

Replying to nilason:

closure.c:11:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int]

That is a different, unrelated error.

comment:4 Changed 7 months ago by Dave-Allured (Dave Allured)

Upstream, NCARG was put into "maintenance mode" five years ago. There has not been any stable release since then. However, they accepted dozens of maintenance patches into their development branch, from Fedora, Conda, and other sources. This includes a few bits from Macports.

I expect that these patches included fixes for implicit declarations. We should try the latest tag version. I will try this myself soon, unless someone does it first.

comment:5 Changed 7 months ago by ryandesign (Ryan Carsten Schmidt)

We are already using the latest tag version, 6.6.2 from 2019. In their November 2020 update blog post they promised to "put out periodic bug-fix releases" but sadly they appear never to have done so and none of their subsequent blog posts mention NCL.

Both of the bugs reported in this ticket have been reported upstream 15 months ago at https://github.com/NCAR/ncl/issues/193 with no response.

comment:6 in reply to:  5 Changed 7 months ago by Dave-Allured (Dave Allured)

Okay, I misunderstood what is a "tag version". What I meant was, I would like to try the latest development snapshot.

comment:7 Changed 7 months ago by tenomoto (Takeshi Enomoto)

I pushed the commit that is against Ryans' suggestion to enable build on Sonoma. I imagine many scientists and engineers, including myself and my students, still need NCL. https://github.com/macports/macports-ports/commit/405bac09ffbec42dc246997293fcdb4d29c9d995

I manually edited 100+ files to comply C99, wasting a number of holidays. I found the compiler option -Wno-error=implicit-function-declaration before completing the patches. Probably I should have used an automated tool such as cprotol.

Version 0, edited 7 months ago by tenomoto (Takeshi Enomoto) (next)

comment:8 in reply to:  7 Changed 7 months ago by ryandesign (Ryan Carsten Schmidt)

Sorry you spent so much time on it and that the developers don't seem to care to fix it themselves. It's annoying when upstream developers ignore compiler warnings for decades and then disappear by the time the warnings become errors.

If there's an automated tool to fix these things that would be great. Is "cprotol" the name of the tool? I'm not familiar with it and couldn't find anything when I searched that name.

For future reference, the revision shouldn't be increased just to fix a build error. Only increase the revision if something will change for those users who already had the port installed. See the documentation of the revision keyword at https://guide.macports.org/#reference.keywords.

comment:9 Changed 7 months ago by tenomoto (Takeshi Enomoto)

I misspelled. The correct name is cproto https://invisible-island.net/cproto/cproto.html. It creates header from source. I have not used it but it is in MacPorts. NCL/NCARG has been maintained by NCAR, i.e. paid staff and the most users (scientists and students) are not familiar with the internals.

Indeed it was a mistake to increase the revision.

Note: See TracTickets for help on using tickets.