Re: Strange errors regarding function '__alloca' on a Debian buster/sid i686 system

2018-04-02 Thread Dennis Clarke 

On 02/04/18 02:00 PM, Paul Smith wrote:

On Mon, 2018-04-02 at 13:55 -0400, Dennis Clarke wrote:

Not sure what to do with that.


You may need this:
http://git.savannah.gnu.org/cgit/make.git/commit/?id=193f1e81edd6b1b56b0eb0ff8aa4b41c7b4257b4

Or, latest from Git HEAD.


I started over from the top and only used the release 4.2.1 tarball.

Managed to get everything to work however I need PERL_USE_UNSAFE_INC=1
to run the testsuite.

Here are the results and the patches.

---
FILE : make-4.2.1_linux_4.15.15-genunix_i686.005.patch01
---
*** configure.ac_backup Mon Jun  6 12:27:31 2016
--- configure.acMon Apr  2 16:57:41 2018
***
*** 399,408 
  #include 
  #include 

- #define GLOB_INTERFACE_VERSION 1
  #if !defined _LIBC && defined __GNU_LIBRARY__ && __GNU_LIBRARY__ > 1
  # include 
! # if _GNU_GLOB_INTERFACE_VERSION == GLOB_INTERFACE_VERSION
 gnu glob
  # endif
  #endif],
--- 399,407 
  #include 
  #include 

  #if !defined _LIBC && defined __GNU_LIBRARY__ && __GNU_LIBRARY__ > 1
  # include 
! # if _GNU_GLOB_INTERFACE_VERSION == 1 || _GNU_GLOB_INTERFACE_VERSION == 2
 gnu glob
  # endif
  #endif],


---
FILE make-4.2.1_linux_4.15.15-genunix_i686.005.patch02
---
*** dir.c.orig  2016-05-31 07:17:26.0 +
--- dir.c   2018-04-03 03:25:44.892913153 +
***
*** 1260,1276 
   * regular file; fix that here.
   */
  #if !defined(stat) && !defined(WINDOWS32) || defined(VMS)
! # ifndef VMS
! #  ifndef HAVE_SYS_STAT_H
  int stat (const char *path, struct stat *sbuf);
! #  endif
! # else
! /* We are done with the fake stat.  Go back to the real stat */
! #   ifdef stat
! # undef stat
! #   endif
! # endif
! # define local_stat stat
  #else
  static int
  local_stat (const char *path, struct stat *buf)
--- 1260,1276 
   * regular file; fix that here.
   */
  #if !defined(stat) && !defined(WINDOWS32) || defined(VMS)
! #ifndef VMS
! #ifndef HAVE_SYS_STAT_H
  int stat (const char *path, struct stat *sbuf);
! #endif
! #else
! /* We are done with the fake stat.  Go back to the real stat */
! #ifdef stat
! #undef stat
! #endif
! #endif
! #define local_stat stat
  #else
  static int
  local_stat (const char *path, struct stat *buf)
***
*** 1293,1300 
  return -1;
  }
  #endif

!   EINTRLOOP (e, stat (path, buf));
return e;
  }
  #endif
--- 1293,1322 
  return -1;
  }
  #endif
+ #endif

! /* Similarly for lstat.  */
! #if !defined(lstat) && !defined(WINDOWS32) || defined(VMS)
! #ifndef VMS
! #ifndef HAVE_SYS_STAT_H
! int lstat (const char *path, struct stat *sbuf);
! #endif
! #else
! /* We are done with the fake lstat.  Go back to the real lstat */
! #ifdef lstat
! #undef lstat
! #endif
! #endif
! #define local_lstat lstat
! #elif defined(WINDOWS32)
! /* Windows doesn't support lstat().  */
! #define local_lstat local_stat
! #else
! static int
! local_lstat (const char *path, struct stat *buf)
! {
!   int e;
!   EINTRLOOP (e, lstat (path, buf));
return e;
  }
  #endif
***
*** 1305,1313 
gl->gl_opendir = open_dirstream;
gl->gl_readdir = read_dirstream;
gl->gl_closedir = free;
gl->gl_stat = local_stat;
-   /* We don't bother setting gl_lstat, since glob never calls it.
-  The slot is only there for compatibility with 4.4 BSD.  */
  }

  void
--- 1327,1334 
gl->gl_opendir = open_dirstream;
gl->gl_readdir = read_dirstream;
gl->gl_closedir = free;
+   gl->gl_lstat = local_lstat;
gl->gl_stat = local_stat;
  }

  void

Setup a few env vars and here I use CFLAGS with c99 specified but NOT 
the pedantic warnings or errors.


