X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
From: =?UTF-8?Q?Hans-Bernhard_Br=c3=b6ker?= <HBBroeker AT t-online DOT de>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Difficulties compiling libc from repository using gcc 10.N.0
Date: Thu, 10 Dec 2020 22:19:33 +0100
Lines: 47
Message-ID: <i3fhnbFqna3U1@mid.dfncis.de>
References: <5FD1FEA1 DOT 7010304 AT gmx DOT de>
 <8816d501-9f33-4d68-4235-1935a83580f6 AT gmail DOT com>
 <CAA2C=vACivjbYiU7yVpyFdzKjjKB10E1tvqShLPQ6i31cuKrDA AT mail DOT gmail DOT com>
 <111383e4-b3db-f346-b71c-749dee17dc9e AT gmail DOT com>
 <CAA2C=vDL+YWHssNteT71jUNxYAJkxwiNXrKp1O618tY6bHHcxg AT mail DOT gmail DOT com>
 <831rfx4ixg DOT fsf AT gnu DOT org> <6371c322-a0ad-b85a-1ccc-1bdfff4a8d87 AT gmail DOT com>
 <83tust30nj DOT fsf AT gnu DOT org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.dfncis.de zVdj6t1zPuAVN58/BQ+CEASioKWISrYjWyjgQHSDa7hSI15RzPQSM0UxU0
Cancel-Lock: sha1:JvnVnKv6o37Z/v3NbKnf4fZmjBo=
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.5.1
In-Reply-To: <83tust30nj.fsf@gnu.org>
Content-Language: en-US
Bytes: 3639
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

Am 10.12.2020 um 20:45 schrieb Eli Zaretskii (eliz AT gnu DOT org) [via 
djgpp AT delorie DOT com]:
>> From: "J.W. Jagersma (jwjagersma AT gmail DOT com) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
>> Date: Thu, 10 Dec 2020 19:55:11 +0100
>>
>>>> -void (*__stdio_cleanup_hook)(void);
>>>> +extern void (*__stdio_cleanup_hook)(void); /* stdio/stdiohk.c */
>>>
>>> This part I don't understand: are you saying that it is no longer the
>>> default that a function not explicitly declared 'static' has the
>>> external linkage?  Why do we need an explicit 'extern' qualifier?
>>>
>>> Thanks.
>>
>> This only applies to global variables (and __stdio_cleanup_hook here is a
>> function *pointer*), functions themselves still have implicit external linkage.
> 
> And global variables don't?

Kind-a.  In strict standard C, they do, but Unix C compilers have all 
had a common extension since the dawn of time_t: they expand the concept 
of "tentative definitions" (C99 6.9.2p2) from translation units to the 
entire program, i.e. a non-initialized definition effectively remains in 
"tentative" state until link-time.  This extension was so wide-spread 
that it's actually listed in the C standard informative annex J.5.11.

Or, to put it in terms of GCC options: -fcommon is againnst the C 
standard, but it has always been the Unix standard.  The reason is 
hinted at by the name of the option: COMMON is a FORTRAN concept which 
Unix linkers had to support from the get-go, and it's technically 
equivalent to joining tentative definitions across translation units. 
(A FORTRAN named COMMON translates to a global, un-initialized struct 
variable.  Individual translation units define it, then the linker puts 
them all in the same place.)

So GCC 10 switched this default to the C standard-conforming value, 
-fno-common, and that will break code which relied on -fcommon without 
ever knowing it did.

And BTW the correct solution of this issue is _not_ to just put "extern" 
in front of existing definitions, but rather to remove all but a single 
one of those entirely, and replace them by #includes of the header that 
does hold the corresponding extern declaration.

Rules of thumb: never write "extern" in a *.c file, and never write 
"static" in a *.h file.  You'll know when you're hitting an exception to 
this rule.