lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lynx-dev] autotools vs. prototypes


From: Ryan Schmidt
Subject: Re: [Lynx-dev] autotools vs. prototypes
Date: Thu, 27 Aug 2020 18:32:44 -0500


On Aug 27, 2020, at 18:18, Thorsten Glaser wrote:

> Ryan Schmidt dixit:
> 
>> Just to note, -Werror=implicit-function-declaration will be the default
>> behavior of Apple clang soon, hence the report we received and the
>> desire to fix this soon.
> 
> I implemented something similar in MirPorts (packaging framework for
> MirBSD and other operating systems) and MirBSD core.
> 
> It turns out that you simply CANNOT do that.
> 
> Almost all GNU autoconf snippets make use of the fact that implicit
> definitions, even with bogus prototypes, resolve at link time, to
> detect functions.
> 
> I had to patch GCC to add a specific flag that adds -Wno-error if
> a certain environment variable is present, so we can add all the
> warning flags and -Werror to CFLAGS and have autofools propagate
> these to the Makefiles but deactivate them during the configure
> run itself.
> 
> It’s not just GNU autotools. Most build systems do this. I took
> specific pains to avoid it in mirtoconf (mksh build system) but
> that needs adapting to each and every operating system things are
> ported to.
> 
> One example of such a stock configure test is:
> 
> | /* Override any GCC internal prototype to avoid an error.
> |    Use char because int might match the return type of a GCC
> |    builtin and then its argument prototype would still apply.  */
> | #ifdef __cplusplus
> | extern "C"
> | #endif
> | char opendir ();
> | int
> | main ()
> | {
> | return opendir ();
> |   ;
> |   return 0;
> | }
> 
> Just to demonstrate how bad the situation is. This affects
> the vast majority of FOSS in the wild.
> 
> tl;dr: You cannot default to -Werror=implicit-function-declaration
> *at all* or the usual ./configure; make; sudo make install trifecta
> will break EVERYWHERE, and you MUST add functionality so that, if
> it is present, it can be disabled from the environment.
> 
> Please *do* forward this to everyone who needs to hear this.

A lot of FOSS software builds fine with this change. Another lot doesn't 
because of forgotten #include directives, which will take awhile to identify 
and fix, but seems doable.

I don't feel it's my place to second-guess Apple and/or the LLVM developers 
about this. I'm sure their engineers are much smarter than I am. If you'd like 
them to change their minds about this, you should file a bug report at:

https://feedbackassistant.apple.com

and/or:

https://bugs.llvm.org




reply via email to

[Prev in Thread] Current Thread [Next in Thread]