error building pynormaliz with 8.8.beta6

[Sébastien Labbé]

Bonsoir,

As I reported in sage-release for 8.8.beta6 [1], I get troubles installing pynormaliz. I pasted the log on framabin here [2]. I am running Ubuntu 16.04.

The discussion started on the closed ticket #27731 [3], but it is better to continue it on sage-devel.

Sébastien

[1] https://groups.google.com/d/msg/sage-release/CHxw0WQQLpE/D_jWIruEBQAJ

[2] https://framabin.org/p/?a648d45c0650b5cd#6Z9TY9HfEOFxlM5mHck+Hk1/17KgtcFqn8XFEy3vq9M=

[3] https://trac.sagemath.org/ticket/27731

[Vincent Delecroix]

Salut,

Could you try running manually (in the tmp build repo of pynormaliz)

$ sage -sh
$ ./configure

[Vincent Delecroix]

This line in your log is also very suspicious

{{{
configure: error: source directory already configured; run "make
distclean" there first
}}}

It comes from the Sage main configure script. It seems that your
install suffers some inconsistencies.

Vincent

Le 23/05/2019 à 22:55, Sébastien Labbé a écrit :

[Sébastien Labbé]

$ cd /home/slabbe/GitBox/sage/local/var/tmp/sage/build/pynormaliz-2.5/src
$ sage -sh

Starting subshell with Sage environment variables set.  Don't forget
to exit when you are done.  Beware:
 * Do not do anything with other copies of Sage on your system.
 * Do not use this for installing Sage packages using "sage -i" or for
   running "make" at Sage's root directory.  These should be done
   outside the Sage shell.

Bypassing shell configuration files...

Note: SAGE_ROOT=/home/slabbe/GitBox/sage

$ ./configure

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 g++ -std=gnu++11 accepts -g... yes
checking whether g++ -std=gnu++11 supports C++11 features with -std=gnu++11... yes
configure: creating ./config.status
config.status: creating config.py
(sage-sh) slabbe@miami:src$
(sage-sh) slabbe@miami:src$ ls
config.log     configure  GPLv2              PyNormaliz.py  tests
config.py      COPYING      m4              Readme.md
config.py.in   doc      NormalizModule.cpp  setup.cfg
config.status  examples   PKG-INFO          setup.py

Now, if you want to see the config.log, here it is:

$ cat config.log

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by PyNormaliz configure VERSION, which was
generated by GNU Autoconf 2.69.  Invocation command line was

  $ ./configure

## --------- ##
## Platform. ##
## --------- ##

hostname = miami
uname -m = x86_64
uname -r = 4.4.0-143-generic
uname -s = Linux
uname -v = #169-Ubuntu SMP Thu Feb 7 07:56:38 UTC 2019

/usr/bin/uname -p = unknown
/bin/uname -X     = unknown

/bin/arch              = unknown
/usr/bin/arch -k       = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo      = unknown
/bin/machine           = unknown
/usr/bin/oslevel       = unknown
/bin/universe          = unknown

PATH: /home/slabbe/GitBox/sage/local/libexec/ccache
PATH: /home/slabbe/GitBox/sage/build/bin
PATH: /home/slabbe/GitBox/sage/src/bin
PATH: /home/slabbe/GitBox/sage/local/bin
PATH: /home/slabbe/GitBox/sage
PATH: /home/slabbe/GitBox/scripts
PATH: /home/slabbe/bin
PATH: /home/slabbe/Applications/bin
PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /sbin
PATH: /bin
PATH: /usr/games
PATH: /usr/local/games
PATH: /opt/gurobi811/linux64/bin


## ----------- ##
## Core tests. ##
## ----------- ##

configure:1939: checking for C++ compiler version
configure:1948: g++ -std=gnu++11 --version >&5
g++ (Ubuntu 5.4.0-6ubuntu1~16.04.11) 5.4.0 20160609
Copyright (C) 2015 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.

