Cannot build from source on CentOS

[christoph-conrads]

The following fragment from the configure file in Code_Saturne 6.0.5 does not work on CentOS (x86-64 ISA) because the program file is located at /bin/file instead of /usr/bin/file:

x86_64-*kfreebsd*-gnu|x86_64-*linux*|powerpc*-*linux*| \
s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
  # Find out what ABI is being produced by ac_compile, and set linker
  # options accordingly.  Note that the listed cases only cover the
  # situations where additional linker options are needed (such as when
  # doing 32-bit compilation for a host where ld defaults to 64-bit, or
  # vice versa); the common cases where no linker options are needed do
  # not appear in the list.
  echo 'int i;' > conftest.$ac_ext
  if { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_compile\""; } >&5
  (eval $ac_compile) 2>&5
  ac_status=$?
  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
  test $ac_status = 0; }; then
    case `/usr/bin/file conftest.o` in

CentOS 7 is the operating system for the supercomputer Eagle and its end of life is at the end of 2024. I think the problem occurs on all RedHat-based distributions (Fedora, CentOS Stream, and RedHat Enterprise Linux) but I did not verify this claim.

[YvanFournier]

This code is generated by autoconf, and not directly handled by code_saturne.

Did you use a downloaded .tar.gz, or did you rebuild the autoconf files using ./sbin/bootstrap ? At least some code_saturne 6.0 releases (6.0.3 if I remember correctly) have been build without issues on CentOS 7.

[christoph-conrads]

Did you use a downloaded .tar.gz, or did you rebuild the autoconf files using ./sbin/bootstrap ?

Spack uses GitHub tarballs and has to rebuild the autoconf files because there is no configure file in these tarballs. These generated configure files contain the incorrect file path mentioned above and compilation fails. I attached the Spack log because I am not familiar with autotools.

Building Code_Saturne 6.0.6 (SHA256 hash of tarball below) downloaded from the Code_Saturne website works on CentOS 7 (with and without Spack).

How do you want to proceed Yvan? As far as I am concerned, I will make Spack download the tarballs from code-saturne.org instead of GitHub.

SHA256: 86f9605d68c9ee7fd137c29980abbdd5d11c8731da623421ddbc2b69907f4f22 code_saturne-6.0.6.tar.gz

[christoph-conrads]

Error message for completeness:

make[3]: Entering directory `/home/john/code_saturne-6.0.6/src/mei'
depbase=`echo mei_evaluate.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ../../libtool  --tag=CC   --mode=compile /home/john/spack/lib/spack/env/gcc/gcc -DHAVE_CONFIG_H -I. -I../..  -I../../src/bft -I../../src/base -I/usr/include/mpi -D_POSIX_C_SOURCE=200809L -DNDEBUG   -funroll-loops -O2 -Wuninitialized -fexcess-precision=fast -std=c99 -fms-extensions -funsigned-char -pedantic -W -Wall -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Wunused -Wfloat-equal  -fopenmp -MT mei_evaluate.lo -MD -MP -MF $depbase.Tpo -c -o mei_evaluate.lo mei_evaluate.c &&\
mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  /home/john/spack/lib/spack/env/gcc/gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/bft -I../../src/base -I/usr/include/mpi -D_POSIX_C_SOURCE=200809L -DNDEBUG -funroll-loops -O2 -Wuninitialized -fexcess-precision=fast -std=c99 -fms-extensions -funsigned-char -pedantic -W -Wall -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Wunused -Wfloat-equal -fopenmp -MT mei_evaluate.lo -MD -MP -MF .deps/mei_evaluate.Tpo -c mei_evaluate.c  -fPIC -DPIC -o .libs/mei_evaluate.o
mei_evaluate.c:51:24: fatal error: mei_parser.h: No such file or directory
 #include "mei_parser.h"
                        ^
compilation terminated.

Error messages in log (thank you, Spack):

