Fpm from source on CentOS 7

I am attempting to build fpm from single source in a CentOS 7 installation using the devtoolset-10 build of gfortran (version 10.2.1–11). I am following the instructions posted at Installing fpm — Fortran Package Manager verbatim. To be specific I am execute the following commands for steps 1 & 2:

wget https://github.com/fortran-lang/fpm/releases/download/current/fpm.F90
mkdir -p build/bootstrap
gfortran -J build/bootstrap -o build/bootstrap/fpm fpm.F90

However, when I attempt to execute step 3 with the command

./build/bootstrap/fpm install

I encounter the error

<ERROR>'fpm.toml' could not be found, check if the file exists
STOP 1

Clearly this file does not exist. Can anyone offer information as to:

  1. where I would obtain the appropraite fpm.toml file for the single source version?
  2. Once I have managed to workaround this issue, how should I suggest a correction to the posted instructions so that others do not encounter this same issue?

The build/boostrap/fpm executable you have created is perfectly valid to use as is. You can just put it somewhere in your path and be done if you like. However, it doesn’t take advantage of some of the C-interop stuff to improve performance.

Each of the commands in that guide should be executed from the root folder of a clone of the fpm repository.

1 Like

Thank you for the reply (which is much appreciated!) I had already tried what you suggested. I first cloned the repo, then downloaded the single source (fpm.F90) version and
then issued the commands I have previously mentioned. However, the

./build/bootstrap/fpm install

command still fails with the error message:

Initialized empty Git repository in /home/myusername/codes/fpm/build/dependencies/toml-f/.git/
Unknown option: -C
usage: git [--version] [--help] [-c name=value]
           [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
           [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
           <command> [<args>]
<ERROR>Error while fetching git repository for remote dependency
STOP 1

I thought the installation from single source would work but it is not so.
Thus far none of the methods, as outlined on Installing fpm — Fortran Package Manager for building from source have worked and I working with a fairly generic Linux installation. Also building from the cloned repo according to the suggested commands:

git clone https://github.com/fortran-lang/fpm
cd fpm
./install.sh

also fails in the install script with the error message:

Initialized empty Git repository in /home/myusername/codes/fpm/build/dependencies/toml-f/.git/
Unknown option: -C
usage: git [--version] [--help] [-c name=value]
           [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
           [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
           <command> [<args>]
<ERROR>Error while fetching git repository for remote dependency
STOP 1

It is a bit of a barrier to get new users to adopt a technology when posted instructions don’t work on a a fairly generic installation (yes I know for I can install binaries or work with pip or anaconda but there are other reasons why I don’t want to do so in this instance). Any further suggestions on how I can get an installation from source to go to completion?

That error message is coming from git. It appears your installation of git is too old and doesn’t support the -C option used by fpm. Would it possible to upgrade your version of git?

1 Like

Thanks for the reply! Unfortunately I am on the latest version of git (1.8.3.1) currently available through offical CentOS repos for CentOS 7.

Try and download Miniconda, create a venv, install git from conda-forge. That should circumvent any issues you are facing

1 Like

Thanks for your reply! But as I stated in my previous post there are reasons (that I won’t go into detail about) that I need to avoid Anaconda/Miniconda installations. I am aware those will work. I am trying to get the install from source working and to document how to do it so that other can do so as well.

1 Like

You won’t be working per se with miniconda, you will just use it for installation. Once fpm is installed you can completely remove miniconda. From what I’ve read on this thread the problem is your git version, which is bound to be updated in CentOS main repo at some point or another

1 Like

Thanks for reaching out @paprof and I completely agree, we definitely want fpm to be easily accessible by as many people as possible. As Brad has pointed-out, we haven’t quite catered for such an old version of git in our development.

A possible solution you could try is to patch the single-source version after you have downloaded it with the following changes:

12821c12821,12822
<         call execute_command_line("git -C "//local_path//" fetch --depth=1 "// &
---
>         call execute_command_line("git --work-tree="//local_path//" --git-dir="//local_path// &
>                                   "/.git fetch --depth=1 "// &
12829c12830,12831
<         call execute_command_line("git -C "//local_path//" checkout -qf FETCH_HEAD", exitstat=stat)
---
>         call execute_command_line("git --work-tree="//local_path//" --git-dir="//local_path// &
>                                    "/.git checkout -qf FETCH_HEAD", exitstat=stat)
12855c12857
<         line = "git -C "//local_path//" log -n 1 > "//temp_file
---
>         line = "git --work-tree="//local_path//" --git-dir="//local_path//"/.git log -n 1 > "//temp_file

(This replaces the -C option with --work-tree and --git-dir instead.)

2 Likes

I’ve always been very frustrated by distros that don’t install versions of things less than 10 years old. Note that CentOS 7 was first released in 2014, so that distro itself is already quite old. Note that you won’t be able to use fpm until you have a version of git new enough to accept the -C argument, as fpm uses it for all of its operations related to fetching dependencies.

2 Likes

Thanks for the report, this is an issue we have seen now multiple times. When I decided for using -C it seems like most distros package a new enough git, however this is obviously not true for all distros. But we can fix this in fpm:

You can get a fixed version from Release Bleeding edge version · fortran-lang/fpm · GitHub.

2 Likes

Yes I understand this and user miniconda for many other installations. But for reasons I I don’t want to go into here it is not an option for me on this particular system. I realize that CentOS 7 is “old” but with recent changes to CentOS made by Red Hat CentOS 8 is not enterprise grade and many production systems are only slowly moving over to Rocky 8/9 which would offer more up-to-date versions of software.

Thanks to everyone for the patience and the helpful replies! The systems I am dealing with require an enterprise grade OS because of security concerns and a presently-installed complex software ecosystem that does not easily migrate to a newer more bleeding edge (e.g. Fedora/Ubuntu) Linux distro. The long-term plan is to migrate to Rocky 8/9 but that is many more months of functionality testing away. Enterprise grade Linux distributions are more conservative for a good reason and Red Hat has a valuable market share because of that need for security & long-term stability. One can criticize RHEL/CentOS for being less than bleeding edge (still using Python 2, version 4.x kernels, & older git) but enterprises with complicated software ecosystems require that level of stability manage risk. That requirement does not matter quite so much to a single-user Linux installation who can more easily upograde to the latest distro.
Conda-based installations for system-wide software installations are not possible in the situation that I am dealing with without additional risks (conda presents a much larger larger attack surface to bad actors). Installation of pre-built binaries from non-trusted sources/repos are out of the question for the same reason. I realize that this is a bit paranoid. But I am paid to be professionally paranoid in order to mitigate risk.
I’ll be looking to see if I can patch the single-source fpm version as suggested or find a way to get a secure later version of git installed on our current systems. Thank you all so much for all the supportive comments!

1 Like

Well I happen to encounter today the very same issue: I need to install on a HPC server a package that provides only a fpm.toml as its build system[1], and the only viable way appears to be building it from source, since:

  • I do not manage the HPC cluster, I’m just a regular user
  • I have no sudo rights, as a regular user
  • I do not have access to conda or similar there
  • I cannot install homebrew (which would have been the perfect move for the non-sudoer) since the provided version of curl is too old for homebrew to support

So many many thanks to @awvwgk for the blazing fast take of action, you probably save me from going through the hassle of writing a CMake build for the project!


  1. that’s because I have written it from scratch and wanted it to be an fpm-only library… ↩︎