configure:1959: $? = 0
configure:1948: g++ -std=gnu++11 -v >&5
Using built-in specs.
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.4.0-6ubuntu1~16.04.11' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.11)
configure:1959: $? = 0
configure:1948: g++ -std=gnu++11 -V >&5
g++: error: unrecognized command line option '-V'
g++: fatal error: no input files
compilation terminated.
configure:1959: $? = 1
configure:1948: g++ -std=gnu++11 -qversion >&5
g++: error: unrecognized command line option '-qversion'
g++: fatal error: no input files
compilation terminated.
configure:1959: $? = 1
configure:1979: checking whether the C++ compiler works
configure:2001: g++ -std=gnu++11   -L/home/slabbe/GitBox/sage/local/lib -Wl,-rpath,/home/slabbe/GitBox/sage/local/lib  conftest.cpp  >&5
configure:2005: $? = 0
configure:2053: result: yes
configure:2056: checking for C++ compiler default output file name
configure:2058: result: a.out
configure:2064: checking for suffix of executables
configure:2071: g++ -std=gnu++11 -o conftest   -L/home/slabbe/GitBox/sage/local/lib -Wl,-rpath,/home/slabbe/GitBox/sage/local/lib  conftest.cpp  >&5
configure:2075: $? = 0
configure:2097: result:
configure:2119: checking whether we are cross compiling
configure:2127: g++ -std=gnu++11 -o conftest   -L/home/slabbe/GitBox/sage/local/lib -Wl,-rpath,/home/slabbe/GitBox/sage/local/lib  conftest.cpp  >&5
configure:2131: $? = 0
configure:2138: ./conftest
configure:2142: $? = 0
configure:2157: result: no
configure:2162: checking for suffix of object files
configure:2184: g++ -std=gnu++11 -c   conftest.cpp >&5
configure:2188: $? = 0
configure:2209: result: o
configure:2213: checking whether we are using the GNU C++ compiler
configure:2232: g++ -std=gnu++11 -c   conftest.cpp >&5
configure:2232: $? = 0
configure:2241: result: yes
configure:2250: checking whether g++ -std=gnu++11 accepts -g
configure:2270: g++ -std=gnu++11 -c -g  conftest.cpp >&5
configure:2270: $? = 0
configure:2311: result: yes
configure:2423: checking whether g++ -std=gnu++11 supports C++11 features with -std=gnu++11
configure:2719: g++ -std=gnu++11 -std=gnu++11 -c -g -O2  conftest.cpp >&5
configure:2719: $? = 0
configure:2728: result: yes
configure:3107: g++ -std=gnu++11 -std=gnu++11 -o conftest -g -O2  -L/home/slabbe/GitBox/sage/local/lib -Wl,-rpath,/home/slabbe/GitBox/sage/local/lib  conftest.cpp  >&5
configure:3107: $? = 0
configure:3141: g++ -std=gnu++11 -std=gnu++11 -o conftest -g -O2  -L/home/slabbe/GitBox/sage/local/lib -Wl,-rpath,/home/slabbe/GitBox/sage/local/lib  conftest.cpp  >&5
configure:3141: $? = 0
configure:3141: ./conftest
configure:3141: $? = 0
configure:3307: creating ./config.status

## ---------------------- ##
## Running config.status. ##
## ---------------------- ##

This file was extended by PyNormaliz config.status VERSION, which was
generated by GNU Autoconf 2.69.  Invocation command line was

  CONFIG_FILES    =
  CONFIG_HEADERS  =
  CONFIG_LINKS    =
  CONFIG_COMMANDS =
  $ ./config.status

on miami

config.status:721: creating config.py

## ---------------- ##
## Cache variables. ##
## ---------------- ##

ac_cv_cxx_compiler_gnu=yes
ac_cv_env_CCC_set=
ac_cv_env_CCC_value=
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CXXFLAGS_set=
ac_cv_env_CXXFLAGS_value=
ac_cv_env_CXX_set=set
ac_cv_env_CXX_value='g++ -std=gnu++11'
ac_cv_env_LDFLAGS_set=set
ac_cv_env_LDFLAGS_value='-L/home/slabbe/GitBox/sage/local/lib -Wl,-rpath,/home/slabbe/GitBox/sage/local/lib '
ac_cv_env_LIBS_set=
ac_cv_env_LIBS_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=
ac_cv_env_host_alias_value=
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_objext=o
ac_cv_prog_cxx_g=yes
ax_cv_cxx_compile_cxx11__std_gnupp11=yes

## ----------------- ##
## Output variables. ##
## ----------------- ##

