Hi list,
I'm trying to build mold for epel8. A bunch of mold's unit tests produce statically linked 32-bit binaries, so on x86_64 we need a build dependency on a static multilib glibc.
I have learnt that multilib build dependencies are a tricky thing in Koji, and the only solution I have found to work is to specify a filename-based dependency: `BuildDepends: /usr/lib/libc.a`
This works fine for rawhide, f35, f34 and epel9 but fails on epel8: ``` No matching package to install: '/usr/lib/libc.a' ``` Full build log: https://kojipkgs.fedoraproject.org/work/tasks/2503/81962503/mock_output.log
Any ideas?
Best, Christoph
* Christoph Erhardt:
I'm trying to build mold for epel8. A bunch of mold's unit tests produce statically linked 32-bit binaries, so on x86_64 we need a build dependency on a static multilib glibc.
I have learnt that multilib build dependencies are a tricky thing in Koji, and the only solution I have found to work is to specify a filename-based dependency: `BuildDepends: /usr/lib/libc.a`
This works fine for rawhide, f35, f34 and epel9 but fails on epel8:
No matching package to install: '/usr/lib/libc.a'Full build log: https://kojipkgs.fedoraproject.org/work/tasks/2503/81962503/mock_output.log
Any ideas?
We do not support cross-building, so you'd have to use a 32-bit builder for building 32-bit binaries (which does not exist for EPEL). You can test this in an gating/integration test, which can install the i686 packages.
You don't see this in Fedora because it we have the glibc32 package there, but it's a hideous hack that needs to go away. It only exists to support building glibc itself.
Thanks, Florian
* Florian Weimer:
- Christoph Erhardt:
I'm trying to build mold for epel8. A bunch of mold's unit tests produce statically linked 32-bit binaries, so on x86_64 we need a build dependency on a static multilib glibc.
I have learnt that multilib build dependencies are a tricky thing in Koji, and the only solution I have found to work is to specify a filename-based dependency: `BuildDepends: /usr/lib/libc.a`
This works fine for rawhide, f35, f34 and epel9 but fails on epel8:
No matching package to install: '/usr/lib/libc.a'Full build log: https://kojipkgs.fedoraproject.org/work/tasks/2503/81962503/mock_output.log
Any ideas?
We do not support cross-building, so you'd have to use a 32-bit builder for building 32-bit binaries (which does not exist for EPEL). You can test this in an gating/integration test, which can install the i686 packages.
You don't see this in Fedora because it we have the glibc32 package there, but it's a hideous hack that needs to go away. It only exists to support building glibc itself.
Sorry, that should be “support building gcc with multilib support”.
Florian
I'm not actually trying to cross-build mold for i686; my goal is to do a regular x86_64 build of mold and to run its complete testsuite.
Since mold is a linker that supports multiple target architectures, its testsuite contains a bunch of scripts that explicitly invoke `cc -m32` and `cc -m32 -static` to cover mold's i686-specific code paths. Obviously, these fail if no 32-bit libc is present.
I could disable these particular unit tests (10 out of 201, to be precise) - but I'm unsure whether that would be a wise thing to do.
Best, Christoph
On Thursday, 27 January 2022 19:08:39 CET Florian Weimer wrote:
- Florian Weimer:
- Christoph Erhardt:
We do not support cross-building, so you'd have to use a 32-bit builder for building 32-bit binaries (which does not exist for EPEL). You can test this in an gating/integration test, which can install the i686 packages.
You don't see this in Fedora because it we have the glibc32 package there, but it's a hideous hack that needs to go away. It only exists to support building glibc itself.
Sorry, that should be “support building gcc with multilib support”.
Florian _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
* Christoph Erhardt:
I'm not actually trying to cross-build mold for i686; my goal is to do a regular x86_64 build of mold and to run its complete testsuite.
Yes, I understood that. x86_64 buildroots only have x86_64 packages in Koji. You cannot build and run 32-bit binaries (unless you put them together completely from scratch, without help from i686 RPM packages).
Since mold is a linker that supports multiple target architectures, its testsuite contains a bunch of scripts that explicitly invoke `cc -m32` and `cc -m32 -static` to cover mold's i686-specific code paths. Obviously, these fail if no 32-bit libc is present.
I could disable these particular unit tests (10 out of 201, to be precise) - but I'm unsure whether that would be a wise thing to do.
Do we have CI for EPEL? You could run the tests there.
Thanks, Florian
Hi Florian,
Yes, I understood that. x86_64 buildroots only have x86_64 packages in Koji. You cannot build and run 32-bit binaries (unless you put them together completely from scratch, without help from i686 RPM packages).
alright, thank you for clarifying!
Curiously though, the Koji build for epel9 does find and install a `glibc-static.i686` package from the `build` repo: https://kojipkgs.fedoraproject.org//work/tasks/9858/81959858/root.log I presume this is a CentOS package and has nothing to do with Fedora's glibc32 hack, but I still find it interesting that it is found on epel9 but not on epel8.
Is there an overview of - or a simple way to find out - how many and which Fedora packages currently rely on the glibc32 hack?
Do we have CI for EPEL? You could run the tests there.
Given that I'm a freshman Fedora developer, I'm not familiar with that part of the Fedora infrastructure yet. Could someone with pertinent knowledge weigh in on this topic?
Thanks, Christoph
* Christoph Erhardt:
Hi Florian,
Yes, I understood that. x86_64 buildroots only have x86_64 packages in Koji. You cannot build and run 32-bit binaries (unless you put them together completely from scratch, without help from i686 RPM packages).
alright, thank you for clarifying!
Curiously though, the Koji build for epel9 does find and install a `glibc-static.i686` package from the `build` repo: https://kojipkgs.fedoraproject.org//work/tasks/9858/81959858/root.log I presume this is a CentOS package and has nothing to do with Fedora's glibc32 hack, but I still find it interesting that it is found on epel9 but not on epel8.
That's very interesting. I've been told repeatedly that Koji cannot do that. Oh well.
Is there an overview of - or a simple way to find out - how many and which Fedora packages currently rely on the glibc32 hack?
It should be very, very few packages. It's supposed to be gcc only at this point.
Do we have CI for EPEL? You could run the tests there.
Given that I'm a freshman Fedora developer, I'm not familiar with that part of the Fedora infrastructure yet. Could someone with pertinent knowledge weigh in on this topic?
Sorry, I don't know much about the EPEL infrastructure offerings, either.
Thanks, Florian
On Tue, Mar 1, 2022 at 7:44 AM Florian Weimer fweimer@redhat.com wrote:
- Christoph Erhardt:
Hi Florian,
Yes, I understood that. x86_64 buildroots only have x86_64 packages in Koji. You cannot build and run 32-bit binaries (unless you put them together completely from scratch, without help from i686 RPM packages).
alright, thank you for clarifying!
Curiously though, the Koji build for epel9 does find and install a `glibc-static.i686` package from the `build` repo: https://kojipkgs.fedoraproject.org//work/tasks/9858/81959858/root.log I presume this is a CentOS package and has nothing to do with Fedora's glibc32 hack, but I still find it interesting that it is found on epel9 but not on epel8.
That's very interesting. I've been told repeatedly that Koji cannot do that. Oh well.
Koji can do this with "bare mode" external repo handling. That means that all arch filtering of content is handled by DNF instad.
Is there an overview of - or a simple way to find out - how many and which Fedora packages currently rely on the glibc32 hack?
It should be very, very few packages. It's supposed to be gcc only at this point.
Do we have CI for EPEL? You could run the tests there.
Given that I'm a freshman Fedora developer, I'm not familiar with that part of the Fedora infrastructure yet. Could someone with pertinent knowledge weigh in on this topic?
Sorry, I don't know much about the EPEL infrastructure offerings, either.
We have nothing for EPEL. I believe we're trying to get basic FTI tests in place now, but we have nothing currently.
-
Christoph Erhardt -
Florian Weimer -
Neal Gompa