Re: undefined reference to `__alloca'

[Paul Smith]

On Sat, 2017-11-18 at 21:19 +0000, Earnestly wrote:
> [I've also found that `make update' is apparently subject to `make -j4'
> race conditions resulting in errors like:
> 
>     wget: unable to resolve host address ‘cvs.savannah.gnu.org’
>     make: *** [Makefile;1584: get-doc/fdl.texi] Error 4

I don't see any possible way that using -j could cause such an
error...?  Unless it's not valid to run wget multiple times in the same
directory (for different files) somehow.  Very bizarre.

> I'm a little upset that the build system is calling out to remote
> resources at all but it does seem to only be during preamble...]

"make update" is designed to be run by maintainers, who have a complete
system installation such as autoconf, automake, gettext, etc.  As part
of that process it will download the latest translation files, GNU
standards documents, etc.

I don't believe in checking in either generated (configure, etc.) or
remotely maintained files (translations, etc.) to GNU make's source
control system.  Other packages may have different attitudes on this,
but that's how I do it.

A distribution tarball, such as you'd download from the gnu.org sites,
will of course come with all the content you need and will not require
any remote resources; indeed all you need is a C compiler and a shell
(you don't even need a version of make, if you don't have one).

> Nevertheless, I'm still getting the same issues:

In this try, as well, I can see that you're using the version of glob
that comes with make (by linking glob/libglob.a).  That's the part I'm
trying to understand.  If your system libc is glibc, then the configure
script should detect this and the build should not compile the local
glob implementation at all.

So, the first question is why is configure not detecting that your
system library supports GNU libc glob?

> Does it mean anything if my _GNU_GLOB_INTERFACE_VERSION is '2'?

Ah!  Yes, that's the problem.  If you examine configure.ac you'll see
this test there:

#define GLOB_INTERFACE_VERSION 1
#if !defined _LIBC && defined __GNU_LIBRARY__ && __GNU_LIBRARY__ > 1
# include <gnu-versions.h>
# if _GNU_GLOB_INTERFACE_VERSION == GLOB_INTERFACE_VERSION

Obviously this will never be true.

One way to fix this would be to change the second #if line above to be:

# if _GNU_GLOB_INTERFACE_VERSION >= GLOB_INTERFACE_VERSION

and see if that works.

Is there anywhere documented what the difference is between version 1
and version 2?  Is it just this symlink change?  I'm not sure if the
above change is absolutely correct since it means we'll always accept
the latest libc glob interface, which seems to defeat the purpose of
having a version in the first place.