Failed compile on Fedora 28, x86_64

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Failed compile on Fedora 28, x86_64

Jeffrey Walton-3
I'm working on Fedora 28, x86_64 (fully patched). I'm building 4.2.1
from the tarball.

I *thought* we are supposed to avoid alloca in 2018. I guess this is
another reason why.

----------------------------------

...
gcc -DLOCALEDIR=\"/usr/local/share/locale\"
-DLIBDIR=\"/usr/local/lib64\" -DINCLUDEDIR=\"/usr/local/include\"
-DHAVE_CONFIG_H -I.  -I./glob  -I/usr/local/include -DNDEBUG  -g2 -O2
-m64 -march=native -fPIC -MT remote-stub.o -MD -MP -MF
.deps/remote-stub.Tpo -c -o remote-stub.o remote-stub.c
mv -f .deps/hash.Tpo .deps/hash.Po
mv -f .deps/remote-stub.Tpo .deps/remote-stub.Po
mv -f .deps/variable.Tpo .deps/variable.Po
mv -f .deps/read.Tpo .deps/read.Po
gcc  -g2 -O2 -m64 -march=native -fPIC -Wl,--export-dynamic
-L/usr/local/lib64 -m64 -Wl,-R,/usr/local/lib64 -Wl,--enable-new-dtags
-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 -lpthread
glob/libglob.a(glob.o): In function `glob_in_dir':
/home/test/make-4.2.1/glob/glob.c:1367: undefined reference to `__alloca'
/home/test/make-4.2.1/glob/glob.c:1342: undefined reference to `__alloca'
/home/test/make-4.2.1/glob/glob.c:1256: undefined reference to `__alloca'
/home/test/make-4.2.1/glob/glob.c:1283: undefined reference to `__alloca'
glob/libglob.a(glob.o): In function `glob':
/home/test/make-4.2.1/glob/glob.c:581: undefined reference to `__alloca'
glob/libglob.a(glob.o):/home/test/make-4.2.1/glob/glob.c:732: more
undefined references to `__alloca' follow
collect2: error: ld returned 1 exit status
gmake[2]: *** [Makefile:656: make] Error 1
gmake[2]: Leaving directory '/home/test/make-4.2.1'
gmake[1]: *** [Makefile:798: all-recursive] Error 1
gmake[1]: Leaving directory '/home/test/make-4.2.1'
gmake: *** [Makefile:534: all] Error 2
Failed to build Make

----------------------------------

Here's from the Fedora man pages. It should provide the header and
library information if a Fedora box is not handy.

ALLOCA(3)                  Linux Programmer's Manual                 ALLOCA(3)

NAME
       alloca - allocate memory that is automatically freed

SYNOPSIS
       #include <alloca.h>

       void *alloca(size_t size);

DESCRIPTION
       The  alloca() function allocates size bytes of space in the stack frame
       of the caller.  This temporary space is automatically  freed  when  the
       function that called alloca() returns to its caller.

RETURN VALUE
       The  alloca()  function returns a pointer to the beginning of the allo‐
       cated space.  If the allocation causes stack overflow, program behavior
       is undefined.

ATTRIBUTES
       For   an   explanation   of   the  terms  used  in  this  section,  see
       attributes(7).

       ┌──────────┬───────────────┬─────────┐
       │Interface │ Attribute     │ Value   │
       ├──────────┼───────────────┼─────────┤
       │alloca()  │ Thread safety │ MT-Safe │
       └──────────┴───────────────┴─────────┘
CONFORMING TO
       This function is not in POSIX.1.

       There is evidence that the alloca()  function  appeared  in  32V,  PWB,
       PWB.2,  3BSD,  and  4BSD.  There is a man page for it in 4.3BSD.  Linux
       uses the GNU version.

NOTES
       The alloca() function is machine- and compiler-dependent.  For  certain
       applications,  its  use  can  improve efficiency compared to the use of
       malloc(3) plus free(3).  In certain cases, it can also simplify  memory
       deallocation  in  applications  that  use  longjmp(3) or siglongjmp(3).
       Otherwise, its use is discouraged.

       Because the space allocated by alloca() is allocated within  the  stack
       frame,  that  space  is  automatically  freed if the function return is
       jumped over by a call to longjmp(3) or siglongjmp(3).

       Do not attempt to free(3) space allocated by alloca()!

   Notes on the GNU version
       Normally, gcc(1) translates calls to alloca() with inlined code.   This
       is  not done when either the -ansi, -std=c89, -std=c99, or the -std=c11
       option is given and the header <alloca.h> is not included.   Otherwise,
       (without  an  -ansi  or -std=c* option) the glibc version of <stdlib.h>
       includes <alloca.h> and that contains the lines:

           #ifdef  __GNUC__
           #define alloca(size)   __builtin_alloca (size)
           #endif

       with messy consequences if one has a private version of this function.

       The fact that the code is inlined means that it is impossible  to  take
       the address of this function, or to change its behavior by linking with
       a different library.

       The inlined code often consists of a single instruction  adjusting  the
       stack  pointer,  and does not check for stack overflow.  Thus, there is
       no NULL error return.

