Bug 1148335 - LTO: cxxtools build failure
LTO: cxxtools build failure
Status: NEW
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Development
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Michal Vyskocil
E-mail List
:
Depends on:
Blocks: 1133084
  Show dependency treegraph
 
Reported: 2019-08-27 11:34 UTC by Michel Normand
Modified: 2020-02-18 04:56 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
cxxtools_standard__ppc64le_201908271102.log (256.88 KB, text/x-log)
2019-08-27 11:34 UTC, Michel Normand
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michel Normand 2019-08-27 11:34:51 UTC
Created attachment 815846 [details]
cxxtools_standard__ppc64le_201908271102.log

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.
Comment 1 Martin Liška 2019-08-27 11:39:02 UTC
Lemme take a look.
Comment 2 Martin Liška 2019-08-27 11:56:04 UTC
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
        #include <csignal>
        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"
                                       "bne 0b"
                                       : "=&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
compilation terminated.
/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
[ok]

The reason is that you need to assemble the object into a final executable.
I would recommend to link it to a shared library.
Comment 3 Michel Normand 2019-08-27 11:59:51 UTC
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.

(1) http://www.tntnet.org/cxxtools.html
(2) https://github.com/maekitalo/cxxtools
(3) https://github.com/maekitalo/cxxtools/commit/c5baa0b7756ee88f51ec58fe9a4d3b416266cc9f
Comment 4 Martin Liška 2019-08-27 14:31:43 UTC
(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
> (3)
> https://github.com/maekitalo/cxxtools/commit/
> c5baa0b7756ee88f51ec58fe9a4d3b416266cc9f
Comment 5 Michal Vyskocil 2020-01-27 09:53:01 UTC
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.