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." Kind regards, Aaron [1] https://github.com/cplusplus/draft/blob/master/papers/n4835.pdf -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org