CPPFLAGS=''
CXX='g++ -std=gnu++11 -std=gnu++11'
CXXFLAGS='-g -O2'
DEFS='-DPACKAGE_NAME=\"PyNormaliz\" -DPACKAGE_TARNAME=\"pynormaliz\" -DPACKAGE_VERSION=\"VERSION\" -DPACKAGE_STRING=\"PyNormaliz\ VERSION\" -DPACKAGE_BUGREPORT=\"https://github.com/Normaliz/PyNormaliz\" -DPACKAGE_URL=\"\" -DHAVE_CXX11=1'
ECHO_C=''
ECHO_N='-n'
ECHO_T=''
ENFNORMALIZ='True'
EXEEXT=''
HAVE_CXX11='1'
LDFLAGS='-L/home/slabbe/GitBox/sage/local/lib -Wl,-rpath,/home/slabbe/GitBox/sage/local/lib '
LIBOBJS=''
LIBS=''
LTLIBOBJS=''
OBJEXT='o'
PACKAGE_BUGREPORT='https://github.com/Normaliz/PyNormaliz'
PACKAGE_NAME='PyNormaliz'
PACKAGE_STRING='PyNormaliz VERSION'
PACKAGE_TARNAME='pynormaliz'
PACKAGE_URL=''
PACKAGE_VERSION='VERSION'
PATH_SEPARATOR=':'
SHELL='/bin/bash'
ac_ct_CXX=''
bindir='${exec_prefix}/bin'
build_alias=''
datadir='${datarootdir}'
datarootdir='${prefix}/share'
docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'
dvidir='${docdir}'
exec_prefix='${prefix}'
host_alias=''
htmldir='${docdir}'
includedir='${prefix}/include'
infodir='${datarootdir}/info'
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
localedir='${datarootdir}/locale'
localstatedir='${prefix}/var'
mandir='${datarootdir}/man'
oldincludedir='/usr/include'
pdfdir='${docdir}'
prefix='/usr/local'
program_transform_name='s,x,x,'
psdir='${docdir}'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
sysconfdir='${prefix}/etc'
target_alias=''

## ----------- ##
## confdefs.h. ##
## ----------- ##

/* confdefs.h */
#define PACKAGE_NAME "PyNormaliz"
#define PACKAGE_TARNAME "pynormaliz"
#define PACKAGE_VERSION "VERSION"
#define PACKAGE_STRING "PyNormaliz VERSION"
#define PACKAGE_BUGREPORT "https://github.com/Normaliz/PyNormaliz"
#define PACKAGE_URL ""
#define HAVE_CXX11 1

configure: exit 0

[Vincent Delecroix]

So the PyNormaliz configure script is actually working... you strangely
obtained an error when it was run via the setup.py script with the
mysterious

configure: error: source directory already configured; run "make
distclean" there first

Vincent

[Sébastien Labbé]

>     configure: error: source directory already configured; run "make distclean" there first

Is this the make distclean of sage or the make distclean of pynormaliz?

[Sébastien Labbé]

This is to say that I was able to reproduce the issue on my laptop this time (also running Ubunbtu 16.04).

Am I the only one having trouble with :

    make pynormaliz

?

[Matthias Koeppe]

The error message ' configure: error: source directory already configured; run "make 

distclean" there first' seems to indicate that the wrong configure script is invoked for some reason. 

What is the content of $PATH?

What does 'sh --version' show?

[Vincent Delecroix]

Didn't you run 'sage -i pynormaliz'?

[Sébastien Labbé]

$ echo $PATH
/home/slabbe/GitBox/sage:/home/slabbe/GitBox/scripts:/home/slabbe/bin:/home/slabbe/Applications/bin:/home/slabbe/bin:/home/slabbe/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/opt/gurobi800/linux64/bin

$ sh --version

sh: 0: Illegal option --

 

sage -i pynormaliz gives the same error as make pynormaliz

[Vincent Delecroix]

$ which sh

[Sébastien Labbé]

On Saturday, May 25, 2019 at 6:18:43 PM UTC+2, vdelecroix wrote:

$ which sh

$ which sh
/bin/sh
$ sage -sh
(sage-sh) $ which sh
/bin/sh

[Vincent Delecroix]