phobos_$ env | sort
BUILD=/usr/local/build
CC=gcc
CFLAGS=-m32 -march=i386 -g -std=iso9899:1999 -Wl,-rpath=/usr/local/lib 
-D_POSIX_PTHREAD_SEMANTICS -D_TS_ERRNO

CONFIG_SHELL=/bin/bash
CPPFLAGS=-I/usr/local/include
CXXFLAGS=-m32 -march=i386 -g -std=iso9899:1999 -Wl,-rpath=/usr/local/lib 
-D_POSIX_PTHREAD_SEMANTICS -D_TS_ERRNO

CXX=g++
EDITOR=/usr/bin/vi
LANG=en_US.UTF-8
LC_COLLATE=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_MONETARY=en_US.UTF-8
LC_NUMERIC=en_US.UTF-8
LC_TIME=en_US.UTF-8
LD_OPTIONS=-R/usr/local/lib -L/usr/local/lib
LD_RUN_PATH=/usr/local/lib
PAGER=more
PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/sbin:/bin:/usr/sbin
PWD=/usr/local/build
SHELL=/bin/bash
SHLVL=1
SRC=/usr/local/src
TERM=vt100
TMPDIR=/var/tmp/dclarke
TZ=GMT0
USER=dclarke
_=/usr/bin/env
VISUAL=/usr/bin/vi


Apply those patches neatly to the tarball sources :


phobos_$ patch --verbose --backup < 
../make-4.2.1_linux_4.15.15-genunix_i686.005.patch01

Hmm...  Looks like a new-style context diff to me...
The text leading up to this was:
--
|*** configure.ac_backup

Re: Strange errors regarding function '__alloca' on a Debian buster/sid i686 system

2018-04-02 Thread Paul Smith 
On Mon, 2018-04-02 at 13:55 -0400, Dennis Clarke wrote:
> Not sure what to do with that.

You may need this:
http://git.savannah.gnu.org/cgit/make.git/commit/?id=193f1e81edd6b1b56b0eb0ff8aa4b41c7b4257b4

Or, latest from Git HEAD.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Strange errors regarding function '__alloca' on a Debian buster/sid i686 system

2018-04-02 Thread Dennis Clarke 

On 02/04/18 01:15 PM, Martin Dorey wrote:

