Folks,
In general, we probably want to look at the value of host system type being picked up for ARMv5 builds, especially on ARMv7 builder systems. Here's an example output from running an OpenMPI build on Fedora 18 using the current Koji builder setup, note the "armv7l" target:
--- begin quote --- checking build system type... armv7l-unknown-linux-gnueabi checking host system type... armv7l-unknown-linux-gnueabi checking target system type... armv7l-unknown-linux-gnueabi --- end quote ---
I believe that this is incorrect, at least, this is in question. The compiler options (set elsewhere) are correct from an ABI point of view, and the output will be a soft float ABI target, but it's not the right architecture revision target. It will matter in a few cases. For example when a package is choosing inline assembly or other specifics that differ between ARMv5 and ARMv7. Mostly, we've been lucky in that the differences are small, but I suspect hidden breakage is lurking.
In this specific example, OpenMPI should move to the new GCC atomics stuff in due course, but they have a giant mess called "asmlib" that provides their own custom atomic functions (what could go wrong?) for historical reasons. The macros used to build that are enough to make you gouge your eyes out, but once you figure it out, it's obvious that they do already have ARMv5 assembly code that should work, if it thinks it's building for an armv5l system. And it's faster to just pick that up than reworking a lot of not just code, but also other arches and build macros, and other stuff unique to the OpenMPI atomics setup.
Let's ponder how we're going to fix it. I could be wrong, but I'd think we want to ensure that configure is picking up armv5l-redhat-linux-gnueabi as the host type on armv5tel builds. It should do this irrespective of the actual host architecture of the builder. I tried just force overriding it in a test build with an "%{ifarch} armv5tel" but that wasn't picked up, so I missed something, but in general that's not the right approach anyway. We want something at the r-r-c level.
Comments? Dennis? Peter?
Jon.
On Mon, Jul 30, 2012 at 5:23 AM, Jon Masters jonathan@jonmasters.org wrote:
Folks,
In general, we probably want to look at the value of host system type being picked up for ARMv5 builds, especially on ARMv7 builder systems. Here's an example output from running an OpenMPI build on Fedora 18 using the current Koji builder setup, note the "armv7l" target:
--- begin quote --- checking build system type... armv7l-unknown-linux-gnueabi checking host system type... armv7l-unknown-linux-gnueabi checking target system type... armv7l-unknown-linux-gnueabi --- end quote ---
I believe that this is incorrect, at least, this is in question. The compiler options (set elsewhere) are correct from an ABI point of view, and the output will be a soft float ABI target, but it's not the right architecture revision target. It will matter in a few cases. For example when a package is choosing inline assembly or other specifics that differ between ARMv5 and ARMv7. Mostly, we've been lucky in that the differences are small, but I suspect hidden breakage is lurking.
In this specific example, OpenMPI should move to the new GCC atomics stuff in due course, but they have a giant mess called "asmlib" that provides their own custom atomic functions (what could go wrong?) for historical reasons. The macros used to build that are enough to make you gouge your eyes out, but once you figure it out, it's obvious that they do already have ARMv5 assembly code that should work, if it thinks it's building for an armv5l system. And it's faster to just pick that up than reworking a lot of not just code, but also other arches and build macros, and other stuff unique to the OpenMPI atomics setup.
Let's ponder how we're going to fix it. I could be wrong, but I'd think we want to ensure that configure is picking up armv5l-redhat-linux-gnueabi as the host type on armv5tel builds. It should do this irrespective of the actual host architecture of the builder. I tried just force overriding it in a test build with an "%{ifarch} armv5tel" but that wasn't picked up, so I missed something, but in general that's not the right approach anyway. We want something at the r-r-c level.
Comments? Dennis? Peter?
It should always take the details that the build system is telling it and not the underlying platform without exception. The same goes with features like NEON (and MMX/SSE on x86). I've fixed a number of these before.
Peter
On 07/30/2012 03:13 AM, Peter Robinson wrote:
On Mon, Jul 30, 2012 at 5:23 AM, Jon Masters jonathan@jonmasters.org wrote:
Folks,
In general, we probably want to look at the value of host system type being picked up for ARMv5 builds, especially on ARMv7 builder systems. Here's an example output from running an OpenMPI build on Fedora 18 using the current Koji builder setup, note the "armv7l" target:
--- begin quote --- checking build system type... armv7l-unknown-linux-gnueabi checking host system type... armv7l-unknown-linux-gnueabi checking target system type... armv7l-unknown-linux-gnueabi --- end quote ---
I believe that this is incorrect, at least, this is in question. The compiler options (set elsewhere) are correct from an ABI point of view, and the output will be a soft float ABI target, but it's not the right architecture revision target. It will matter in a few cases. For example when a package is choosing inline assembly or other specifics that differ between ARMv5 and ARMv7. Mostly, we've been lucky in that the differences are small, but I suspect hidden breakage is lurking.
In this specific example, OpenMPI should move to the new GCC atomics stuff in due course, but they have a giant mess called "asmlib" that provides their own custom atomic functions (what could go wrong?) for historical reasons. The macros used to build that are enough to make you gouge your eyes out, but once you figure it out, it's obvious that they do already have ARMv5 assembly code that should work, if it thinks it's building for an armv5l system. And it's faster to just pick that up than reworking a lot of not just code, but also other arches and build macros, and other stuff unique to the OpenMPI atomics setup.
Let's ponder how we're going to fix it. I could be wrong, but I'd think we want to ensure that configure is picking up armv5l-redhat-linux-gnueabi as the host type on armv5tel builds. It should do this irrespective of the actual host architecture of the builder. I tried just force overriding it in a test build with an "%{ifarch} armv5tel" but that wasn't picked up, so I missed something, but in general that's not the right approach anyway. We want something at the r-r-c level.
Comments? Dennis? Peter?
It should always take the details that the build system is telling it and not the underlying platform without exception. The same goes with features like NEON (and MMX/SSE on x86). I've fixed a number of these before.
Good. Then you agree it should be thinking armv5l-redhat-linux-gnueabi there and this is a bug we need to fix. If we figure out why this is happening, OpenMPI should just build. Meanwhile, if you do setup a "wimpybuilder" channel for v5-specific builds, you could add OpenMPI into that channel and it ought to build if the host is ARMv5. I also thinking we could do something to get at least one successful build through by ensuring it runs on a system that is an ARMv5 host. Then we'd at least have an openmpi package that had been built as a dep.
I'll ping you and others later about fixing this. Got to finish this article on atomics now. When I'm done, we should have material others can use to help fix issues. Not this issue, this isn't really an atomics issue as it turns out.
Jon.
On Mon, Jul 30, 2012 at 8:26 AM, Jon Masters jonathan@jonmasters.org wrote:
On 07/30/2012 03:13 AM, Peter Robinson wrote:
On Mon, Jul 30, 2012 at 5:23 AM, Jon Masters jonathan@jonmasters.org wrote:
Folks,
In general, we probably want to look at the value of host system type being picked up for ARMv5 builds, especially on ARMv7 builder systems. Here's an example output from running an OpenMPI build on Fedora 18 using the current Koji builder setup, note the "armv7l" target:
--- begin quote --- checking build system type... armv7l-unknown-linux-gnueabi checking host system type... armv7l-unknown-linux-gnueabi checking target system type... armv7l-unknown-linux-gnueabi --- end quote ---
I believe that this is incorrect, at least, this is in question. The compiler options (set elsewhere) are correct from an ABI point of view, and the output will be a soft float ABI target, but it's not the right architecture revision target. It will matter in a few cases. For example when a package is choosing inline assembly or other specifics that differ between ARMv5 and ARMv7. Mostly, we've been lucky in that the differences are small, but I suspect hidden breakage is lurking.
In this specific example, OpenMPI should move to the new GCC atomics stuff in due course, but they have a giant mess called "asmlib" that provides their own custom atomic functions (what could go wrong?) for historical reasons. The macros used to build that are enough to make you gouge your eyes out, but once you figure it out, it's obvious that they do already have ARMv5 assembly code that should work, if it thinks it's building for an armv5l system. And it's faster to just pick that up than reworking a lot of not just code, but also other arches and build macros, and other stuff unique to the OpenMPI atomics setup.
Let's ponder how we're going to fix it. I could be wrong, but I'd think we want to ensure that configure is picking up armv5l-redhat-linux-gnueabi as the host type on armv5tel builds. It should do this irrespective of the actual host architecture of the builder. I tried just force overriding it in a test build with an "%{ifarch} armv5tel" but that wasn't picked up, so I missed something, but in general that's not the right approach anyway. We want something at the r-r-c level.
Comments? Dennis? Peter?
It should always take the details that the build system is telling it and not the underlying platform without exception. The same goes with features like NEON (and MMX/SSE on x86). I've fixed a number of these before.
Good. Then you agree it should be thinking armv5l-redhat-linux-gnueabi there and this is a bug we need to fix. If we figure out why this is happening, OpenMPI should just build. Meanwhile, if you do setup a "wimpybuilder" channel for v5-specific builds, you could add OpenMPI into that channel and it ought to build if the host is ARMv5. I also thinking we could do something to get at least one successful build through by ensuring it runs on a system that is an ARMv5 host. Then we'd at least have an openmpi package that had been built as a dep.
I'll have a play to get it on a guru builder.
Peter
On Mon, Jul 30, 2012 at 8:26 AM, Jon Masters jonathan@jonmasters.org wrote:
On 07/30/2012 03:13 AM, Peter Robinson wrote:
On Mon, Jul 30, 2012 at 5:23 AM, Jon Masters jonathan@jonmasters.org wrote:
Folks,
In general, we probably want to look at the value of host system type being picked up for ARMv5 builds, especially on ARMv7 builder systems. Here's an example output from running an OpenMPI build on Fedora 18 using the current Koji builder setup, note the "armv7l" target:
--- begin quote --- checking build system type... armv7l-unknown-linux-gnueabi checking host system type... armv7l-unknown-linux-gnueabi checking target system type... armv7l-unknown-linux-gnueabi --- end quote ---
I believe that this is incorrect, at least, this is in question. The compiler options (set elsewhere) are correct from an ABI point of view, and the output will be a soft float ABI target, but it's not the right architecture revision target. It will matter in a few cases. For example when a package is choosing inline assembly or other specifics that differ between ARMv5 and ARMv7. Mostly, we've been lucky in that the differences are small, but I suspect hidden breakage is lurking.
In this specific example, OpenMPI should move to the new GCC atomics stuff in due course, but they have a giant mess called "asmlib" that provides their own custom atomic functions (what could go wrong?) for historical reasons. The macros used to build that are enough to make you gouge your eyes out, but once you figure it out, it's obvious that they do already have ARMv5 assembly code that should work, if it thinks it's building for an armv5l system. And it's faster to just pick that up than reworking a lot of not just code, but also other arches and build macros, and other stuff unique to the OpenMPI atomics setup.
Let's ponder how we're going to fix it. I could be wrong, but I'd think we want to ensure that configure is picking up armv5l-redhat-linux-gnueabi as the host type on armv5tel builds. It should do this irrespective of the actual host architecture of the builder. I tried just force overriding it in a test build with an "%{ifarch} armv5tel" but that wasn't picked up, so I missed something, but in general that's not the right approach anyway. We want something at the r-r-c level.
Comments? Dennis? Peter?
It should always take the details that the build system is telling it and not the underlying platform without exception. The same goes with features like NEON (and MMX/SSE on x86). I've fixed a number of these before.
Good. Then you agree it should be thinking armv5l-redhat-linux-gnueabi there and this is a bug we need to fix. If we figure out why this is happening, OpenMPI should just build. Meanwhile, if you do setup a "wimpybuilder" channel for v5-specific builds, you could add OpenMPI into that channel and it ought to build if the host is ARMv5. I also thinking we could do something to get at least one successful build through by ensuring it runs on a system that is an ARMv5 host. Then we'd at least have an openmpi package that had been built as a dep.
Still fails.
http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1020679
Peter
Peter Robinson pbrobinson@gmail.com wrote:
On Mon, Jul 30, 2012 at 8:26 AM, Jon Masters jonathan@jonmasters.org wrote:
On 07/30/2012 03:13 AM, Peter Robinson wrote:
On Mon, Jul 30, 2012 at 5:23 AM, Jon Masters
jonathan@jonmasters.org wrote:
Folks,
In general, we probably want to look at the value of host system
type
being picked up for ARMv5 builds, especially on ARMv7 builder
systems.
Here's an example output from running an OpenMPI build on Fedora 18 using the current Koji builder setup, note the "armv7l" target:
--- begin quote --- checking build system type... armv7l-unknown-linux-gnueabi checking host system type... armv7l-unknown-linux-gnueabi checking target system type... armv7l-unknown-linux-gnueabi --- end quote ---
I believe that this is incorrect, at least, this is in question.
The
compiler options (set elsewhere) are correct from an ABI point of
view,
and the output will be a soft float ABI target, but it's not the
right
architecture revision target. It will matter in a few cases. For
example
when a package is choosing inline assembly or other specifics that differ between ARMv5 and ARMv7. Mostly, we've been lucky in that
the
differences are small, but I suspect hidden breakage is lurking.
In this specific example, OpenMPI should move to the new GCC
atomics
stuff in due course, but they have a giant mess called "asmlib"
that
provides their own custom atomic functions (what could go wrong?)
for
historical reasons. The macros used to build that are enough to
make you
gouge your eyes out, but once you figure it out, it's obvious that
they
do already have ARMv5 assembly code that should work, if it thinks
it's
building for an armv5l system. And it's faster to just pick that up
than
reworking a lot of not just code, but also other arches and build macros, and other stuff unique to the OpenMPI atomics setup.
Let's ponder how we're going to fix it. I could be wrong, but I'd
think
we want to ensure that configure is picking up armv5l-redhat-linux-gnueabi as the host type on armv5tel builds. It should do this irrespective of the actual host architecture of the builder. I tried just force overriding it in a test build with an "%{ifarch} armv5tel" but that wasn't picked up, so I missed
something,
but in general that's not the right approach anyway. We want
something
at the r-r-c level.
Comments? Dennis? Peter?
It should always take the details that the build system is telling
it
and not the underlying platform without exception. The same goes
with
features like NEON (and MMX/SSE on x86). I've fixed a number of
these
before.
Good. Then you agree it should be thinking
armv5l-redhat-linux-gnueabi
there and this is a bug we need to fix. If we figure out why this is happening, OpenMPI should just build. Meanwhile, if you do setup a "wimpybuilder" channel for v5-specific builds, you could add OpenMPI into that channel and it ought to build if the host is ARMv5. I also thinking we could do something to get at least one successful build through by ensuring it runs on a system that is an ARMv5 host. Then
we'd
at least have an openmpi package that had been built as a dep.
Still fails.
http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1020679
Peter
Thanks. It's picking the wrong bits but for a different reason. I'll hack up a v5 builder environment of my own later and fix it. The point is there are two ways to fix openmpi:
1. Make it build the v5 code it has. 2. Remove all of its asmlib and replace with a few lines of C. Easy but it's a large patch to carry and so for this case only 1 is preferable for the moment.
Not online yet. I just woke up briefly and couldn't help reading email. Back in a few hours.
Jon.
Jon Masters wrote:
On 07/30/2012 03:13 AM, Peter Robinson wrote:
On Mon, Jul 30, 2012 at 5:23 AM, Jon Masters jonathan@jonmasters.org wrote:
Folks,
In general, we probably want to look at the value of host system type being picked up for ARMv5 builds, especially on ARMv7 builder systems. Here's an example output from running an OpenMPI build on Fedora 18 using the current Koji builder setup, note the "armv7l" target:
--- begin quote --- checking build system type... armv7l-unknown-linux-gnueabi checking host system type... armv7l-unknown-linux-gnueabi checking target system type... armv7l-unknown-linux-gnueabi --- end quote ---
I believe that this is incorrect, at least, this is in question. The compiler options (set elsewhere) are correct from an ABI point of view, and the output will be a soft float ABI target, but it's not the right architecture revision target. It will matter in a few cases. For example when a package is choosing inline assembly or other specifics that differ between ARMv5 and ARMv7. Mostly, we've been lucky in that the differences are small, but I suspect hidden breakage is lurking.
In this specific example, OpenMPI should move to the new GCC atomics stuff in due course, but they have a giant mess called "asmlib" that provides their own custom atomic functions (what could go wrong?) for historical reasons. The macros used to build that are enough to make you gouge your eyes out, but once you figure it out, it's obvious that they do already have ARMv5 assembly code that should work, if it thinks it's building for an armv5l system. And it's faster to just pick that up than reworking a lot of not just code, but also other arches and build macros, and other stuff unique to the OpenMPI atomics setup.
Let's ponder how we're going to fix it. I could be wrong, but I'd think we want to ensure that configure is picking up armv5l-redhat-linux-gnueabi as the host type on armv5tel builds. It should do this irrespective of the actual host architecture of the builder. I tried just force overriding it in a test build with an "%{ifarch} armv5tel" but that wasn't picked up, so I missed something, but in general that's not the right approach anyway. We want something at the r-r-c level.
Comments? Dennis? Peter?
It should always take the details that the build system is telling it and not the underlying platform without exception. The same goes with features like NEON (and MMX/SSE on x86). I've fixed a number of these before.
Good. Then you agree it should be thinking armv5l-redhat-linux-gnueabi there and this is a bug we need to fix.
Just for clarification, are you saying that something is not being set correctly (in rpmmacros, etc.) in the v5 mock chroot when v5 builds are being run on a v7 host?
Thanks,
d.marlin =========
If we figure out why this is happening, OpenMPI should just build. Meanwhile, if you do setup a "wimpybuilder" channel for v5-specific builds, you could add OpenMPI into that channel and it ought to build if the host is ARMv5. I also thinking we could do something to get at least one successful build through by ensuring it runs on a system that is an ARMv5 host. Then we'd at least have an openmpi package that had been built as a dep.
I'll ping you and others later about fixing this. Got to finish this article on atomics now. When I'm done, we should have material others can use to help fix issues. Not this issue, this isn't really an atomics issue as it turns out.
Jon. _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
On Mon, Jul 30, 2012 at 2:53 PM, David A. Marlin dmarlin@redhat.com wrote:
Jon Masters wrote:
On 07/30/2012 03:13 AM, Peter Robinson wrote:
On Mon, Jul 30, 2012 at 5:23 AM, Jon Masters jonathan@jonmasters.org wrote:
Folks,
In general, we probably want to look at the value of host system type being picked up for ARMv5 builds, especially on ARMv7 builder systems. Here's an example output from running an OpenMPI build on Fedora 18 using the current Koji builder setup, note the "armv7l" target:
--- begin quote --- checking build system type... armv7l-unknown-linux-gnueabi checking host system type... armv7l-unknown-linux-gnueabi checking target system type... armv7l-unknown-linux-gnueabi --- end quote ---
I believe that this is incorrect, at least, this is in question. The compiler options (set elsewhere) are correct from an ABI point of view, and the output will be a soft float ABI target, but it's not the right architecture revision target. It will matter in a few cases. For example when a package is choosing inline assembly or other specifics that differ between ARMv5 and ARMv7. Mostly, we've been lucky in that the differences are small, but I suspect hidden breakage is lurking.
In this specific example, OpenMPI should move to the new GCC atomics stuff in due course, but they have a giant mess called "asmlib" that provides their own custom atomic functions (what could go wrong?) for historical reasons. The macros used to build that are enough to make you gouge your eyes out, but once you figure it out, it's obvious that they do already have ARMv5 assembly code that should work, if it thinks it's building for an armv5l system. And it's faster to just pick that up than reworking a lot of not just code, but also other arches and build macros, and other stuff unique to the OpenMPI atomics setup.
Let's ponder how we're going to fix it. I could be wrong, but I'd think we want to ensure that configure is picking up armv5l-redhat-linux-gnueabi as the host type on armv5tel builds. It should do this irrespective of the actual host architecture of the builder. I tried just force overriding it in a test build with an "%{ifarch} armv5tel" but that wasn't picked up, so I missed something, but in general that's not the right approach anyway. We want something at the r-r-c level.
Comments? Dennis? Peter?
It should always take the details that the build system is telling it and not the underlying platform without exception. The same goes with features like NEON (and MMX/SSE on x86). I've fixed a number of these before.
Good. Then you agree it should be thinking armv5l-redhat-linux-gnueabi there and this is a bug we need to fix.
Just for clarification, are you saying that something is not being set correctly (in rpmmacros, etc.) in the v5 mock chroot when v5 builds are being run on a v7 host?
No, some projects aren't following the cflags etc as specified in rpmmacros.
Peter
On 07/30/2012 03:05 PM, Peter Robinson wrote:
On Mon, Jul 30, 2012 at 2:53 PM, David A. Marlindmarlin@redhat.com wrote:
Jon Masters wrote:
On 07/30/2012 03:13 AM, Peter Robinson wrote:
On Mon, Jul 30, 2012 at 5:23 AM, Jon Mastersjonathan@jonmasters.org wrote:
Folks,
In general, we probably want to look at the value of host system type being picked up for ARMv5 builds, especially on ARMv7 builder systems. Here's an example output from running an OpenMPI build on Fedora 18 using the current Koji builder setup, note the "armv7l" target:
--- begin quote --- checking build system type... armv7l-unknown-linux-gnueabi checking host system type... armv7l-unknown-linux-gnueabi checking target system type... armv7l-unknown-linux-gnueabi --- end quote ---
I believe that this is incorrect, at least, this is in question. The compiler options (set elsewhere) are correct from an ABI point of view, and the output will be a soft float ABI target, but it's not the right architecture revision target. It will matter in a few cases. For example when a package is choosing inline assembly or other specifics that differ between ARMv5 and ARMv7. Mostly, we've been lucky in that the differences are small, but I suspect hidden breakage is lurking.
In this specific example, OpenMPI should move to the new GCC atomics stuff in due course, but they have a giant mess called "asmlib" that provides their own custom atomic functions (what could go wrong?) for historical reasons. The macros used to build that are enough to make you gouge your eyes out, but once you figure it out, it's obvious that they do already have ARMv5 assembly code that should work, if it thinks it's building for an armv5l system. And it's faster to just pick that up than reworking a lot of not just code, but also other arches and build macros, and other stuff unique to the OpenMPI atomics setup.
Let's ponder how we're going to fix it. I could be wrong, but I'd think we want to ensure that configure is picking up armv5l-redhat-linux-gnueabi as the host type on armv5tel builds. It should do this irrespective of the actual host architecture of the builder. I tried just force overriding it in a test build with an "%{ifarch} armv5tel" but that wasn't picked up, so I missed something, but in general that's not the right approach anyway. We want something at the r-r-c level.
Comments? Dennis? Peter?
It should always take the details that the build system is telling it and not the underlying platform without exception. The same goes with features like NEON (and MMX/SSE on x86). I've fixed a number of these before.
Good. Then you agree it should be thinking armv5l-redhat-linux-gnueabi there and this is a bug we need to fix.
Just for clarification, are you saying that something is not being set correctly (in rpmmacros, etc.) in the v5 mock chroot when v5 builds are being run on a v7 host?
No, some projects aren't following the cflags etc as specified in rpmmacros.
There is quite a lot of that going on. Not only that, but %__cc is frequently ignored, too, so it isn't as easy as it should be to rebuild some packages using a different compiler.
Gordan
Gordan Bobic wrote:
On 07/30/2012 03:05 PM, Peter Robinson wrote:
On Mon, Jul 30, 2012 at 2:53 PM, David A. Marlindmarlin@redhat.com wrote:
Jon Masters wrote:
On 07/30/2012 03:13 AM, Peter Robinson wrote:
On Mon, Jul 30, 2012 at 5:23 AM, Jon Mastersjonathan@jonmasters.org wrote:
Folks,
In general, we probably want to look at the value of host system type being picked up for ARMv5 builds, especially on ARMv7 builder systems. Here's an example output from running an OpenMPI build on Fedora 18 using the current Koji builder setup, note the "armv7l" target:
--- begin quote --- checking build system type... armv7l-unknown-linux-gnueabi checking host system type... armv7l-unknown-linux-gnueabi checking target system type... armv7l-unknown-linux-gnueabi --- end quote ---
I believe that this is incorrect, at least, this is in question. The compiler options (set elsewhere) are correct from an ABI point of view, and the output will be a soft float ABI target, but it's not the right architecture revision target. It will matter in a few cases. For example when a package is choosing inline assembly or other specifics that differ between ARMv5 and ARMv7. Mostly, we've been lucky in that the differences are small, but I suspect hidden breakage is lurking.
In this specific example, OpenMPI should move to the new GCC atomics stuff in due course, but they have a giant mess called "asmlib" that provides their own custom atomic functions (what could go wrong?) for historical reasons. The macros used to build that are enough to make you gouge your eyes out, but once you figure it out, it's obvious that they do already have ARMv5 assembly code that should work, if it thinks it's building for an armv5l system. And it's faster to just pick that up than reworking a lot of not just code, but also other arches and build macros, and other stuff unique to the OpenMPI atomics setup.
Let's ponder how we're going to fix it. I could be wrong, but I'd think we want to ensure that configure is picking up armv5l-redhat-linux-gnueabi as the host type on armv5tel builds. It should do this irrespective of the actual host architecture of the builder. I tried just force overriding it in a test build with an "%{ifarch} armv5tel" but that wasn't picked up, so I missed something, but in general that's not the right approach anyway. We want something at the r-r-c level.
Comments? Dennis? Peter?
It should always take the details that the build system is telling it and not the underlying platform without exception. The same goes with features like NEON (and MMX/SSE on x86). I've fixed a number of these before.
Good. Then you agree it should be thinking armv5l-redhat-linux-gnueabi there and this is a bug we need to fix.
Just for clarification, are you saying that something is not being set correctly (in rpmmacros, etc.) in the v5 mock chroot when v5 builds are being run on a v7 host?
No, some projects aren't following the cflags etc as specified in rpmmacros.
There is quite a lot of that going on. Not only that, but %__cc is frequently ignored, too, so it isn't as easy as it should be to rebuild some packages using a different compiler.
Ok, so this is a 'per package' type fix, and not something we can fix in the build environment.
Thank you Peter and Gordan for the clarification.
d.marlin ==========
Gordan _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
On 07/30/2012 06:10 PM, David Marlin wrote:
Gordan Bobic wrote:
On 07/30/2012 03:05 PM, Peter Robinson wrote:
On Mon, Jul 30, 2012 at 2:53 PM, David A. Marlindmarlin@redhat.com wrote:
Jon Masters wrote:
On 07/30/2012 03:13 AM, Peter Robinson wrote:
On Mon, Jul 30, 2012 at 5:23 AM, Jon Mastersjonathan@jonmasters.org wrote:
> > Folks, > > In general, we probably want to look at the value of host system > type > being picked up for ARMv5 builds, especially on ARMv7 builder > systems. > Here's an example output from running an OpenMPI build on Fedora 18 > using the current Koji builder setup, note the "armv7l" target: > > --- begin quote --- > checking build system type... armv7l-unknown-linux-gnueabi > checking host system type... armv7l-unknown-linux-gnueabi > checking target system type... armv7l-unknown-linux-gnueabi > --- end quote --- > > I believe that this is incorrect, at least, this is in question. The > compiler options (set elsewhere) are correct from an ABI point of > view, > and the output will be a soft float ABI target, but it's not the > right > architecture revision target. It will matter in a few cases. For > example > when a package is choosing inline assembly or other specifics that > differ between ARMv5 and ARMv7. Mostly, we've been lucky in that the > differences are small, but I suspect hidden breakage is lurking. > > In this specific example, OpenMPI should move to the new GCC atomics > stuff in due course, but they have a giant mess called "asmlib" that > provides their own custom atomic functions (what could go wrong?) > for > historical reasons. The macros used to build that are enough to > make you > gouge your eyes out, but once you figure it out, it's obvious > that they > do already have ARMv5 assembly code that should work, if it > thinks it's > building for an armv5l system. And it's faster to just pick that > up than > reworking a lot of not just code, but also other arches and build > macros, and other stuff unique to the OpenMPI atomics setup. > > Let's ponder how we're going to fix it. I could be wrong, but I'd > think > we want to ensure that configure is picking up > armv5l-redhat-linux-gnueabi as the host type on armv5tel builds. It > should do this irrespective of the actual host architecture of the > builder. I tried just force overriding it in a test build with an > "%{ifarch} armv5tel" but that wasn't picked up, so I missed > something, > but in general that's not the right approach anyway. We want > something > at the r-r-c level. > > Comments? Dennis? Peter? >
It should always take the details that the build system is telling it and not the underlying platform without exception. The same goes with features like NEON (and MMX/SSE on x86). I've fixed a number of these before.
Good. Then you agree it should be thinking armv5l-redhat-linux-gnueabi there and this is a bug we need to fix.
Just for clarification, are you saying that something is not being set correctly (in rpmmacros, etc.) in the v5 mock chroot when v5 builds are being run on a v7 host?
No, some projects aren't following the cflags etc as specified in rpmmacros.
There is quite a lot of that going on. Not only that, but %__cc is frequently ignored, too, so it isn't as easy as it should be to rebuild some packages using a different compiler.
Ok, so this is a 'per package' type fix, and not something we can fix in the build environment.
Thank you Peter and Gordan for the clarification.
I have some bugzilla tickets filed for a few packages where I've found this happening, but it is by no means exhaustive. I suggest you file a ticket for each package you find that isn't packaged correctly to obey the rpm macro conventions.
Gordan
-
d.marlin -
Gordan Bobic -
Jon Masters -
Peter Robinson