On 12/7/21 11:55, Sarah Julia Kriesch wrote:>> An excerpt from the build log which shows the failing parts would be helpful.
/usr/lib64/gcc/s390x-suse-linux/11/../../../../s390x-suse-linux/bin/ld: @GLIBCXX_3.4.11: TLS reference in /usr/lib64/libLLVM.so mismatches non-TLS reference in /usr/lib64/libLLVM.so /usr/lib64/gcc/s390x-suse-linux/11/../../../../s390x-suse-linux/bin/ld: /usr/lib64/libLLVM.so: error adding symbols: bad value collect2: error: ld returned 1 exit status make[2]: *** [../../../../src/Makefile.shlib:309: llvmjit.so] Error 1
This sounds like a linker issue. I would compare the binutils versions used in Debian, Fedora and openSUSE for a starter.
We have got the same problem with Rust1.54 with a longer exception: Compiling rustc_driver v0.0.0 (/home/abuild/rpmbuild/BUILD/rustc-1.54.0-src/compiler/rustc_driver) (...) [15144s] = note: /usr/lib64/gcc/s390x-suse-linux/11/../../../../s390x-suse-linux/bin/ld: @GLIBCXX_3.4.11: TLS reference in /usr/lib64/libLLVM.so mismatches non-TLS reference in /usr/lib64/libLLVM.so [15144s] /usr/lib64/gcc/s390x-suse-linux/11/../../../../s390x-suse-linux/bin/ld: /usr/lib64/libLLVM.so: error adding symbols: bad value [15144s] collect2: error: ld returned 1 exit status
Not surprising given that rustc also links against libLLVM.
FWIW, postgresql-14 also fails to build from source (FTBFS) on Debian unstable on s390x:
But it seems to be a testsuite failure in this case.
Fedora is switching to PostgreSQL14 for the next release version at the moment. But they will need some time for x86 before porting it for s390x.
I think "porting" is the wrong term in this context. It already works on s390x in general ;-).
IBMers are in the worst case situation, that it is difficult to receive VMs based on openSUSE.
What about trying to reproduce the issue on qemu-system-s390x?
That will be used by the osc command on IBM Z.
That's not what I meant. I would suggest installing an openSUSE s390x instance inside qemu-system-s390x which should also work on x86_64. Adrian