Re: Software Management call for RFEs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Friday 24 May 2013 13:41:41 Kevin Fenzi wrote:
> On Fri, 24 May 2013 15:15:30 -0400 Rahul Sundaram <metherid@xxxxxxxxx> wrote:
> > Not really.  We are focusing only on the x86_64/x86 case and ignoring
> > the broader problem which Debian has tackled.  Jumping to the
> > conclusion that because you had some multi-lib issues in Ubuntu, we
> > are doing better is premature.  Considering the fact that ARM is
> > going to become primary architecture for Fedora, we really need to
> > solve the broader problem one way or the other.
> 
> It was my understanding that arm is not going to do any multilib.
> 
> aarch64 cannot run other stuff, so you cannot run armv7 or whatever on
> a aarch64 box, it's just completely different.

I think you missed the whole point of Debian's multi-arch -- instead of
special handling for "sister" architectures (e.g: x86/x86_64), or proving
there aren't (e.g: aarch64/armv7) -- it creates a symmetric world.

The *huge* benefit of multi-arch is to people that *cross-compile*.

Example (without multi-arch -- like in Fedora today):
 * You cross compile libfoo (e.g: on x86 you compile for arm)

 * You can install the resulting libfoo rpm on the arm device

 * Now you want to cross-compile an application that use this
   library, so you need to install libfoo-devel on your workstation -- BUT!

 * The libfoo-devel you have is for arm (not installable on your x86)

 * Furthermore, even if you manage to install it, it will put the files
   in the wrong location (/usr/lib) and not where the cross-compiler
   will search them (e.g: /usr/arm-unknown-linux/.../lib)

 * So you have to extract the arm libraries from libfoo-devel and
   manually put them into the correct location.
   (btw: Debian embedded developers has automatic tool to "convert"
    these packages -- dpkg-cross).

 * If you maintain an embedded arm based product, multiply this
   scenario by the number of libraries your developers maintain and
   their daily commits.... does it scale? How does it affect your
   whole build environment, continuous integration tools, etc.

Same example (but with multi-arch):
 * Every compiler/linker/dynamic-linker for every architecture search first
   in /usr/lib/<arch> and falls back to /usr/lib (to cover legacy libraries
   which haven't  been migrated yet).

 * Under this scheme, *both* the native and cross toolchains search for
    libraries in the same location -- /usr/lib/<arch>

 * With careful package design, there should be no problem installing
    the arm based libfoo-devel on our x86 system (no conflicting files).

 * Please note, that it doesn't matter if libfoo-devel was built on an arm
   machine (native compilation) or on x86 with a cross-compiler -- in both
   cases the resulting library files would be on /usr/lib/arm-unknown-linux

 * This means cross-toolchains becomes first class citizens.

Bye,

-- 
Oron Peled                                 Voice: +972-4-8228492
oron@xxxxxxxxxxxx                  http://users.actcom.co.il/~oron
Gratis is nice, Libre is an inalienable right.

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux