Building 32 bit packages for centos8

[Stephen John Smoogen]

On Sat, 19 Dec 2020 at 03:59, Michael Ivanov <ivans(a)isle.spb.ru&gt; wrote:

>  Hallo,
>
>  I'm trying to build 32 bit rpm package for centos8 with mock. When I
>  specify target arch as i386, then a lot of packages are reported as not
>  found. When arch is omitted, then mock tries to build 64-bit package.
>
>  In mock config I have:
>
>  config_opts['target_arch'] = 'i386'
>  config_opts['legal_host_arches'] = ('x86_64')
>
>  This worked in older centos systems.
>
>  Any hints?
>  
RHEL and CentOS-8 do not have 32 bit support in the default directories. If
you need to build for 32 bit you will need to use the 'altarch' CentOS-8.



>  Best regards,
>
>  --
>   \   / |			           |
>   (OvO) |  Михаил Иванов                    |
>   (^^^) |                                   |
>    \^/  |      E-mail:  ivans(a)isle.spb.ru   |
>    ^ ^  |                                   |
>
>  _______________________________________________
>  buildsys mailing list -- buildsys(a)lists.fedoraproject.org
>  To unsubscribe send an email to buildsys-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]...
>  

-- 
Stephen J Smoogen.

[Florian Weimer]

* Michael Ivanov:

>  Why separate repository would be needed? CentOS-8 as far as I can
> see
>  contains 32-bit versions of all packages that I need. I can manually
>  install them and compile the package, no problems. 
The published i686 package set is not complete enough to create a mock
chroot from it.

There should be a way to get this working for most packages with a
carefully crafted mock configuration that sets up an x86_64 root, but
runs rpmbuild for a 32-bit build.  Or you install a VM with the 32-bit
development packages and run rpmbuild manually.  But some spec files are
simply not compatible with a build environment where gcc defaults to
create 64-bit binaries.

Internally, Red Hat has fully 32-bit buildroots, so we don't run into
this issue.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

[Stephen John Smoogen]

On Mon, 21 Dec 2020 at 05:09, Florian Weimer <fweimer(a)redhat.com&gt; wrote:

>  * Michael Ivanov:
>
>  > Why separate repository would be needed? CentOS-8 as far as I can see
>  > contains 32-bit versions of all packages that I need. I can manually
>  > install them and compile the package, no problems.
>
>  The published i686 package set is not complete enough to create a mock
>  chroot from it.
>
>  There should be a way to get this working for most packages with a
>  carefully crafted mock configuration that sets up an x86_64 root, but
>  runs rpmbuild for a 32-bit build.  Or you install a VM with the 32-bit
>  development packages and run rpmbuild manually.  But some spec files are
>  simply not compatible with a build environment where gcc defaults to
>  create 64-bit binaries.
>
>  Internally, Red Hat has fully 32-bit buildroots, so we don't run into
>  this issue.
>
>  
Thank you Florian

I should have been more explicit and explained better in my email




>  Thanks,
>  Florian
>  --
>  Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
>  Commercial register: Amtsgericht Muenchen, HRB 153243,
>  Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael
>  O'Neill
>  _______________________________________________
>  buildsys mailing list -- buildsys(a)lists.fedoraproject.org
>  To unsubscribe send an email to buildsys-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]...
>  

-- 
Stephen J Smoogen.