checking whether closedir returns void... no
./configure: line 9678: PKG_PROG_PKG_CONFIG: command not found
./configure: line 9690: syntax error near unexpected token `GUILE,'
./configure: line 9690: `   PKG_CHECK_MODULES(GUILE, guile-2.0,
have_guile=yes,'
debi686$


Perhaps it's:



progress here .. sort of :

debi686$
debi686$ ldd make
linux-gate.so.1 (0xb7f4e000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb7efe000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7d25000)
/lib/ld-linux.so.2 (0xb7f5)
debi686$ ./make --version
GNU Make 4.2.1
Built for i686-pc-linux-gnu
Copyright (C) 1988-2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
debi686$

debi686$ export PERL_USE_UNSAFE_INC=1
debi686$ /usr/bin/time -p /usr/bin/make check 2>&1 | tee 
../make-4.2.1_linux_4.15.15-genunix_i686_git_48c8a116a914a325a0497721f5d8b58d5bba34d4.check.log 


Making check in glob
make[1]: Entering directory 
'/usr/local/build/make-4.2.1_linux_4.15.15-genunix_i686_git_48c8a116a914a325a0497721f5d8b58d5bba34d4/glob'

make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory 
'/usr/local/build/make-4.2.1_linux_4.15.15-genunix_i686_git_48c8a116a914a325a0497721f5d8b58d5bba34d4/glob'

Making check in config
make[1]: Entering directory 
'/usr/local/build/make-4.2.1_linux_4.15.15-genunix_i686_git_48c8a116a914a325a0497721f5d8b58d5bba34d4/config'

make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory 
'/usr/local/build/make-4.2.1_linux_4.15.15-genunix_i686_git_48c8a116a914a325a0497721f5d8b58d5bba34d4/config'

Making check in po
make[1]: Entering directory 
'/usr/local/build/make-4.2.1_linux_4.15.15-genunix_i686_git_48c8a116a914a325a0497721f5d8b58d5bba34d4/po'

make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory 
'/usr/local/build/make-4.2.1_linux_4.15.15-genunix_i686_git_48c8a116a914a325a0497721f5d8b58d5bba34d4/po'

Making check in doc
make[1]: Entering directory 
'/usr/local/build/make-4.2.1_linux_4.15.15-genunix_i686_git_48c8a116a914a325a0497721f5d8b58d5bba34d4/doc'

make[1]: Nothing to be done for 'check'.
make[1]: Leaving directory 
'/usr/local/build/make-4.2.1_linux_4.15.15-genunix_i686_git_48c8a116a914a325a0497721f5d8b58d5bba34d4/doc'
make[1]: Entering directory 
'/usr/local/build/make-4.2.1_linux_4.15.15-genunix_i686_git_48c8a116a914a325a0497721f5d8b58d5bba34d4'

/usr/bin/make  loadavg
make[2]: Entering directory 
'/usr/local/build/make-4.2.1_linux_4.15.15-genunix_i686_git_48c8a116a914a325a0497721f5d8b58d5bba34d4'
make[2]: Leaving directory 
'/usr/local/build/make-4.2.1_linux_4.15.15-genunix_i686_git_48c8a116a914a325a0497721f5d8b58d5bba34d4'

/usr/bin/make  check-local
make[2]: Entering directory 
'/usr/local/build/make-4.2.1_linux_4.15.15-genunix_i686_git_48c8a116a914a325a0497721f5d8b58d5bba34d4'
cd tests && perl ./run_make_tests.pl -srcdir 
/usr/local/build/make-4.2.1_linux_4.15.15-genunix_i686_git_48c8a116a914a325a0497721f5d8b58d5bba34d4 
-make ../make

--
   Running tests for GNU make on Linux phobos 4.15.15-genunix i686
GNU Make 4.2.1
--

Finding tests...

features/archives ... ok (10 passed)
features/comments ... ok (1 passed)
features/conditionals ... ok (5 passed)
features/default_names .. ok (3 passed)
features/double_colon ... ok (14 passed)
features/echoing  ok (4 passed)
features/errors . ok (3 passed)
features/escape . ok (8 passed)
features/export . ok (12 passed)
features/include  ok (15 passed)
features/jobserver .. ok (6 passed)
features/load ... ok (5 passed)
features/loadapi  ok (3 passed)
features/mult_rules . ok (2 passed)
features/mult_targets ... ok (2 passed)
features/order_only . ok (10 passed)
features/output-sync  ok (15 passed)
features/override ... ok (4 passed)
features/parallelism  ok (9 passed)
features/patspecific_vars ...

Re: Strange errors regarding function '__alloca' on a Debian buster/sid i686 system

2018-04-02 Thread Paul Smith 
On Mon, 2018-04-02 at 10:02 -0400, Dennis Clarke wrote:
> Well sure ... however before I get there I am still baffled why this
> current release code won't work on an old 32-bit intel debian server?

My understanding of the issue is that there's a compatibility problem
with the newly-released version of glibc.  If you're seeing this issue
with an older version of glibc, then maybe it's something different.

Regarding the kernel: the kernel has pretty much nothing that it
depends on, other than hardware and the compiler: obviously they have
very few library and tool interaction issues.  From an environment
portability standpoint, the kernel is one of the simplest packages
there is.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Strange errors regarding function '__alloca' on a Debian buster/sid i686 system

2018-04-02 Thread Dennis Clarke 



I don't know why that would have only kicked off now but, in my limited 
experience, autotools often works in ways that are similarly mysterious to me.




Yeah .. black magic under a full moon.  :-\

Let's just do a git head pull here and give that a whirl.

Dennis


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Strange errors regarding function '__alloca' on a Debian buster/sid i686 system

2018-04-02 Thread Dennis Clarke 



you went offlist .. let's not.

OK, I just was on a phone client that does not know my "real" email address,
used by the list, sorry.



no biggie .. it happens.



I meant to suggest to have a look at the output of ldd, to see
if there is anything weird there. E.g. I have (on the latest Fedora):

$ ldd `which make`
/usr/bin/make:
 linux-vdso.so.1 (0x7fff2dcbc000)
 libguile-2.0.so.22 => /lib64/libguile-2.0.so.22 (0x7f7cc7d0)
 libgc.so.1 => /lib64/libgc.so.1 (0x7f7cc79a4000)
 libdl.so.2 => /lib64/libdl.so.2 (0x7f7cc77a)
 libpthread.so.0 => /lib64/libpthread.so.0 (0x7f7cc7581000)
 libc.so.6 => /lib64/libc.so.6 (0x7f7cc71ac000)
 libffi.so.6 => /lib64/libffi.so.6 (0x7f7cc6fa4000)
 libunistring.so.2 => /lib64/libunistring.so.2 (0x7f7cc6c32000)
 libgmp.so.10 => /lib64/libgmp.so.10 (0x7f7cc69bb000)
 libltdl.so.7 => /lib64/libltdl.so.7 (0x7f7cc67b1000)
 libcrypt.so.1 => /lib64/libcrypt.so.1 (0x7f7cc657b000)
 libm.so.6 => /lib64/libm.so.6 (0x7f7cc6265000)
 /lib64/ld-linux-x86-64.so.2 (0x7f7cc82c8000)
 libatomic_ops.so.1 => /lib64/libatomic_ops.so.1 (0x7f7cc6062000)
 libfreebl3.so => /lib64/libfreebl3.so (0x7f7cc5e5f000)



That looks bonkers to me ... Red Hat ?   Nope .. even on a RHEL 7.4 
system I have :


-bash-4.2$ which make
/bin/make
-bash-4.2$ ldd /bin/make
linux-vdso.so.1 =>  (0x7fff205fd000)
libc.so.6 => /lib64/libc.so.6 (0x7fd570f2)
/lib64/ld-linux-x86-64.so.2 (0x562392bba000)
-bash-4.2$
-bash-4.2$ uname -r
3.10.0-693.17.1.el7.x86_64
-bash-4.2$


Here on the debian sid i686 unit I have :

debi686$ which make
/usr/bin/make
debi686$ ldd /usr/bin/make
linux-gate.so.1 (0xb7f2f000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb7edf000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7d06000)
/lib/ld-linux.so.2 (0xb7f31000)


So no bonkers dependencies.

Dennis

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

RE: Strange errors regarding function '__alloca' on a Debian buster/sid i686 system

2018-04-02 Thread Martin Dorey 
> checking whether closedir returns void... no
> ./configure: line 9678: PKG_PROG_PKG_CONFIG: command not found
> ./configure: line 9690: syntax error near unexpected token `GUILE,'
> ./configure: line 9690: `   PKG_CHECK_MODULES(GUILE, guile-2.0, 
> have_guile=yes,'
> debi686$

Perhaps it's:

https://askubuntu.com/questions/468661/how-to-fix-pkg-prog-pkg-config-command-not-found-error

I have that installed on the Debian box where I work on Make:

martind@swiftboat:~$ dpkg -S /usr/share/aclocal/pkg.m4
pkg-config: /usr/share/aclocal/pkg.m4
martind@swiftboat:~$

I don't know why that would have only kicked off now but, in my limited 
experience, autotools often works in ways that are similarly mysterious to me.
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Strange errors regarding function '__alloca' on a Debian buster/sid i686 system

2018-04-02 Thread Dmitrii Pasechnik 
On Mon, Apr 02, 2018 at 10:44:53AM -0400, Dennis Clarke wrote:
> On 02/04/18 10:21 AM, Dmitrii Pasechnik wrote:
> > I just wonder whether this is a relatively common case of an updated
> > make dependence, which is incompatible on the binary level (e.g. due to
> > wrong minor version number).
> > E.g. if your make has guile extension enabled, it is easy to shoot
> > yourself in the foot by hacking on one of libguile dependencies...
> > 
> 
> you went offlist .. let's not.
OK, I just was on a phone client that does not know my "real" email address,
used by the list, sorry.

> 
> Also, not sure how to check for whatever it is you suggest.
> 
> root@phobos:~# which make
> /usr/bin/make
> root@phobos:~# file /usr/bin/make
> /usr/bin/make: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV),
> dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32,
> BuildID[sha1]=fcdb8756a78eb97afc306cc2c6acce391bfafbc3, stripped
> root@phobos:~#

I meant to suggest to have a look at the output of ldd, to see
if there is anything weird there. E.g. I have (on the latest Fedora):

$ ldd `which make`
/usr/bin/make:
linux-vdso.so.1 (0x7fff2dcbc000)
libguile-2.0.so.22 => /lib64/libguile-2.0.so.22 (0x7f7cc7d0)
libgc.so.1 => /lib64/libgc.so.1 (0x7f7cc79a4000)
libdl.so.2 => /lib64/libdl.so.2 (0x7f7cc77a)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7f7cc7581000)
libc.so.6 => /lib64/libc.so.6 (0x7f7cc71ac000)
libffi.so.6 => /lib64/libffi.so.6 (0x7f7cc6fa4000)
libunistring.so.2 => /lib64/libunistring.so.2 (0x7f7cc6c32000)
libgmp.so.10 => /lib64/libgmp.so.10 (0x7f7cc69bb000)
libltdl.so.7 => /lib64/libltdl.so.7 (0x7f7cc67b1000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x7f7cc657b000)
libm.so.6 => /lib64/libm.so.6 (0x7f7cc6265000)
/lib64/ld-linux-x86-64.so.2 (0x7f7cc82c8000)
libatomic_ops.so.1 => /lib64/libatomic_ops.so.1 (0x7f7cc6062000)
libfreebl3.so => /lib64/libfreebl3.so (0x7f7cc5e5f000)

