Bug 2250265 - s390 cross-compiler isn't suiteable for building openssl
Summary: s390 cross-compiler isn't suiteable for building openssl
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: cross-gcc
Version: 39
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: David Howells
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-11-17 11:55 UTC by Dmitry Belyavskiy
Modified: 2024-05-13 16:06 UTC (History)
16 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2024-05-13 16:06:47 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Dmitry Belyavskiy 2023-11-17 11:55:35 UTC
I'm trying to build openssl for s390 using cross-compiler and can't install the necessary package glibc-headers-s390:



Reproducible: Always

Steps to Reproduce:
1. yum install glibc-headers-x86
2. yum glibc-headers-s390
Actual Results:  
Error: Transaction test error:
  file /usr/include/bits/a.out.h from install of glibc-headers-s390-2.38-10.fc39.noarch conflicts with file from package glibc-headers-x86-2.38-10.fc39.noarch
  file /usr/include/bits/dl_find_object.h from install of glibc-headers-s390-2.38-10.fc39.noarch conflicts with file from package glibc-headers-x86-2.38-10.fc39.noarch
  file /usr/include/bits/elfclass.h from install of glibc-headers-s390-2.38-10.fc39.noarch conflicts with file from package glibc-headers-x86-2.38-10.fc39.noarch
  file /usr/include/bits/endianness.h from install of glibc-headers-s390-2.38-10.fc39.noarch conflicts with file from package glibc-headers-x86-2.38-10.fc39.noarch
  file /usr/include/bits/environments.h from install of glibc-headers-s390-2.38-10.fc39.noarch conflicts with file from package glibc-headers-x86-2.38-10.fc39.noarch
  file /usr/include/bits/epoll.h from install of glibc-headers-s390-2.38-10.fc39.noarch conflicts with file from package glibc-headers-x86-2.38-10.fc39.noarch
  file /usr/include/bits/fcntl.h from install of glibc-headers-s390-2.38-10.fc39.noarch conflicts with file from package glibc-headers-x86-2.38-10.fc39.noarch
...

Expected Results:  
successful installation

I'd expect that the files are to be installed into /usr/lib/gcc/s390x-linux-gnu/13


My goal is a cross-compiling openssl.

(git clone openssl)
(install necessary stuff, see openssl.spec)
(yum install binutils-s390x-linux-gnu.x86_64 gcc-s390x-linux-gnu.x86_64 qemu-system-s390x.x86_64 qemu-system-s390x-core.x86_64 qemu-user-static-s390x.x86_64)

./config --cross-compile-prefix=s390x-linux-gnu- linux64-s390x -Wno-stringop-overflow

I get an error 

inttypes.h: No such file or directory
  234 | #  include <inttypes.h>

as inttypes.h is not provided by other s390x cross-compile files

Comment 1 Dmitry Belyavskiy 2023-11-17 12:13:47 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>

Comment 2 Florian Weimer 2023-11-17 12:23:44 UTC
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.

Comment 3 Dan Horák 2023-11-17 15:12:35 UTC
(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?

Comment 4 Dmitry Belyavskiy 2023-11-17 16:37:02 UTC
(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.

Comment 5 Dan Horák 2023-11-17 17:10:13 UTC
(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 ...

Comment 6 Peter Robinson 2024-05-13 16:06:47 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.