Re: Improving the state of ARM

[Adam Jackson]

On Wed, 2014-06-11 at 08:48 +0100, Richard W.M. Jones wrote:
> While I certainly think clang should be fixed on ARM, it's important
> to note:
> 
>  * clang doesn't work on i686/x86_64 either *[1]

Just a reminder, while the llvm package is nominally mine, my interest
in it extends exactly as far as llvm, and even that is grudging.  That
clang is built from the same srpm is only because llvm upstream don't
give you any other way to build it, afaik (and if this changes I will
happily fix the packaging to reflect it).

I am happy to have comaintainers.  Honestly I'd mark it cvsextras+ if
that was still a thing we had.

> In both cases you have to hack the standard RPM flags, otherwise
> compilation fails.
> 
> Therefore all arguments about ARM being dropped as a primary
> architecture for not supporting clang, apply equally to x86.

Except that on x86, if you hack out -fstack-protector-strong, floating
point code will compile and link, where on arm it will not even get as
far as compiling.

- ajax

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Improving the state of ARM

[Richard W.M. Jones]

While I certainly think clang should be fixed on ARM, it's important
to note:

 * clang doesn't work on i686/x86_64 either *[1]

In both cases you have to hack the standard RPM flags, otherwise
compilation fails.

Therefore all arguments about ARM being dropped as a primary
architecture for not supporting clang, apply equally to x86.

For the supported compilers, ARM is equivalent to x86.

Rich.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1099282#c2

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Improving the state of ARM

[Matthew Garrett]

On Tue, Jun 10, 2014 at 07:05:56PM +0100, Richard W.M. Jones wrote:

> In this case however I don't think much productive came from this
> discussion we had about hfsplus-tools.  Obviously no one wants
> hfsplus-tools and/or clang enough on Fedora/ARM that they are prepared
> to fix it.  So I think we should just drop it on ARM, and let anyone
> who wants it, fix it later (or reenable %{arm} if clang gets fixed).

Let me try this again. The aim is for Fedora to provide an experience 
that's consistent across primary architectures to the extent that is 
reasonably possible. If people don't care about that, we have a problem. 
The nature of that problem depends on who is failing to do the caring:

1) If the ARM maintainers don't care about ARM being equivalent to x86, 
that's a serious problem that is (with luck) easily fixable. On the 
other hand, if they care but don't have sufficient resources to fix 
things, that's a smaller problem but probably less easily fixed, 
because:

2) If individual package maintainers don't care about ARM, there's 
really not a lot we can do. They weren't involved in the decision to 
make ARM primary. They probably don't plan on installing Fedora on any 
ARM systems, so they gain no personal benefit from fixing it. What kind 
of incentives can we provide? Threaten to drop their packages? That 
would provide consistency, but it ends up being a rather limiting 
strategy.

Honestly the most practical solution would seem to be a concerted effort 
from the ARM team to fix these up - the assumption that individual 
package maintainers will take care of things isn't realistic. But given 
that they're busy getting arm64 into a good state, I don't know how 
reasonable that is given the available resources.

I think there's a real problem if ARM continues to languish behind x86's 
feature set, and I think it's realistic to ask whether that problem is 
sufficiently serious for demoting it. But that's clearly not the most 
desirable outcome, and so I'd really prefer us to figure out a way to 
fix things. Improving code portability benefits us, our users and the 
ecosystem as a whole.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct