Bugzilla – Bug 1148335
LTO: cxxtools build failure
Last modified: 2020-02-18 04:56:56 UTC
Created attachment 815846 [details]
LTO: cxxtools build failure
for i586/x86_64 and ppc64/ppc64le
most probably because configure checking atomicity as 'att_arm'
[ 124s] checking atomic type... att_arm
[ 176s] /tmp/ccY7ghas.s: Assembler messages:
[ 176s] /tmp/ccY7ghas.s:13230: Error: unrecognized opcode: `ldr'
[ 176s] /tmp/ccY7ghas.s:13232: Error: unrecognized opcode: `swp'
disabling LTO seems to be sufficient to bypass problem.
Lemme take a look.
So the problem is in configure (w/ LTO vs. w/o LTO):
@@ -376,7 +732,7 @@
checking whether the g++ linker (/usr/x86_64-suse-linux/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
-checking atomic type... att_x86_64
+checking atomic type... att_arm
configure: checking for suseconds_t...
checking for suseconds_t... yes
checking that generated files are newer than configure... done
The code snippet is:
$ cat atomic2.c
typedef std::sig_atomic_t atomic_t;
void atomicIncrement(volatile atomic_t& dest)
int a, b, c;
asm volatile ( "0:\n\t"
"ldr %0, [%3]\n\t"
"add %1, %0, %4\n\t"
"swp %2, %1, [%3]\n\t"
"cmp %0, %2\n\t"
"swpne %1, %2, [%3]\n\t"
: "=&r" (a), "=&r" (b), "=&r" (c)
: "r" (&dest), "r" (1)
: "cc", "memory");
$ g++ atomic2.c -flto
atomic2.c: Assembler messages:
atomic2.c:17: Error: no such instruction: `ldr %esi,[%rax]'
atomic2.c:18: Error: number of operands mismatch for `add'
atomic2.c:19: Error: no such instruction: `swp %edx,%ecx,[%rax]'
atomic2.c:21: Error: no such instruction: `swpne %ecx,%edx,[%rax]'
atomic2.c:22: Error: no such instruction: `bne 0b'
lto-wrapper: fatal error: g++ returned 1 exit status
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
$ g++ atomic2.c -c -flto
The reason is that you need to assemble the object into a final executable.
I would recommend to link it to a shared library.
Is the source ref in spec (1), still a valid one ?
There is a github git tree (2) with more commits after version 2.2.1 among which a recent commit (3) that remove the atomicity lines but not directly applicable to current 2.2.1 version.
Would need more work.
I am stopping my investigation here.
(In reply to Michel Normand from comment #3)
> Is the source ref in spec (1), still a valid one ?
Hm, it's really down.
> There is a github git tree (2) with more commits after version 2.2.1 among
> which a recent commit (3) that remove the atomicity lines but not directly
> applicable to current 2.2.1 version.
> Would need more work.
> I am stopping my investigation here.
Well, it will probably not help us here. I would recommend to use something like AC_LANG_PROGRAM.
> (1) http://www.tntnet.org/cxxtools.html
> (2) https://github.com/maekitalo/cxxtools
I made a request https://build.opensuse.org/request/show/767605 to use source tarball from github. Tarball looks different because it was not made via make dist and is normal github tagged release. However it seems that github is more reliable than random third party sites nowadays and I should have used it before.
I can't help you with ppcle64 related stuff, sorry. So I unassigned myself from this issue.