7 errors found in build log:
     60     checking for strip... strip
     61     checking for ranlib... ranlib
     62     checking command to parse /bin/nm -B output from /home/john/spack/lib/spack/env/gcc/gcc object... ok
     63     checking for sysroot... no
     64     checking for a working dd... /bin/dd
     65     checking how to truncate binary pipes... /bin/dd bs=4096 count=1
  >> 66     /home/john/code_saturne-6.0.6/configure: line 9101: /usr/bin/file: No such file or directory
     67     checking for mt... no
     68     checking if : is a manifest tool... no
     69     checking how to run the C preprocessor... /home/john/spack/lib/spack/env/gcc/gcc -E
     70     checking for ANSI C header files... yes
     71     checking for sys/types.h... yes
     72     checking for sys/stat.h... yes

     ...

     403    checking for strip... strip
     404    checking for ranlib... ranlib
     405    checking command to parse /bin/nm -B output from /home/john/spack/lib/spack/env/gcc/gcc object... ok
     406    checking for sysroot... no
     407    checking for a working dd... /bin/dd
     408    checking how to truncate binary pipes... /bin/dd bs=4096 count=1
  >> 409    ./configure: line 8116: /usr/bin/file: No such file or directory
     410    checking for mt... no
     411    checking if : is a manifest tool... no
     412    checking how to run the C preprocessor... /home/john/spack/lib/spack/env/gcc/gcc -E
     413    checking for ANSI C header files... yes
     414    checking for sys/types.h... yes
     415    checking for sys/stat.h... yes

     ...

     649    Making all in mei
     650    make[3]: Entering directory `/home/john/code_saturne-6.0.6/src/mei'
     651    depbase=`echo mei_evaluate.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
     652    /bin/sh ../../libtool  --tag=CC   --mode=compile /home/john/spack/lib/spack/env/gcc/gcc -DHAVE_CONFIG_H -I. -I../..  -I../.
            ./src/bft -I../../src/base -I/usr/include/mpi -D_POSIX_C_SOURCE=200809L -DNDEBUG   -funroll-loops -O2 -Wuninitialized -fexc
            ess-precision=fast -std=c99 -fms-extensions -funsigned-char -pedantic -W -Wall -Wshadow -Wpointer-arith -Wcast-qual -Wcast-
            align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Wunused -Wfloat-equ
            al  -fopenmp -MT mei_evaluate.lo -MD -MP -MF $depbase.Tpo -c -o mei_evaluate.lo mei_evaluate.c &&\
     653    mv -f $depbase.Tpo $depbase.Plo
     654    libtool: compile:  /home/john/spack/lib/spack/env/gcc/gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/bft -I../../src/base -I/u
            sr/include/mpi -D_POSIX_C_SOURCE=200809L -DNDEBUG -funroll-loops -O2 -Wuninitialized -fexcess-precision=fast -std=c99 -fms-
            extensions -funsigned-char -pedantic -W -Wall -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wstrict-pr
            ototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Wunused -Wfloat-equal -fopenmp -MT mei_evaluate.lo -
            MD -MP -MF .deps/mei_evaluate.Tpo -c mei_evaluate.c  -fPIC -DPIC -o .libs/mei_evaluate.o
  >> 655    mei_evaluate.c:51:24: fatal error: mei_parser.h: No such file or directory
     656     #include "mei_parser.h"
     657                            ^
     658    compilation terminated.
  >> 659    make[3]: *** [mei_evaluate.lo] Error 1
     660    make[3]: Leaving directory `/home/john/code_saturne-6.0.6/src/mei'
  >> 661    make[2]: *** [all-recursive] Error 1
     662    make[2]: Leaving directory `/home/john/code_saturne-6.0.6/src'
  >> 663    make[1]: *** [all-recursive] Error 1
     664    make[1]: Leaving directory `/home/john/code_saturne-6.0.6'
  >> 665    make: *** [all] Error 2

[YvanFournier]

Hello,

Is this based on a download from code_saturne.org temporarily down tonight), or from a GitHub download ? If using a GitHub download, ./sbin/boostrap generates mei_parser.h, but requires Bison and Flex to be installed to do so. This file should be present in the complete tarball.

Note that starting with code_saturne 6.1, MEI has been replaced by another subsystem, with no more Bison/Flex dependencies.

[YvanFournier]

I suspect I understand what is going on from the Spack log, assuming you used the GitHub version: Spack tries to run autoreconf as it recognizes that a configure.ac is present but not configure, but does not run additional steps.

With code_saturne, to ensure everything is ready, the actual, documented solution is to run ./sbin/bootstrap in the top source directory. This also handles configure in subdirectories (libple), while I am not sure autoreconf can do this.

If you can add a Spack rule telling it to run ./sbin/bootstrap in the newly downloaded directory, that should solve this sort of issue.

[christoph-conrads]

Hi Yvan,

I suspect I understand what is going on from the Spack log, assuming you used the GitHub version

Yes.

With code_saturne, to ensure everything is ready, the actual, documented solution is to run ./sbin/bootstrap in the top source directory. This also handles configure in subdirectories (libple), while I am not sure autoreconf can do this.

I will try this when I find some time.

[christoph-conrads]

If you can add a Spack rule telling it to run ./sbin/bootstrap in the newly downloaded directory, that should solve this sort of issue.

The configure script finishes successfully but there are two messages related /usr/bin/file on stderr:

/home/john/code_saturne-6.0.6/configure: line 9101: /usr/bin/file: No such file or directory

The attachments contain config.log and a log of the stderr output. config.log cs-6.0.6-configure.stderr.log

Spack can be made to call ./sbin/bootstrap by overriding the method autoreconf (untested):

import subprocess
class CodeSaturne(AutotoolsPackage):
    # ...
    depends_on("bison", when="@:6.0.999")
    depends_on("flex", when="@:6.0.999")

    def autoreconf(self, spec, prefix):
        subprocess.run("./sbin/bootstrap", check=True)

[YvanFournier]

Hello,

/usr/bin/file seems to be included in thr libtool.m4 and ltmain.sh files, which are both added/generated by the GNU autotools, especially libtool.

One of Libtool's main selling point is that it should help ensure portability across various systems... which seems to be a massive failure here.

I'm not sure which package should provide /usr/bin/file, but I have not had this issue on any of the systems I tested so far.

In any case, this issue should not seem limited to Spack, unless the Spack build is in a special virtual environment. Does the file exit in your main CentOS environment ? Do you have the access rights to package managment and the possibility of installing this file ? Or declaring it as a dependency for Spack ?

Best regards,

Yvan

[christoph-conrads]

Hi Yvan,

to exclude Spack problems, I rebuilt Code_Saturne without Spack in a brand new CentOS 7 container. The problem persisted because there is file command by default. If file is installed in /bin/file, the autotools find it.

I am sorry for the trouble but I was using Linux containers all the time and the images are very minimal. I absolutely expected file to be preinstalled.