Outdated config.guess and config.sub in freexl 2.0

[Even Rouault]

Hi,

I've just stumbled upon a cross compilation issue of freexl for arm64
where it appears that the config.guess and config.sub file in the
tarball are from 2009

The following gets an updated version that solves the issue:

wget
"http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD"
-O config.guess
wget
"http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD"
-O config.sub

Even

--
http://www.spatialys.com
My software is free, but my time generally not.

[a.fu...@lqt.it]

On Sat, 16 Sep 2023 15:14:22 +0200, Even Rouault wrote:
> Hi,
>
> I've just stumbled upon a cross compilation issue of freexl for arm64
> where it appears that the config.guess and config.sub file in the
> tarball are from 2009
>
> The following gets an updated version that solves the issue:
>
> wget
>
> "http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD"
> -O config.guess
> wget
>
> "http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD"
> -O config.sub
>

Hi Even,

Thank a lot for bringing my attention to a problem I had never
considered before.

Today I had some free time to study, and so I discovered several
interesting things that I think are worth to be shared.

1. both config.guess and config.sub are simply two shell scripts
that are required during the project configuration.
their task is to identify the system architecture and they
are an integral part of Automake.

2. they naturally evolve over time as new architectures appear
on the market.

3. the problem arises from the fact that these two scripts are
never automatically updated, they always remain the ones
installed the first time.
for a project with a long life behind it (like FreeXL) they
end up becoming decidedly obsolete.

ok, now we know that it is essential to regularly update these
two scripts to keep them up to date.
the problem is understanding which is the simplest and most
robust solution.

hypothesis #1)
the one you suggest.
the project maintainer must occasionally remember to manually
download the latest version from the GNU Automake WEB site.
the new files will then be copied over the previous ones.

hypothesis #2)
there is a simpler and more direct solution; just using
automake itself:

automake --add-missing --copy --force-missing

this ensures that Automake automatically updates both
config.guess and config.sub

conclusion: instead of simply running autoreconf every
time you switch to a new version of the project, you
just need to get into the habit of running automake
at the same time.

# automake --add-missing --copy --force-missing
# autoreconf

bye Sandro

[Even Rouault]

Sandro,

> hypothesis #2)
> there is a simpler and more direct solution; just using
> automake itself:
>
> automake --add-missing --copy --force-missing
>
> this ensures that Automake automatically updates both
> config.guess and config.sub

It would be nice that this was done before creating a release tarball,
so that ./configure works out of the box

And/or provide a autogen.sh script like
https://gitlab.com/libtiff/libtiff/-/blob/master/autogen.sh?ref_type=heads
to make regeneration of autoconf&automake files easier

[a.fu...@lqt.it]

On Mon, 25 Sep 2023 18:11:12 +0200, Even Rouault wrote:
> Sandro,
>> hypothesis #2)
>> there is a simpler and more direct solution; just using
>> automake itself:
>>
>> automake --add-missing --copy --force-missing
>>
>> this ensures that Automake automatically updates both
>> config.guess and config.sub
>
> It would be nice that this was done before creating a release
> tarball, so that ./configure works out of the box
>

for sure: all the next releases of the spatialite family
from today onwards will follow this criterion

bye Sandro