On Thu, Mar 27, 2014 at 9:05 AM, Erik Joelsson <erik.joels...@oracle.com> wrote: > There are unfortunately legal complications surrounding updating these > files. We can initiate the approval dance, but it will take time to go > through (weeks at least). This is the reason Magnus added the wrapper around > config.guess, so that we could get functional updates to it faster. >
OK, but as I wrote, config.guess currently only maps some recognized systems to different names. This case is different because for ppc64le the output of 'autoconf-config.guess' would be an emtpy string and a quite big error message on stderr. Do you really want that we make Linux/ppc64le the default fallback in config.guess if 'autoconf-config.guess' can not detect a system? Or should we exceptionally just patch 'autoconf-config.guess' if we know that we will update it anyway with a new version within a few weeks? I think I'd prefer this solution, because this is just one change which will be automatically removed once we integrate the new 'autoconf-config.guess' version. If we just hack 'config.guess' we would have to manually take that change back once we get the new 'autoconf-config.guess' version. In any case I'd kindly ask you to start the 'legal approval dance' :) Regards, Volker > I agree that long term, updating these files from the source is the correct > action. > > /Erik > > > On 2014-03-26 23:47, Alexander Smundak wrote: >> >> On Wed, Mar 26, 2014 at 2:21 AM, Volker Simonis >> <volker.simo...@gmail.com> wrote: >>> >>> So I'd suggest we just check in this new version for the current >>> common/autoconf/build-aux/config.guess. >> >> I agree. >> >> Magnus, would you like me to do this? > >