Best,
Dima

> 
> Dennis
> 
> 
> ___
> Bug-make mailing list
> Bug-make@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-make

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Strange errors regarding function '__alloca' on a Debian buster/sid i686 system

2018-04-02 Thread Dennis Clarke 

On 02/04/18 11:24 AM, Martin Dorey wrote:

 > why this current release code won't work

https://lists.gnu.org/archive/html/info-gnu/2016-06/msg5.html says 
make-4.2.1 is from 2016-06-11.  In the email thread I cited previously, 
for what looked like the same errors, we see Paul writing, over a year 
after that release, on 2017-11-19, "I pushed a change that should allow 
this to work properly".  So the reason that the current release code 
won't work is, I suggest, because there hasn't been a new release that 
includes that change.  Why not cut to the chase, prove it ...


sure thing .. let's do that and make a 4.2.2 release.


Paul's patch was:

http://git.savannah.gnu.org/cgit/make.git/commit/?id=48c8a116a914a325a0497721f5d8b58d5bba34d4


That doesn't strictly line up anymore .. close enough :

debi686$ diff -c configure.ac_backup configure.ac
*** configure.ac_backup Mon Jun  6 12:27:31 2016
--- configure.acMon Apr  2 16:57:41 2018
***
*** 399,408 
  #include 
  #include 