On my machine `sh` points to `bash`. Could you try to activate
the Sage shell `sage -sh` go to the pynormaliz temporary build folder
and try

$ sh configure

(instead of $ ./configure that worked)

[Sébastien Labbé]

On Saturday, May 25, 2019 at 6:21:49 PM UTC+2, vdelecroix wrote:

On my machine `sh` points to `bash`. Could you try to activate
the Sage shell `sage -sh` go to the pynormaliz temporary build folder
and try

$ sh configure

(instead of $ ./configure that worked)

That recreates the problem:

$  cd /home/slabbe/GitBox/sage/local/var/tmp/sage/build/pynormaliz-2.5/src

$ sage -sh

(sage-sh)$ sh configure
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

[Vincent Delecroix]

The output is very weird as it seems that the wrong configure file
is actually run. From the direct invocation of ./configure, you see
that the output should start with
{{{

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 g++ -std=gnu++11 accepts -g... yes
checking whether g++ -std=gnu++11 supports C++11 features with
}}}

In particular there is nothing there about gawk or make...

1) Could you try

$ sh ./configure

2) Could you try to run `$ sh configure` in a folder where there is no
configure file at all. e.g you could move the configure file
somewhere else or/and run the command from `/tmp/`.

[Sébastien Labbé]

1) Could you try

$ sh ./configure

(sage-sh) $ sh ./configure

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 g++ -std=gnu++11 accepts -g... yes

checking whether g++ -std=gnu++11 supports C++11 features with -std=gnu++11... yes
configure: creating ./config.status
config.status: creating config.py

2) Could you try to run `$ sh configure` in a folder where there is no
configure file at all. e.g you could move the configure file
somewhere else or/and run the command from `/tmp/`.

(sage-sh) $ cd /tmp

(sage-sh) $ pwd

/tmp
(sage-sh) $ sh configure
sh: 0: Can't open configure

 

[Vincent Delecroix]

All right, we should go with solution 1 then. Could you modify the
setup.py line 63 with
{{{
- subprocess.check_call(["sh", "configure"], env = my_env )
- subprocess.check_call(["sh", "./configure"], env = my_env )
}}}
and try in the build folder (with sage env activated)

$ pip install .

(or pip3 if you use Sage with python3)

NOTE: The man page of sh is kind of ambiguous about what is done
when the name of the file does not contain a slash.

{{{
[...] If the pathname does not contain a <slash> character:

* The implementation shall attempt to read that file from the current
working directory; the file need not be executable.

[...]
}}}

Maybe it is the case that your sh actually does not follow the "shall"
above.

[Sébastien Labbé]

$ tar xvf PyNormaliz-2.5.tar.gz

$ cd PyNormaliz-2.5/

$ vim setup.py
$ sage -sh
(sage-sh) $ pip install .
Processing /home/slabbe/GitBox/sage/upstream/PyNormaliz-2.5
Installing collected packages: PyNormaliz
  Running setup.py install for PyNormaliz ... done
Successfully installed PyNormaliz-2.5

[Vincent Delecroix]

Great! I opened

https://github.com/Normaliz/PyNormaliz/issues/56

We should ask Sebastian Gutsche to release a new PyNormaliz
version including the patch.

Vincent

[Sébastien Labbé]

Maybe it is the case that your sh actually does not follow the "shall"
above.

 

It seems so.

When I do

$ sh --version
sh: 0: Illegal option --

which is weird since:

$ man sh

...

       --version
              Affiche le numéro de version de bash sur la sortie  standard  et
              termine avec succès.

...

[but it finishes with the version at the bottom:]

...

GNU Bash 4.3 

[Vincent Delecroix]

sh is not bash. Your man sh seems to show the bash documentation. The
real sh man page is for example available here

https://www.freebsd.org/cgi/man.cgi?query=sh

And there is no such option.

[Michael Orlitzky]

On 5/25/19 12:49 PM, Sébastien Labbé wrote:
>
> (sage-sh) $ cd /tmp
> (sage-sh) $ pwd
> /tmp
> (sage-sh) $ sh configure
> sh: 0: Can't open configure
>

This means that the "configure" file isn't coming from your PATH, which
is even more weird (where the hell is it coming from?).