BUGS
       There is no error indication if the stack  frame  cannot  be  extended.
       (However, after a failed allocation, the program is likely to receive a
       SIGSEGV signal if it attempts to access the unallocated space.)

       On many systems alloca() cannot be used inside the list of arguments of
       a  function  call,  because  the stack space reserved by alloca() would
       appear on the stack in the middle of the space for the  function  argu‐
       ments.

SEE ALSO
       brk(2), longjmp(3), malloc(3)

COLOPHON
       This  page  is  part of release 4.15 of the Linux man-pages project.  A
       description of the project, information about reporting bugs,  and  the
       latest     version     of     this    page,    can    be    found    at
       https://www.kernel.org/doc/man-pages/.

GNU                               2017-09-15                         ALLOCA(3)

_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make

config.log.zip (17K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Failed compile on Fedora 28, x86_64

Martin Dorey-2

I *thought* we are supposed to avoid alloca in 2018.


Amen brother.


martind@swiftboat:~/download/make-git/src$ sgrep -w alloca | wc -l
115
martind@swiftboat:~/download/make-git/src$ 

Ugh.


I'm building 4.2.1 from the tarball.


You'd have more luck from git, per:


https://savannah.gnu.org/bugs/?53597

I know I get tied up in autotools knots every time I have to git pull, so there's a patch there too.


From: Bug-make <bug-make-bounces+martin.dorey=[hidden email]> on behalf of Jeffrey Walton <[hidden email]>
Sent: Friday, August 24, 2018 12:06 PM
To: [hidden email]
Subject: Failed compile on Fedora 28, x86_64
 
I'm working on Fedora 28, x86_64 (fully patched). I'm building 4.2.1
from the tarball.

I *thought* we are supposed to avoid alloca in 2018. I guess this is
another reason why.

----------------------------------

...
gcc -DLOCALEDIR=\"/usr/local/share/locale\"
-DLIBDIR=\"/usr/local/lib64\" -DINCLUDEDIR=\"/usr/local/include\"
-DHAVE_CONFIG_H -I.  -I./glob  -I/usr/local/include -DNDEBUG  -g2 -O2
-m64 -march=native -fPIC -MT remote-stub.o -MD -MP -MF
.deps/remote-stub.Tpo -c -o remote-stub.o remote-stub.c
mv -f .deps/hash.Tpo .deps/hash.Po
mv -f .deps/remote-stub.Tpo .deps/remote-stub.Po
mv -f .deps/variable.Tpo .deps/variable.Po
mv -f .deps/read.Tpo .deps/read.Po
gcc  -g2 -O2 -m64 -march=native -fPIC -Wl,--export-dynamic
-L/usr/local/lib64 -m64 -Wl,-R,/usr/local/lib64 -Wl,--enable-new-dtags
-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 -lpthread
glob/libglob.a(glob.o): In function `glob_in_dir':
/home/test/make-4.2.1/glob/glob.c:1367: undefined reference to `__alloca'
/home/test/make-4.2.1/glob/glob.c:1342: undefined reference to `__alloca'
/home/test/make-4.2.1/glob/glob.c:1256: undefined reference to `__alloca'
/home/test/make-4.2.1/glob/glob.c:1283: undefined reference to `__alloca'
glob/libglob.a(glob.o): In function `glob':
/home/test/make-4.2.1/glob/glob.c:581: undefined reference to `__alloca'
glob/libglob.a(glob.o):/home/test/make-4.2.1/glob/glob.c:732: more
undefined references to `__alloca' follow
collect2: error: ld returned 1 exit status
gmake[2]: *** [Makefile:656: make] Error 1
gmake[2]: Leaving directory '/home/test/make-4.2.1'
gmake[1]: *** [Makefile:798: all-recursive] Error 1
gmake[1]: Leaving directory '/home/test/make-4.2.1'
gmake: *** [Makefile:534: all] Error 2
Failed to build Make

----------------------------------

Here's from the Fedora man pages. It should provide the header and
library information if a Fedora box is not handy.

ALLOCA(3)                  Linux Programmer's Manual                 ALLOCA(3)

NAME
       alloca - allocate memory that is automatically freed

SYNOPSIS
       #include <alloca.h>

       void *alloca(size_t size);

DESCRIPTION
       The  alloca() function allocates size bytes of space in the stack frame
       of the caller.  This temporary space is automatically  freed  when  the
       function that called alloca() returns to its caller.

RETURN VALUE
       The  alloca()  function returns a pointer to the beginning of the allo‐
       cated space.  If the allocation causes stack overflow, program behavior
       is undefined.

ATTRIBUTES
       For   an   explanation   of   the  terms  used  in  this  section,  see
       attributes(7).

       ┌──────────┬───────────────┬─────────┐
       │Interface │ Attribute     │ Value   │
       ├──────────┼───────────────┼─────────┤
       │alloca()  │ Thread safety │ MT-Safe │
       └──────────┴───────────────┴─────────┘
CONFORMING TO
       This function is not in POSIX.1.

       There is evidence that the alloca()  function  appeared  in  32V,  PWB,
       PWB.2,  3BSD,  and  4BSD.  There is a man page for it in 4.3BSD.  Linux
       uses the GNU version.

NOTES
       The alloca() function is machine- and compiler-dependent.  For  certain
       applications,  its  use  can  improve efficiency compared to the use of
       malloc(3) plus free(3).  In certain cases, it can also simplify  memory
       deallocation  in  applications  that  use  longjmp(3) or siglongjmp(3).
       Otherwise, its use is discouraged.

       Because the space allocated by alloca() is allocated within  the  stack
       frame,  that  space  is  automatically  freed if the function return is
       jumped over by a call to longjmp(3) or siglongjmp(3).

       Do not attempt to free(3) space allocated by alloca()!

   Notes on the GNU version
       Normally, gcc(1) translates calls to alloca() with inlined code.   This
       is  not done when either the -ansi, -std=c89, -std=c99, or the -std=c11
       option is given and the header <alloca.h> is not included.   Otherwise,
       (without  an  -ansi  or -std=c* option) the glibc version of <stdlib.h>
       includes <alloca.h> and that contains the lines:

           #ifdef  __GNUC__
           #define alloca(size)   __builtin_alloca (size)
           #endif

       with messy consequences if one has a private version of this function.

       The fact that the code is inlined means that it is impossible  to  take
       the address of this function, or to change its behavior by linking with
       a different library.

       The inlined code often consists of a single instruction  adjusting  the
       stack  pointer,  and does not check for stack overflow.  Thus, there is
       no NULL error return.

BUGS
       There is no error indication if the stack  frame  cannot  be  extended.
       (However, after a failed allocation, the program is likely to receive a
       SIGSEGV signal if it attempts to access the unallocated space.)

       On many systems alloca() cannot be used inside the list of arguments of
       a  function  call,  because  the stack space reserved by alloca() would
       appear on the stack in the middle of the space for the  function  argu‐
       ments.

SEE ALSO
       brk(2), longjmp(3), malloc(3)

COLOPHON
       This  page  is  part of release 4.15 of the Linux man-pages project.  A
       description of the project, information about reporting bugs,  and  the
       latest     version     of     this    page,    can    be    found    at
       https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.kernel.org%2Fdoc%2Fman-pages%2F&amp;data=01%7C01%7CMartin.Dorey%40hitachivantara.com%7Cafdfa6168cb24b62890808d60a032568%7C18791e1761594f52a8d4de814ca8284a%7C0&amp;sdata=qDRKClgJ%2BPGu46tvLS6WeG6lYL%2F85DrHin2C6bTgF4Y%3D&amp;reserved=0.

GNU                               2017-09-15                         ALLOCA(3)

_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

Re: Failed compile on Fedora 28, x86_64

Mike Gran
In reply to this post by Jeffrey Walton-3
On Fri, Aug 24, 2018 at 03:06:24PM -0400, Jeffrey Walton wrote:
> I'm working on Fedora 28, x86_64 (fully patched). I'm building 4.2.1
> from the tarball.
>
> I *thought* we are supposed to avoid alloca in 2018. I guess this is
> another reason why.

First, I am not a make maintainer.

You can see the patches that Fedora 28 applies to Make 4.2.1 to have
it build on its Koji page.  There are several patches.

Koji page
https://koji.fedoraproject.org/koji/rpminfo?rpmID=12659817

Source RPM with patches
https://kojipkgs.fedoraproject.org//packages/make/4.2.1/6.fc28/src/make-4.2.1-6.fc28.src.rpm

Alternately, you can get vanilla make 4.2.1 to build from source by
running ./configure CFLAGS="-D__alloca=alloca"

Regards,
Mike Gran

_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make