Re: [Lynx-dev] autotools vs. prototypes
On Aug 27, 2020, at 19:41, Thomas Dickey wrote: > On Thu, Aug 27, 2020 at 07:29:50PM -0500, Ryan Schmidt wrote: >> On Aug 27, 2020, at 19:05, Thomas Dickey 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 see - as long as it's on the command-line, and not hardcoded into clang >>> (though past experience suggests that's too much to expect). >>> >>> For the moment, I'll proceed with the command-line. >> >> Not sure what you mean exactly about the command line. It's simply that the >> default behavior of the compiler has changed, and now implicit function >> declarations are an error, rather than a warning as they have been before. > > sure - as long as they didn't hardcode the behavior, it's something that > can be addressed in the configure script. When I see the updated version, > I'll update the configure script. You can get the updated version of clang for macOS Catalina or Big Sur beta here, either as the full Xcode download or as the smaller command line tools: https://developer.apple.com/download/more/?=Xcode%2012 If you don't want to use a beta or have an older macOS or another OS, you can simulate the effects by adding -Werror=implicit-function-declaration to CFLAGS when configuring lynx. You can disable this behavior of the new clang by adding -Wno-error=implicit-function-declaration to CFLAGS, however I would assume there is no need to do so as long as you include the headers for all the functions you will use. ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] autotools vs. prototypes
- Original Message - | From: "Thomas Dickey" | To: "Ryan Schmidt" | Cc: "Thomas Dickey" , "lynx-dev" | Sent: Thursday, August 27, 2020 8:41:34 PM | Subject: Re: autotools vs. prototypes | On Thu, Aug 27, 2020 at 07:29:50PM -0500, Ryan Schmidt wrote: |> On Aug 27, 2020, at 19:05, Thomas Dickey 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 see - as long as it's on the command-line, and not hardcoded into clang |> > (though past experience suggests that's too much to expect). |> > |> > For the moment, I'll proceed with the command-line. |> |> Not sure what you mean exactly about the command line. It's simply that the |> default behavior of the compiler has changed, and now implicit function |> declarations are an error, rather than a warning as they have been before. | | sure - as long as they didn't hardcode the behavior, it's something that | can be addressed in the configure script. When I see the updated version, | I'll update the configure script. ...and if it's interesting enough, I'll add to this: https://invisible-island.net/personal/lint-tools.html#tool_clang -- Thomas E. Dickey http://invisible-island.net ftp://ftp.invisible-island.net ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] autotools vs. prototypes
On Thu, Aug 27, 2020 at 07:29:50PM -0500, Ryan Schmidt wrote: > On Aug 27, 2020, at 19:05, Thomas Dickey 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 see - as long as it's on the command-line, and not hardcoded into clang > > (though past experience suggests that's too much to expect). > > > > For the moment, I'll proceed with the command-line. > > Not sure what you mean exactly about the command line. It's simply that the > default behavior of the compiler has changed, and now implicit function > declarations are an error, rather than a warning as they have been before. sure - as long as they didn't hardcode the behavior, it's something that can be addressed in the configure script. When I see the updated version, I'll update the configure script. ttyl -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] autotools vs. prototypes
On Aug 27, 2020, at 19:05, Thomas Dickey 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 see - as long as it's on the command-line, and not hardcoded into clang > (though past experience suggests that's too much to expect). > > For the moment, I'll proceed with the command-line. Not sure what you mean exactly about the command line. It's simply that the default behavior of the compiler has changed, and now implicit function declarations are an error, rather than a warning as they have been before. ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] autotools vs. prototypes
>> It turns out that you simply CANNOT [make
>> -Werror=implicit-function-declaration the default].
I don't see why not.
>> Almost all GNU autoconf snippets make use of the fact that implicit
>> definitions, even with bogus prototypes, resolve at link time, to
>> detect functions.
Then they are broken and need to be rendered *obviously* broken, so
they can be found and fixed. Hiding such bugs serves nobody but lazy
software authors/maintainers.
Your exmaple, though, is not the example you seem to think it is:
> | #ifdef __cplusplus
> | extern "C"
> | #endif
> | char opendir ();
> | int
> | main ()
> | {
> | return opendir ();
> | ;
> | return 0;
> | }
There is no implicit function declaration there. What is there is an
EXplicit function declaration with no prototype. That is arguably a
bug too, but to the extent that it is, it is a different one, and
-Werror=implicit-function-declaration should not trip for it.
>> tl;dr: You cannot default to -Werror=implicit-function-declaration
>> *at all* or the usual ./configure; make; sudo make install trifecta
>> will break EVERYWHERE,
That's a feature, not a bug.
Rant ON.
./configure is a broken paradigm and tests that depend on implicit
function declarations, except to test for implicit function
declarations (and why would anyone do that??), are even more broken.
(And, sudo?? Don't even get me started.)
Rant OFF.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
___
Lynx-dev mailing list
Lynx-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] autotools vs. prototypes
On Thu, Aug 27, 2020 at 06:32:44PM -0500, Ryan Schmidt wrote: > > > 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 see - as long as it's on the command-line, and not hardcoded into clang (though past experience suggests that's too much to expect). For the moment, I'll proceed with the command-line. -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] autotools vs. prototypes
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
___
Lynx-dev mailing list
Lynx-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lynx-dev
[Lynx-dev] autotools vs. prototypes (was Re: ncurses configure test needs to include term.h or termcap.h too)
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.
Sorry,
//mirabilos
--
“It is inappropriate to require that a time represented as
seconds since the Epoch precisely represent the number of
seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2
___
Lynx-dev mailing list
Lynx-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lynx-dev
