Bug 2250265
| Summary: | s390 cross-compiler isn't suiteable for building openssl | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Dmitry Belyavskiy <dbelyavs> |
| Component: | cross-gcc | Assignee: | David Howells <dhowells> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 39 | CC: | dan, dhowells, dmalcolm, epel-packagers-sig, fweimer, jakub, jlaw, jwakely, lkundrak, mcermak, mpolacek, msebor, nickc, nixuser, pbrobinson, sipoyare |
| Target Milestone: | --- | Keywords: | DevelBlocker |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2024-05-13 16:06:47 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Dmitry Belyavskiy
2023-11-17 11:55:35 UTC
Also, if I unpack the glibc-headers-s390 manually and add it via -I, I get a different error:
dbelyavs@fedora:~/upstream/s390/openssl1$ s390x-linux-gnu-gcc -I`pwd`/../include -I. -Iinclude -Iapps/include -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -Wno-stringop-overflow -DOPENSSL_USE_NODELETE -DB_ENDIAN -DOPENSSL_PIC -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib64/engines-3\"" -DMODULESDIR="\"/usr/local/lib64/ossl-modules\"" -DOPENSSL_BUILDING_OPENSSL -DNDEBUG -MMD -MF apps/lib/libapps-lib-app_libctx.d.tmp -MT apps/lib/libapps-lib-app_libctx.o -c -o apps/lib/libapps-lib-app_libctx.o apps/lib/app_libctx.c
In file included from /home/dbelyavs/upstream/s390/openssl/../include/features.h:527,
from /home/dbelyavs/upstream/s390/openssl/../include/bits/libc-header-start.h:33,
from /home/dbelyavs/upstream/s390/openssl/../include/limits.h:26,
from include/openssl/types.h:26,
from apps/include/app_libctx.h:13,
from apps/lib/app_libctx.c:9:
/home/dbelyavs/upstream/s390/openssl/../include/gnu/stubs.h:11:11: fatal error: gnu/stubs-64.h: No such file or directory
11 | # include <gnu/stubs-64.h>
It seems you are using the cross-gcc compilers. Reassigning. My understanding is that those cross-compilers are not intended for userspace. CentOS 9 Stream has cross-compilers that work for userspace. We plan to forward-port those to Fedora 40. (In reply to Florian Weimer from comment #2) > It seems you are using the cross-gcc compilers. Reassigning. > > My understanding is that those cross-compilers are not intended for > userspace. CentOS 9 Stream has cross-compilers that work for userspace. We That's correct, the Fedora cross-compilers are supplied without any userspace libs as their are intended for kernel or firmware development. But they are built with sysroot support, so the users can provide the required libs on their own. > plan to forward-port those to Fedora 40. Dmitry, why are trying to cross-compile openssl instead of doing a native build? (In reply to Dan Horák from comment #3) > (In reply to Florian Weimer from comment #2) > > It seems you are using the cross-gcc compilers. Reassigning. > > > > My understanding is that those cross-compilers are not intended for > > userspace. CentOS 9 Stream has cross-compilers that work for userspace. We > > That's correct, the Fedora cross-compilers are supplied without any > userspace libs as their are intended for kernel or firmware development. But > they are built with sysroot support, so the users can provide the required > libs on their own. I planned to use qemu for the next tests, it should resolve the lack of the userspace libs, doesn't it? > > plan to forward-port those to Fedora 40. > > Dmitry, why are trying to cross-compile openssl instead of doing a native > build? Cross-compilation+qemu is suitable for test automation, native build is not. See, e.g. https://github.com/openssl/openssl/blob/master/.github/workflows/cross-compiles.yml - I wanted to implement smth similar for my purposes. (In reply to Dmitry Belyavskiy from comment #4) > (In reply to Dan Horák from comment #3) > > (In reply to Florian Weimer from comment #2) > > > It seems you are using the cross-gcc compilers. Reassigning. > > > > > > My understanding is that those cross-compilers are not intended for > > > userspace. CentOS 9 Stream has cross-compilers that work for userspace. We > > > > That's correct, the Fedora cross-compilers are supplied without any > > userspace libs as their are intended for kernel or firmware development. But > > they are built with sysroot support, so the users can provide the required > > libs on their own. > > I planned to use qemu for the next tests, it should resolve the lack of the > userspace libs, doesn't it? I don't think so, with the sysroot you should install (eg with rpm2cpio) the native s390x lib & headers into the /usr/s390x-linux-gnu/sys-root (see https://src.fedoraproject.org/rpms/cross-gcc/blob/rawhide/f/cross-gcc.spec#_572), then the compiler should pick them, but I haven't tried that personally > > > plan to forward-port those to Fedora 40. > > > > Dmitry, why are trying to cross-compile openssl instead of doing a native > > build? > > Cross-compilation+qemu is suitable for test automation, native build is not. > See, e.g. > https://github.com/openssl/openssl/blob/master/.github/workflows/cross- > compiles.yml - I wanted to implement smth similar for my purposes. I would think a shared or dedicated native VM would be easier for CI purposes (available from IBM Cloud for open source projects), but probably not here ... The cross-gcc is designed for static linked binaries such as firmware or standalone binaries, it's complex to deal with shared libraries builds because you need to have chroot envs etc. |