First, can you find out where /bin/sh actually points? It should be a
symlink to the real shell executable (i.e. /bin/bash).

Finally, can you reproduce the problem under strace? I'm extremely
curious which "configure" file is being used. If you redirect the output
of strace to a log file, it will contain a mountain of extra stuff but
it should also contain the syscall that opens "configure".

[Sébastien Labbé]

On Tuesday, May 28, 2019 at 1:40:45 PM UTC+2, Michael Orlitzky wrote:

On 5/25/19 12:49 PM, Sébastien Labbé wrote:
>
> (sage-sh) $ cd /tmp
> (sage-sh) $ pwd
> /tmp
> (sage-sh) $ sh configure
> sh: 0: Can't open configure
>

This means that the "configure" file isn't coming from your PATH, which
is even more weird (where the hell is it coming from?).

I don't know, but the strace gives the answer, see below.

First, can you find out where /bin/sh actually points?

Sorry, I do not know how to answer this question. What command should I type?

 

It should be a
symlink to the real shell executable (i.e. /bin/bash).

Finally, can you reproduce the problem under strace?

Yes!

I'm extremely
curious which "configure" file is being used. If you redirect the output
of strace to a log file, it will contain a mountain of extra stuff but
it should also contain the syscall that opens "configure".

$ cd /home/slabbe/GitBox/sage/local/var/tmp/sage/build/pynormaliz-2.5/src

$ strace sh congiure

...

4000 lines in total including:

...
faccessat(AT_FDCWD, "/home/slabbe/GitBox/sage/configure", R_OK) = 0
stat("/home/slabbe/GitBox/sage/configure", {st_mode=S_IFREG|0775, st_size=398280, ...}) = 0
...

Therefore, it is using the configure from sage in fact. Indeed, the HOME directory of Sage is in my PATH.

And I can reproduce the issue like this:

$ cd /home/slabbe/GitBox/sage/local/var/tmp/sage/build/pynormaliz-2.5/src

$ sh /home/slabbe/GitBox/sage/configure

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
configure: error: source directory already configured; run "make distclean" there first

which should allow you to reproduce the above.

 

[Samuel Lelievre]

Tue 2019-05-28 23:09:33 UTC+2, Sébastien Labbé:

On Tuesday, May 28, 2019 at 1:40:45 PM UTC+2, Michael Orlitzky wrote:

First, can you find out where /bin/sh actually points?

Sorry, I do not know how to answer this question. What command should I type?

 

ls -halF /bin/sh

[Sébastien Labbé]

Here is what I get:

$ ls -halF /bin/sh
lrwxrwxrwx 1 root root 4 févr. 17  2016 /bin/sh -> dash*

 

[Dima Pasechnik]

dash is a bit of a problem. I am not sure whether currently it is
possible to build Sage with sh==dash
Perhaps modifying pynormaliz to actually use bash for building might
solve this.

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/9838331c-8b7d-476a-9656-891b525b16df%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Dima Pasechnik]

On Wed, May 29, 2019 at 10:16 AM Dima Pasechnik <dim...@gmail.com> wrote:
>
> dash is a bit of a problem. I am not sure whether currently it is
> possible to build Sage with sh==dash

hmm, scratch this. it works at least on Debian stable.

[Sébastien Labbé]

On Wednesday, May 29, 2019 at 10:17:08 AM UTC+2, Dima Pasechnik wrote:

dash is a bit of a problem. I am not sure whether currently it is
possible to build Sage with sh==dash

Well, I have been using this setup for more than 2 years now with no problem in compiling Sage hundreds of times.

Perhaps modifying pynormaliz to actually use bash for building might
solve this.

The solution was found by Vincent earlier, it is to do "sh ./configure" instead of "sh configure" which in my case uses the wrong configure file. So, no need to use bash it seems.

[Michael Orlitzky]

On 5/28/19 5:09 PM, Sébastien Labbé wrote:
>
> $ cd /home/slabbe/GitBox/sage/local/var/tmp/sage/build/pynormaliz-2.5/src
> $ strace sh congiure
> ...
> 4000 lines in total including:
> ...
> faccessat(AT_FDCWD, "/home/slabbe/GitBox/sage/configure", R_OK) = 0
> stat("/home/slabbe/GitBox/sage/configure", {st_mode=S_IFREG|0775,
> st_size=398280, ...}) = 0
> ...
>
> Therefore, it is using the configure from sage in fact. Indeed, the HOME
> directory of Sage is in my PATH.
>

