ppc64le architecture

[Phil Knirsch]

On 10/23/2013 11:09 PM, Brent Baude wrote:
> Greetings fellow secondary arch folks,
>
> As some of you might know, we are working to introduce a new
> architecture called ppc64le into Fedora. It's just as it sounds, ppc64
> (64bit only) but little endian. We've been emulating the Fedora process
> as close as possible internally here and have quite a few packages
> built, including using things like mock and koji.
>
> As with introducing any new architecture, one of the issues we are
> seeing is that current packages lack the libtool (config.guess|sub,m4)
> magic to recognize the architecture.  While rpmbuild and mock do
> properly influence build and targets, the one area we still a high rate
> of failure with is when configure asks the linker if it supports shared
> libs.  In our case, it actually asks the linker with the wrong architecture.
>
> In an ideal situation, libtool would release a new version with the
> ppc64le content (which is already upstream with them) and ALL upstream
> maintainers would immediately add the new content and drop new releases.
>   That's ideal but not realistic.
>
> I also would prefer to NOT update every Fedora package/.spec with a
> patch to fix this and would prefer to have this be the rare exception
> rather than the rule.
>
> So in the interest of beginning work in Fedora and not making a mess of
> things, I'd like to propose another alternative (and solicit more ideas
> as well).  In extending the case where configure “asks” the linker if it
> supports shared libraries, it actually will pass an incorrect
> architecture.   Using lcms2's configure as an example:
>
> checking whether the gcc -std=gnu99 linker (/bin/ld -m elf64ppc)
> supports shared libraries... no
>
>
> In our internal development here, we've patched the linker to always
> respond as if it was asked about the ppc64le architecture.  This
> function is enabled as an environment variable (LD_FORCE_LE=1).  We've
> been using this for several months and I have yet to encounter an
> instance where something bad happens.
>
> So I'd like to propose that for initial Fedora ppc64le development, we
> enable this patch for the linker, at least for the first release.
>   Meanwhile, we can identify and manage the list of packages that need
> updated libtool information on the side.  We could then identify a good
> cutover point and disable the linker patch in a future release.
>
> If this could be helpful for other new arches like aarch64, we could
> share the this patch as well.
>
> I believe the Fedora PPC64 team is supportive of this (at least for the
> ppc64le arch) but we wanted to just solicit broader input.
>
> Feedback appreciated,
>
> Brent
>

Intriguing idea and certainly a very clever way to avoid having to 
either wait 1-2 years until a libtool upstream release has happened and 
the majority of packages have picked that up in newer releases or to go 
in into Fedora and fix iirc about 2000-3000 package manually that don't 
use %configure.

I think this could be very interesting for aarch64 as well as you 
mentioned as i can imagine they fight the same battle there, too.

Especially as it's easy to turn on and off we could set a certain 
criteria for turning it off in the future when e.g. only a small number 
of packages would still fail to build (less than 100 maybe?) and at 
which time we'd turn it off, probably sometime around the branching of a 
new release.

I'd be in favor of giving it a try and see how it goes. Especially as we 
don't have to do an official release in our first cycle for a bringup 
this seems to be the solution with the least amount of effort for the 
biggest benefit.

Thanks for bringing this up Brent!

Regards, Phil

-- 
Philipp Knirsch              | Tel.:  +49-711-96437-470
Manager Core Services        | Fax.:  +49-711-96437-111
Red Hat GmbH                 | Email: Phil Knirsch <pknirsch at redhat.com>
Wankelstrasse 5              | Web:   http://www.redhat.com/
D-70563 Stuttgart, Germany