Re: [gentoo-user] Make failed to compile: symbol __alloca not found...

[David Haller <gentoo@dhaller.de>]

Hello,

On Mon, 11 Dec 2017, tuxic@posteo.de wrote:
>On 12/11 05:13, David Haller wrote:
>> Hello,
>> 
>> On Sun, 10 Dec 2017, tuxic@posteo.de wrote:
>> >x86_64-pc-linux-gnu-gcc -DLOCALEDIR=\"/usr/share/locale\" -DLIBDIR=\"/usr/lib64\" -DINCLUDEDIR=\"/usr/include\" -DHAVE_CONFIG_H -I.  -I./glob    -march=native -O2 -pipe -c -o remote-stub.o remote-stub.c
>> >x86_64-pc-linux-gnu-gcc  -march=native -O2 -pipe -Wl,--export-dynamic -Wl,-O1 -Wl,--as-needed -o make ar.o arscan.o commands.o default.o dir.o expand.o file.o function.o getopt.o getopt1.o guile.o implicit.o job.o load.o loadapi.o main.o misc.o posixos.o output.o read.o remake.o rule.o signame.o strcache.o variable.o version.o vpath.o hash.o remote-stub.o glob/libglob.a   -ldl 
>> >glob/libglob.a(glob.o): In function `glob_in_dir':
>> >glob.c:(.text+0x2ed): undefined reference to `__alloca'
>> 
>> IIRC, that's a missing #define somewhere. Or a #define where it
>> shouldn't. But the thing is: on my system, make doesn't build libglob
>> at all because it finds the globbing stuff in glibc. And make has its
>> own alloca.c.
>> 
>> So, please show the output of the configure-part of the ebuild and
>> what's the output of:
>> 
>> $ grep _GNU_GLOB_INTERFACE_VERSION /usr/include/gnu-versions.h
>
>Here it comes:
[..]
>./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --libdir=/usr/lib64 --program-prefix=g --without-guile --enable-nls
>configure: loading site script /usr/share/config.site
[..]
>checking if system libc has GNU glob... no
[..]

That figures.

>/root>grep _GNU_GLOB_INTERFACE_VERSION /usr/include/gnu-versions.h
>#define _GNU_GLOB_INTERFACE_VERSION	2 /* vs posix/glob.c */

You seem to be using glibc-2.26. Question is, is that new
GLOB_INTERFACE backwards compatible or not? If it is, you could just
mangle the configure, so that "GNU glob" is considered found, a patch
via the e{apply,patch}_user of configure{ac,} should work.

>Any ideas?

"downgrade" to the stable glibc-2.25 ... ;)

Or dig into why the following happens, i.e. why is __alloca not
defined in glob_in_dir() ...

>> Ah, yess:
>> 
>> ==== make-4.2.1/glob/glob.c:211 ff. ====
>> #if !defined __alloca && !defined __GNU_LIBRARY__
>> [..]
>> #  define alloca(n)     __builtin_alloca (n)
>> [..]
>> # define __alloca       alloca
>> [.. down to line 1217 ..]
>> static int
>> glob_in_dir( ..
>> [..]
>> char *fullname = (char *) __alloca(...             /* line 1256 */
>> ====
>> 
>> Somewhere between that and line 1256 of glob.c, where __alloca is
>> first used in that function you managed to undef __alloca...
>> 
>> You must have done something weird ...

If I have the time, I'll try merging the glibc-2.26 and see what
happens. Usually, debugging preprocessor stuff involves (for me) a lot
of liberally sprinkling of in this case e.g.

#ifndef __alloca
#warning notdef __alloca
#endif

or somesuch throughout the relevant code, occasionally verified against the
preprocessed code (gcc -save-temps is nice ;) But it tends to be
tedious if you don't know the code (and circumstances) well already.

HTH,
-dnh

PS: I've not synced portage for quite some days, I wanted to get done
    with the 'emerge -e @world' before adding updates and whatnot into
    the mess... So dunno if glibc-2.26 is stable already.

-- 
The problem with people whose minds are in the gutter is that they keep
blocking my periscope.                                  [Peter Gutman]