Re: Canonical copy of config.guess/config.sub

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

 



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El Fri, 25 Oct 2013 13:59:37 +0200
Phil Knirsch <pknirsch@xxxxxxxxxx> escribió:
> On 10/25/2013 12:07 PM, Marcin Juszkiewicz wrote:
> > W dniu 22.10.2013 17:26, Ralf Corsepius pisze:
> >
> >> Also, automake-based projects receive the versions bundled with
> >> automake, when running automake rsp. autoreconf.
> >
> > *IF* they run autoreconf. I am working on getting software built for
> > AArch64 for over a year now. Main issue is all those projects which
> > ship old, long-time-deprecated copies of config.{guess,sub} files.
> > Sure, they are new enough for most of architectures and operating
> > systems now in use but not for new ones.
> >
> > And %configure macro updates them from /usr/lib/rpm/redhat/ anyway
> > which covers most of situations but for some we need to copy those
> > files by hand because authors think that they are smart and do lot
> > of crazy tricks like:
> >
> > 1. ln -sf ../configure . (so %configure tries "." instead of "..")
> > 2. shipping multiple copies of gnu-config files in any random
> > versions 3. shipping both config.{guess,sub} and
> > configure.{guess,sub} with use of the second ones
> >
> > And such list can go on and on...
> >
> 
> Brent Baude from IBM has proposed a bit of a different approach a few 
> days ago on the secondary mailing list for their work and bring up of 
> Power 64bit Little endian:
> 
> https://lists.fedoraproject.org/pipermail/secondary/2013-October/002628.html
> 
> A very brief summary of what they did was that, instead of tackling
> the problem on the autoFOO and libtool side they modified the linker
> itself to always claim to be able to generate shared libraries, even
> if the arch was actually wrong. In a confined and controlled
> environment where you control the linker and the linker actually
> really KNOWS it can generate correct shared libraries for that arch
> this works just as well.
> 
> The huge benefit here is that you only need to modify the linker, 
> everything else afterwards simply falls into place and just
> works(tm). They have already tried this with a large number of
> packages and haven't seen a single issue with that approach.
> 
> Obviously you'd want this as a temporary solution until either
> Florian's approach would get adopted and shared by upstream libtool
> or the majority of packages have gotten an upstream update that
> picked up the latest config.sub and config.guess to work properly on
> your new architecture.

you still need to patch config.guess and config.sub because when you
get to koji it will say the arch is ppc64le and configure will puke
because the arch is unknown.

Dennis

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJScrZ9AAoJEH7ltONmPFDRaygQAL8QB7JQPVJ/KqFG6q7iKkby
3XPglXnhkz+6F5dry3pcb1RJcB468r7AUiUPASp/WyOwAbunn3ZsphDVnzeGGzg0
8zNbXm6Ot2QYKCN0XipdGOF++5qK3vp+81zROUNwe+rKuMClauHjEKwvYHZeRaO8
/EYR15ON6QhyDxpAt8ImIqfeuTtEFhcvgur7sUxHItaotejiF0neYgsOToVm9Dvx
mlAniX2LIwAHIQElq750m+ac4lNqudTMD1WMOAupj+sO2pOdfAWvsLZ8eItvYI0y
XcD5Nn0Rjij+Qk4SG4Rvhon18flATGAJchh48k/9rIyGQ3dUgmxlOGPSeGQy/IOD
4IGnXDa1BhCMPMaQ346gfjHUzo1xkLyR8vvvV11ar7WkKF9mPMxBQXThOWG3FGHg
HChYZ7iKHe9dH1fHd32AHIziRw/OgXJKKAwaTb5Fa9yl8lzMEFKAYKZhUTTOB0WM
VeGs9LlAVTYKHv66XIMKOnjZoi+3Q7kuJJQCrv4pVU+OviYbd+kw5dJEmfUrK54W
+geiluUJfvlH1twe6k53ZmvqqtW14+7vuu4dhS3fsYpKymBez8y+FBDc0l91eWP6
FPBdBHakiqnJbkQLpB9N9F4tYPWWfBqMziNXuXM0xsabYUEjhQWL8Hxyia73Smdy
B4Cvf+YJS41JmEtXBsML
=Xi7r
-----END PGP SIGNATURE-----
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[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