- #define GLOB_INTERFACE_VERSION 1
  #if !defined _LIBC && defined __GNU_LIBRARY__ && __GNU_LIBRARY__ > 1
  # include 
! # if _GNU_GLOB_INTERFACE_VERSION == GLOB_INTERFACE_VERSION
 gnu glob
  # endif
  #endif],
--- 399,407 
  #include 
  #include 

  #if !defined _LIBC && defined __GNU_LIBRARY__ && __GNU_LIBRARY__ > 1
  # include 
! # if _GNU_GLOB_INTERFACE_VERSION == 1 || _GNU_GLOB_INTERFACE_VERSION == 2
 gnu glob
  # endif
  #endif],




>Still, perhaps you could patch whatever file the

configure script is generating there as a quick proof of concept.



Doing a quick hack on the 4.2.1 release tarball first.

debi686$ autoreconf -v -f
autoreconf: Entering directory `.'
autoreconf: configure.ac: not running autopoint: --install not given
autoreconf: running: aclocal --force -I config
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --force-missing
autoreconf: Leaving directory `.'
debi686$

well .. this is weird :

debi686$ ./configure --prefix=/usr/local --program-prefix=g \
> --disable-silent-rules --enable-dependency-tracking \
> --with-gnu-ld --without-libiconv-prefix \
> --without-libintl-prefix 2>&1 | tee 
../make-4.2.1_linux_4.15.15-genunix_i686_git_48c8a116a914a325a0497721f5d8b58d5bba34d4.config.log

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking dependency style of gcc... (cached) gcc3
checking for ranlib... ranlib
checking how to run the C preprocessor... gcc -E
checking for ar... ar
checking for perl... perl
checking the archiver (ar) interface... ar
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for library containing strerror... none required
checking for a sed that does not truncate output... /bin/sed
checking whether NLS is requested... yes
checking for msgfmt... /usr/bin/msgfmt
checking for gmsgfmt... /usr/bin/msgfmt
checking for xgettext... /usr/bin/xgettext
checking for msgmerge... /usr/bin/msgmerge
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for shared library run path origin... done
checking for CFPreferencesCopyAppValue... no

Re: Strange errors regarding function '__alloca' on a Debian buster/sid i686 system

2018-04-02 Thread Martin Dorey 
> why this current release code won't work

https://lists.gnu.org/archive/html/info-gnu/2016-06/msg5.html says 
make-4.2.1 is from 2016-06-11.  In the email thread I cited previously, for 
what looked like the same errors, we see Paul writing, over a year after that 
release, on 2017-11-19, "I pushed a change that should allow this to work 
properly".  So the reason that the current release code won't work is, I 
suggest, because there hasn't been a new release that includes that change.  
Why not cut to the chase, prove it, tell us and thus help to encourage a new 
release?  If you want a shortcut, perhaps Paul's patch was:

http://git.savannah.gnu.org/cgit/make.git/commit/?id=48c8a116a914a325a0497721f5d8b58d5bba34d4

But patching configure.ac sounds like something that would then need the full 
build-from-git procedure, with autotools, rather than the build from a release 
tarball, in which case I think you'd be better off with the git head.  Still, 
perhaps you could patch whatever file the configure script is generating there 
as a quick proof of concept.

On Apr 2, 2018, at 07:03, Dennis Clarke 
> wrote:

On 01/04/18 05:29 PM, Paul Smith wrote:
On Sun, 2018-04-01 at 16:56 -0400, Dennis Clarke wrote:
So I could just lift that out of glibc 2.27 and drop it into the make
  source tree and have a go at it.  Is that the idea here ?
