[opensuse-packaging] Re: Weird "undefined reference" only for TW x64
On Donnerstag, 2. April 2020 09:33:06 CEST Martin Liška wrote:
On 4/2/20 12:34 AM, Aaron Puchert wrote:
Am 01.04.20 um 20:14 schrieb Stefan Brüns:
On Mittwoch, 1. April 2020 19:44:04 CEST Jason Craig wrote:
The reason for that being that store() is defined "inline" in binarystoragebuffer.c. Inline means to replace the function call with the body of the function wherever it is called. This means you need to have the body of the function in the header file (binarystoragebuffer.h), not a source file. By the time the source file is compiled and linking is happening, it is too late to inline a function.
So I'd guess that in the other versions gcc has ignored the inline and treated it as a normal function, whereas the Tumbleweed x86_64 has honored the inline and dropped the function from the object file.
To fix it, the simplest way is to remove "inline" from the function definition. You could also move the inline definition to the header file, but as demonstrated this function is fairly unlikely to actually be inlined by the compiler.
This seems to be a regression, as it deviates from GCCs own documentation: https://gcc.gnu.org/onlinedocs/gcc/Inline.html
I thought so too, but looking at the standard seems to indicate that GCC
is allowed to do this (http://eel.is/c++draft/dcl.inline#5): If a function or variable with external or module linkage is declared inline in one definition domain, an inline declaration of it shall be reachable from the end of every definition domain in which it is declared; no diagnostic is required.
"Definition domain" is what used to be a "translation unit", the latest published draft [1] still uses that term.
Of course GCC can provide guarantees beyond the requirements of the standard, if the developers want to, since "no diagnostic is required."
Hello.
I can only confirm what Aaron says. More details can be seen here: https://gcc.gnu.org/onlinedocs/gcc/Inline.html
"" When an inline function is not static, then the compiler must assume that there may be calls from other source files; since a global symbol can be defined only once in any program, the function must not be defined in the other source files, so the calls therein cannot be integrated. Therefore, a non-static inline function is always compiled on its own in the usual fashion. ""
In a single translation unit, the compiler is free to inline some instances of a function, and keep some invocations as function calls, correct? So what contradicts keeping exactly *one* definition (in this case in binarystoragebuffer.cpp) with external linkage? This does not contradict "not be defined in the other source files". There is exactly one instance of the symbol. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
On 4/2/2020 03:52, Stefan Brüns wrote:
In a single translation unit, the compiler is free to inline some instances of a function, and keep some invocations as function calls, correct?
So what contradicts keeping exactly *one* definition (in this case in binarystoragebuffer.cpp) with external linkage? This does not contradict "not be defined in the other source files". There is exactly one instance of the symbol.
Kind regards,
Stefan
What I did not see before which is contributing to the problem is that the file binarystoragebuffer.cc is #included in three or four other .cc files. So in this case it IS defined in other source files. regards, -- Jason Craig -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (2)
-
Jason Craig
-
Stefan Brüns