Am 01.04.20 um 20:14 schrieb Stefan Brüns:
On Mittwoch, 1. April 2020 19:44:04 CEST Jason
The reason for that being that store() is defined
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
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
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
published draft  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."
I can only confirm what Aaron says. More details can be seen here:
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