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(a)danny.cz>
To: secondary(a)lists.fedoraproject.org,
Date: 10/23/2013 04:25 PM
Subject: Re: ppc64le architecture
Sent by: secondary-bounces(a)lists.fedoraproject.org
On Wed, 23 Oct 2013 16:09:36 -0500
Brent Baude <baude(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/secondary