On Mittwoch, 1. April 2020 19:44:04 CEST Jason Craig wrote:
On Wednesday 2020-04-01 18:24, Pierre wrote:
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ttbdmi.cc:(.text+0x46e): undefined reference to `BinaryStorageBuffer::store(void*, unsigned int)' /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ttbdmi.cc:(.text+0x48b): undefined reference to `BinaryStorageBuffer::store(void*, unsigned int)' /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ttbdmi.cc:(.text+0x4a8): undefined reference to `BinaryStorageBuffer::store(void*, unsigned int)' /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ttbdmi.cc:(.text+0x4c5): undefined reference to `BinaryStorageBuffer::store(void*, unsigned int)' /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: src/ttbdmi.o:ttbdmi.cc:(.text+0x4e2): more undefined references to `BinaryStorageBuffer::store(void*, unsigned int)' follow
I don't understand why the "undefined reference" is coming up here (binarystoragebuffer.cc has been compiled into an .o object and should link without a problem?)
Your .o file does not contain the function in question.
abuild@a4:~/rpmbuild/BUILD/Nemo-2.3.51> nm -C src/binarystoragebuffer.o | grep ::store The reason for that being that store() is defined "inline" in binarystoragebuffer.c. Inline means to replace the function call with
On 4/1/2020 11:18, Jan Engelhardt wrote: 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
The three types of inlining behave similarly in two important cases: [...], and when *a function is first declared without using the inline keyword and then is defined with inline*, like this:
extern int inc (int *a); inline int inc (int *a) {
return (*a)++;
}
In both of these common cases, the program behaves the same as if you had not used the inline keyword, except for its speed.
This may be related to LTO. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019