You could try, but I'm not optimistic that it will just work.

"just work" ?  nope.  not even close.

I think the way forward is to get the latest code from GNU make's Git
repository and see if that works:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsavannah.gnu.org%2Fgit%2F%3Fgroup%3Dmake=01%7C01%7CMartin.Dorey%40hitachivantara.com%7C3aaed7f79d5f44e9e21408d598a289ba%7C18791e1761594f52a8d4de814ca8284a%7C0=A3q0nOCtgUS08XtpHymxJQOZ2qTFK9f8Kuo3wgXKhaI%3D=0

Well sure ... however before I get there I am still baffled why this
current release code won't work on an old 32-bit intel debian server?

I just compiled kernel 4.15.15 on that machine and am running it now.

Certainly if I can compile and run a new kernel on the same machine I
would think I can compile GNU make from sources?  Or am I stretching
here?

root@phobos:~# cat /proc/version
Linux version 4.15.15-genunix (admsys@phobos) (gcc version 7.3.0 (Debian 
7.3.0-13)) #1 SMP Sun Apr 1 22:27:12 UTC 2018


Be sure to read the README.git file for information on building from
Git, rather than from a source distribution (it requires extra packages
to be installed, such as autotools).

yep .. autoreconf and its brethern however I suspect something else is
going on here.

Dennis

___
Bug-make mailing list
Bug-make@gnu.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnu.org%2Fmailman%2Flistinfo%2Fbug-make=01%7C01%7CMartin.Dorey%40hitachivantara.com%7C3aaed7f79d5f44e9e21408d598a289ba%7C18791e1761594f52a8d4de814ca8284a%7C0=yjRoh86gJtY5iJrwAVzEcjD5kfyBTIIEgC9Fjx2qFCo%3D=0
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Strange errors regarding function '__alloca' on a Debian buster/sid i686 system

2018-04-02 Thread Dennis Clarke 

On 02/04/18 10:21 AM, Dmitrii Pasechnik wrote:

Hi,
I just wonder whether this is a relatively common case of an updated 
make dependence, which is incompatible on the binary level (e.g. due to 
wrong minor version number).
E.g. if your make has guile extension enabled, it is easy to shoot 
yourself in the foot by hacking on one of libguile dependencies...




you went offlist .. let's not.

Also, not sure how to check for whatever it is you suggest.

