On Mon, 23 Apr 2012 20:20:27 +0200
Adrian Schröter <[email protected]> wrote:
>
> Hi,
>
> I would like to propose a change in the rpm provides/requires
> handling of libs and binaries.
>
> Right now, we use on arm the architecture to distinguish between hard
> and soft fp abi.
> This results to the fact that armv7l is complete incompatible to
> armv7hl due to the rpm architecture compatibility list (is this true
> everywhere?)
at least for Fedora its on purpose we do not want to support multilibed
32 bit arm systems.
> This is IMHO technical wrong. For example an rpm with a static build
> soft-fp binary should be installable on a hard-fp system. The kernel
> and the hardware does support it and it would just run.
> But furthermore this will make it also impossible later to have mixed
> systems.
While in theory you can run hfp and sfp on the same system at the same
time, it really does not make a lot of sense to do so. there is not a
whole lot of proprietary software for arm, what is there should be
easily rebuildable for hfp. the only use case i have heard that
somewhat makes sense is video drivers. Vedors should be rebuilding
those for hfp.
>
> What I like to do on openSUSE-ARM is to go the same way as i686 vs.
> x86_64 world did go. Declare i686 backward compatible from x86_64,
> but to extent the provides and requires with an extension. So a hf
> binary will still require a hf lib.
>
> A patch for rpm which should do this is attached, but I have not
> tested it, I have to admit. The reason is that want to discuss it
> here first, because this has a big impact: It would suddenly make the
> old armv7hl rpms not compatible anymore with the new ones.
>
> So, I would like to here if you share my POV here in general. And
> secondly, if you see a chance at all to do this switch.
>
> I promise to take care to push such a patch to rpm upstream, if you
> want it.
>
> thanks
> adrian
>
> PS: I have not evaluated how the NEON VFP world fits in here.
>
for fedora we have armv5tel armv6l and armv7l for sfp and armv7hl and
armv7hnl for hfp. armv7hnl is for neon optimised builds.
I have to be honest that patch is a horrible hack and completely wrong.
marking hfp libs as 64 bit is not at all correct. we soon will have real
64 bit arm, the way to truely support what your proposing would be to
make gcc and glibc multilibed and use something like /usr/libhfp/ for
%{_libdir} on hfp certainly not /usr/lib64/. A big issue with what your
done comes to supporting cleanly arm64 what the rpm arch will be
depends on "uname -m" but i fully expect that libs will go
into /usr/lib64 for consistency with other 64 bit arches however at
least in fedora we dont plan to support 32 bit hfp and 64 bit on the
same system, but a really good time to have brought this up would have
been a few weeks ago, when we were discussing moving the hfp linker and
made things multilibed to support your use cases. What are you use
cases? other than it being you can do it?
Dennis
_______________________________________________
cross-distro mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/cross-distro