Aha, I suspect that "sh" is the problem and not "configure". You have a
lot of stuff in your PATH that probably shouldn't be there; or at least,
should be in a different order:

PATH: /home/slabbe/GitBox/sage/local/libexec/ccache
PATH: /home/slabbe/GitBox/sage/build/bin
PATH: /home/slabbe/GitBox/sage/src/bin
PATH: /home/slabbe/GitBox/sage/local/bin
PATH: /home/slabbe/GitBox/sage/build/bin
PATH: /home/slabbe/GitBox/sage/src/bin
PATH: /home/slabbe/GitBox/sage/local/bin
PATH: /home/slabbe/GitBox/sage

...
PATH: /bin

I'm guessing that when you run "sh configure", it runs some other "sh"
from one of those Sage directories, and not /bin/sh. In particular if
Sage's copy of "sh" changes the current working directory to
"/home/slabbe/GitBox/sage", then the subsequent execution of "configure"
would produce exactly the problem you're seeing.

First, please verify this by changing setup.py to run "/bin/sh" rather
than simply "sh". If my guess is right, two things should be done:

* PyNormaliz should use "/bin/sh", to be on the safe side.

* You should probably reorder PATH on your system so that things
in Sage's bin directories don't override the ones in /bin.

[John H Palmieri]

Running "command -v sh" should tell you which "sh" is running, in case that helps.

[Michael Orlitzky]

On 5/30/19 12:06 AM, John H Palmieri wrote:
>
> I'm guessing that when you run "sh configure", it runs some other "sh"
> from one of those Sage directories, and not /bin/sh.
>
> Running "command -v sh" should tell you which "sh" is running, in case
> that helps.
>

Yeah, nevermind... this is a real stinker. I can now reproduce the
problem. It only happens when all of the following are true:

* The Sage root directory containing the wrong "configure" file
is in your $PATH.

* Dash is what you get when you run "sh".

* When Dash was compiled, the --disable-lineno option was passed to
its configure script.

Ironically, both Debian and Gentoo build Dash with that option to avoid
upstream build errors. Autoconf somehow detects the missing LINENO
support and re-execs itself with bash, and I guess that goes wrong
somehow in this case. Running "bash configure" will indeed search your
$PATH for a "configure" file if none is found in the current working
directory.

As yet unexplained is why manually running "bash configure" works, but
the autoconf bash re-exec does not. My own strace shows that running
"dash configure" will wind up running

execve("/bin/bash", ["/bin/bash", "/home/mjo/src/sage-8.8.beta6
/con"...], 0x55d1c04303f8 /* 68 vars */) = 0

instead of executing either "/bin/bash configure" in the CWD, or
"/bin/bash /path/to/pynormaliz's/configure".

[Michael Orlitzky]

On 5/30/19 12:33 AM, Michael Orlitzky wrote:
>
> As yet unexplained is why manually running "bash configure" works, but
> the autoconf bash re-exec does not. My own strace shows that running
> "dash configure" will wind up running
>
> execve("/bin/bash", ["/bin/bash", "/home/mjo/src/sage-8.8.beta6
> /con"...], 0x55d1c04303f8 /* 68 vars */) = 0
>
> instead of executing either "/bin/bash configure" in the CWD, or
> "/bin/bash /path/to/pynormaliz's/configure".
>

This is due to the "what script am I" detection built in to the
configure script by autoconf:

# Find who we are. Look in the path if we contain no directory
# separator.
as_myself=
case $0 in #((
*[\\/]* ) as_myself=$0 ;;
*) as_save_IFS=$IFS; IFS=$PATH_SEPARATOR
for as_dir in $PATH
do
IFS=$as_save_IFS
test -z "$as_dir" && as_dir=.
test -r "$as_dir/$0" && as_myself=$as_dir/$0 && break
done
IFS=$as_save_IFS

;;
esac

I'm going to ask about this on the autoconf mailing list, but for
pre-existing ./configure scripts, there's nothing we can do about it.
The best fix is probably what we've already decided: to make sure that
we run "./configure" instead of "sh configure".