root@phobos:~# which make
/usr/bin/make
root@phobos:~# file /usr/bin/make
/usr/bin/make: ELF 32-bit LSB shared object, Intel 80386, version 1 
(SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for 
GNU/Linux 2.6.32, 
BuildID[sha1]=fcdb8756a78eb97afc306cc2c6acce391bfafbc3, stripped

root@phobos:~#

Dennis


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Strange errors regarding function '__alloca' on a Debian buster/sid i686 system

2018-04-02 Thread Dennis Clarke 

On 01/04/18 05:29 PM, Paul Smith wrote:

On Sun, 2018-04-01 at 16:56 -0400, Dennis Clarke wrote:

So I could just lift that out of glibc 2.27 and drop it into the make
   source tree and have a go at it.  Is that the idea here ?


You could try, but I'm not optimistic that it will just work.


"just work" ?  nope.  not even close.


I think the way forward is to get the latest code from GNU make's Git
repository and see if that works:

https://savannah.gnu.org/git/?group=make



Well sure ... however before I get there I am still baffled why this
current release code won't work on an old 32-bit intel debian server?

I just compiled kernel 4.15.15 on that machine and am running it now.

Certainly if I can compile and run a new kernel on the same machine I
would think I can compile GNU make from sources?  Or am I stretching
here?

root@phobos:~# cat /proc/version
Linux version 4.15.15-genunix (admsys@phobos) (gcc version 7.3.0 (Debian 
7.3.0-13)) #1 SMP Sun Apr 1 22:27:12 UTC 2018




Be sure to read the README.git file for information on building from
Git, rather than from a source distribution (it requires extra packages
to be installed, such as autotools).


yep .. autoreconf and its brethern however I suspect something else is
 going on here.

Dennis

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Strange errors regarding function '__alloca' on a Debian buster/sid i686 system

2018-04-01 Thread Paul Smith 
On Sun, 2018-04-01 at 16:56 -0400, Dennis Clarke wrote:
> So I could just lift that out of glibc 2.27 and drop it into the make
>   source tree and have a go at it.  Is that the idea here ?

You could try, but I'm not optimistic that it will just work.

I think the way forward is to get the latest code from GNU make's Git
repository and see if that works:

https://savannah.gnu.org/git/?group=make

Be sure to read the README.git file for information on building from
Git, rather than from a source distribution (it requires extra packages
to be installed, such as autotools).

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Strange errors regarding function '__alloca' on a Debian buster/sid i686 system

2018-04-01 Thread Dennis Clarke 



So I could just lift that out of glibc 2.27 and drop it into the make
  source tree and have a go at it.  Is that the idea here ?



phobos$ ls -lap glob
total 216
drwxr-sr-x 3 dclarke devl  4096 Apr  1 21:08 ./
drwxr-sr-x 9 dclarke devl  4096 Apr  1 21:02 ../
-rw-r--r-- 1 dclarke devl  1748 Jan 13  2013 configure.bat
-rw-r--r-- 1 dclarke devl 25263 Jan 13  2013 COPYING.LIB
drwxr-sr-x 2 dclarke devl  4096 Apr  1 21:02 .deps/
-rw-r--r-- 1 dclarke devl  1855 Feb  1 16:17 flexmember.h
-rw-r--r-- 1 dclarke devl 13510 Feb  1 16:17 fnmatch.c
-rw-r--r-- 1 dclarke devl  2295 Feb  1 16:17 fnmatch.h
-rw-r--r-- 1 dclarke devl 31335 Feb  1 16:17 fnmatch_loop.c
-rw-r--r-- 1 dclarke devl 38745 Feb  1 16:17 glob.c
-rw-r--r-- 1 dclarke devl  6614 Feb  1 16:17 glob.h
-rw-r--r-- 1 dclarke devl  1619 Feb  1 16:17 glob_internal.h
-rw-r--r-- 1 dclarke devl 18314 Apr  1 21:02 Makefile
-rw-r--r-- 1 dclarke devl  1124 Jan 13  2013 Makefile.am
-rw-r--r-- 1 dclarke devl  2046 Jan 13  2013 Makefile.ami
-rw-r--r-- 1 dclarke devl 18293 Jun 10  2016 Makefile.in
-rw-r--r-- 1 dclarke devl   195 Jan 13  2013 SCOPTIONS
-rw-r--r-- 1 dclarke devl  5089 Feb  1 16:17 scratch_buffer.h
-rw-r--r-- 1 dclarke devl  2035 Jan 13  2013 SMakefile
phobos$


nope .. that is a large mistake :

phobos$ make
make  all-recursive
make[1]: Entering directory 
'/usr/local/build/make-4.2.1_linux_4.13.0-1-686_i686.002'

Making all in glob
make[2]: Entering directory 
'/usr/local/build/make-4.2.1_linux_4.13.0-1-686_i686.002/glob'
gcc -DHAVE_CONFIG_H -I. -I..   -I/usr/local/include  -m32 -march=i386 -g 
-std=iso9899:1999 -Wl,-rpath=/usr/local/lib -D_POSIX_PTHREAD_SEMANTICS 
-D_TS_ERRNO -MT glob.o -MD -MP -MF .deps/glob.Tpo -c -o glob.o glob.c

In file included from glob.c:79:0:
./scratch_buffer.h:69:11: error: unknown type name ‘max_align_t’
   union { max_align_t __align; char __c[1024]; } __space;
   ^~~
./scratch_buffer.h:95:1: warning: return type defaults to ‘int’ 
[-Wimplicit-int]

 libc_hidden_proto (__libc_scratch_buffer_grow)
 ^
./scratch_buffer.h: In function ‘libc_hidden_proto’:
./scratch_buffer.h:100:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or 
‘__attribute__’ before ‘{’ token

 {
 ^
./scratch_buffer.h:107:1: error: expected declaration specifiers before 
‘libc_hidden_proto’

 libc_hidden_proto (__libc_scratch_buffer_grow_preserve)
 ^
./scratch_buffer.h:124:1: error: expected declaration specifiers before 
‘libc_hidden_proto’

 libc_hidden_proto (__libc_scratch_buffer_set_array_size)
 ^
glob.c:81:20: error: storage class specified for parameter ‘next_brace_sub’
 static const char *next_brace_sub (const char *begin, int flags) 
__THROWNL;

^~
glob.c:81:1: warning: ‘__nothrow__’ attribute ignored [-Wattributes]
 static const char *next_brace_sub (const char *begin, int flags) 
__THROWNL;

 ^~
glob.c:83:22: error: storage class specified for parameter ‘dirent_type’
 typedef uint_fast8_t dirent_type;
  ^~~
glob.c:102:3: error: expected specifier-qualifier-list before ‘dirent_type’
   dirent_type type;
   ^~~
glob.c:98:1: warning: empty declaration
 struct readdir_result
 ^~
glob.c:108:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
before ‘readdir_result_type’

 readdir_result_type (struct readdir_result d)
 ^~~
glob.c:138:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
before ‘{’ token

 {
 ^
glob.c:186:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
before ‘{’ token

 {
 ^
glob.c:213:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
before ‘{’ token

 {
 ^
glob.c:224:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
before ‘{’ token

 {
 ^
glob.c:230:12: error: storage class specified for parameter ‘glob_in_dir’
 static int glob_in_dir (const char *pattern, const char *directory,
^~~
glob.c:233:12: error: storage class specified for parameter ‘prefix_array’
 static int prefix_array (const char *prefix, char **array, size_t n) 
__THROWNL;

^~~~
glob.c:233:1: warning: ‘__nothrow__’ attribute ignored [-Wattributes]
 static int prefix_array (const char *prefix, char **array, size_t n) 
__THROWNL;

 ^~
glob.c:234:12: error: storage class specified for parameter 
‘collated_compare’

 static int collated_compare (const void *, const void *) __THROWNL;
^~~~
glob.c:234:1: warning: ‘__nothrow__’ attribute ignored [-Wattributes]
 static int collated_compare (const void *, const void *) __THROWNL;
 ^~
glob.c:241:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
before ‘{’ token

 {
 ^
glob.c:252:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
before ‘{’ token

 {
 ^
glob.c:289:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
before ‘{’ token

 {
 ^
glob.c:1172:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ 
before ‘{’ token

 {
 ^

Re: Strange errors regarding function '__alloca' on a Debian buster/sid i686 system

2018-04-01 Thread Dennis Clarke 

On 01/04/18 02:58 PM, Paul Smith wrote:

On Sun, 2018-04-01 at 14:54 -0400, Paul Smith wrote:

The contents of the glob/ directory are actually taken directly from
glibc (although at this point an extremely old version) not developed
by GNU make.


Oh, or Martin's reply.  I guess I'm getting really old since this rang
zero bells for me and it was barely 5 months ago... sigh.



Hrmmm .. well thank you both for the reply but I am left wondering what 
actions to take here, if any. I have very up to date glibc now :



phobos$ ldd --version
ldd (Debian GLIBC 2.27-2) 2.27
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

Also I went and fetched the sources and am curious where this "glob" is 
to be found :


phobos$ pwd
/usr/local/build/glibc-2.27

Wherein I see :

./posix/glob.c

Lovely name glob .. but regardless the diff between this and the glob.c 
inside the make sources isn't trivial :


phobos$ diff ../make-4.2.1_linux_4.13.0-1-686_i686.001/glob/glob.c 
./posix/glob.c | wc -l

2310

So I could just lift that out of glibc 2.27 and drop it into the make
 source tree and have a go at it.  Is that the idea here ?

Dennis

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Strange errors regarding function '__alloca' on a Debian buster/sid i686 system

2018-04-01 Thread Paul Smith 
On Sun, 2018-04-01 at 14:54 -0400, Paul Smith wrote:
> The contents of the glob/ directory are actually taken directly from
> glibc (although at this point an extremely old version) not developed
> by GNU make.

Oh, or Martin's reply.  I guess I'm getting really old since this rang
zero bells for me and it was barely 5 months ago... sigh.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Strange errors regarding function '__alloca' on a Debian buster/sid i686 system

2018-04-01 Thread Paul Smith 
On Sun, 2018-04-01 at 13:18 -0400, Dennis Clarke wrote:
> '/usr/local/build/make-4.2.1_linux_4.15.12-genunix_i686.003/glob'
> gcc -DHAVE_CONFIG_H -I. -I.. -g -O2 -MT glob.o -MD -MP -MF 
> .deps/glob.Tpo -c -o glob.o glob.c
> glob.c: In function 'glob':
> glob.c:581:23: warning: implicit declaration of function '__alloca'; did 
> you mean 'alloca'? [-Wimplicit-function-declaration]
> newp = (char *) __alloca (dirlen + 1);
> ^~~~
> alloca
> glob.c:814:11: warning: implicit declaration of function '__stat'; did 
> you mean '__xstat'? [-Wimplicit-function-declaration]
>   : __stat (dirname, )) == 0
> ^~
> __xstat

The contents of the glob/ directory are actually taken directly from
glibc (although at this point an extremely old version) not developed
by GNU make.

Examining the source code, I'd say that your system is defining
__GNU_LIBRARY__ but is not creating all the expected aspects of having
__GNU_LIBRARY__ defined; for example:

  #ifndef __GNU_LIBRARY__
  # define __stat stat
 ...
  #endif

the __stat macro is only defined if __GNU_LIBRARY__ is not defined...
because it's expected that if __GNU_LIBRARY__ is defined then we're
compiling glob to be part of glibc.

I would use "make glob/glob.i" then examine the resulting "glob/glob.i"
file to find out who is setting __GNU_LIBRARY__, and why.

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make