ppc64le architecture

[Brent Baude]

Hi Dan,

Indeed I do observe where that occurs but, as you note, it does depend on
the .specs being a certain way.  So in those cases, we don't need a
work-around.  But there are still many cases where we do; hence the
proposal.

Brent J. Baude
Linux Technology Center
3605 Hwy 52N
Rochester, MN  55901

http://www.ibm.com/linux/ltc/
507.253-0708




From:	Dan Horák <dan at danny.cz>
To:	secondary at lists.fedoraproject.org,
Date:	10/23/2013 04:25 PM
Subject:	Re: ppc64le architecture
Sent by:	secondary-bounces at lists.fedoraproject.org



On Wed, 23 Oct 2013 16:09:36 -0500
Brent Baude <baude at us.ibm.com> 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.

Do you need full updated libtool or having recent enough
config.guess/config.sub will be sufficient? Currently redhat-rpm-config
provides them and they are used to replace the project's upstream ones
when the spec file calls the %configure macro. This was done in support
for aarch64 instead of requiring running autoreconf or patching the
autotools files.


		 		 Dan


> 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
>
>
> Brent J. Baude
> Linux Technology Center
> 3605 Hwy 52N
> Rochester, MN  55901
>
> http://www.ibm.com/linux/ltc/
> 507.253-0708
_______________________________________________
secondary mailing list
secondary at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/secondary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/secondary/attachments/20131023/3eaa35ee/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/secondary/attachments/20131023/3eaa35ee/attachment-0001.gif>