slatec @4.1: f77: No such file or directory

[ryandesign (Ryan Carsten Schmidt)]

​https://build.macports.org/builders/ports-10.12_x86_64-builder/builds/70970/steps/install-port/logs/stdio

--->  Building slatec
DEBUG: Executing org.macports.build (slatec)
DEBUG: Environment: 
CC_PRINT_OPTIONS='YES'
CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_science_slatec/slatec/work/.CC_PRINT_OPTIONS'
CPATH='/opt/local/include'
LIBRARY_PATH='/opt/local/lib'
MACOSX_DEPLOYMENT_TARGET='10.12'
Executing:  cd "/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_science_slatec/slatec/work/src" && /usr/bin/make -j8 -w libslatec.a 
DEBUG: system:  cd "/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_science_slatec/slatec/work/src" && /usr/bin/make -j8 -w libslatec.a 
make: Entering directory `/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_science_slatec/slatec/work/src'
cd static; make
make[1]: Entering directory `/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_science_slatec/slatec/work/src/static'
f77 -O2 -c -o aaaaaa.o ../aaaaaa.f
make[1]: f77: No such file or directory
f77 -O2 -c -o cnbdi.o ../cnbdi.f
make[1]: f77: No such file or directory
f77 -O2 -c -o dcv.o ../dcv.f
make[1]: f77: No such file or directory
make[1]: *** [aaaaaa.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: *** [cnbdi.o] Error 1
make[1]: *** [dcv.o] Error 1
make[1]: Leaving directory `/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_science_slatec/slatec/work/src/static'
make: *** [libslatec.a] Error 2

[smaret (Sebastien Maret)]

I can't reproduce this on 10.14. I don't have access to a computer with 10.12 installed so I can't really help here. Sorry...

[ryandesign (Ryan Carsten Schmidt)]

The issue is not OS-version-specific. To reproduce, run sudo port fetch slatec && sudo port build slatec. The build.args that set FC need to be set outside of the fetch phase.

[Sebastien Maret <sebastien.maret@…>]

In 4bd212da32575d5a44130fe1b11e22aabf0232e7/macports-ports (master):

slatec: fix build

Closes #57365.

[majoc-at-astro (majoc-at-astro)]

Reopened: the build now succeeds, but libslatec.a contains only the string !<arch> and a newline, whether built from source or installed prebuilt. This makes it a tad difficult to link against, eg (from port install gildas):

:info:build ld: file too small (length=8) file '/opt/local/lib/libslatec.a' for architecture x86_64
:info:build collect2: error: ld returned 1 exit status

This is happening for our 10.12 and 10.13 nightly builds (we've yet to stand up a 10.14 builder). Our builds don't do port select gcc mp-gcc8, but doing so before a test source build of slatec doesn't fix the problem.

Please find enclosed the log for port -v -s install slatec, of which this seems to be the top bit:

--->  Building slatec
Executing:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rs
ync.macports.org_macports_release_tarballs_ports_science_slatec/slatec/work/src"
 && /usr/bin/make -j8 -w libslatec.a FC= 
make: Entering directory `/opt/local/var/macports/build/_opt_local_var_macports_
sources_rsync.macports.org_macports_release_tarballs_ports_science_slatec/slatec
/work/src'
cd static; make
make[1]: Entering directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_science_slatec/slatec/work/src/static'
O2 -c -o aaaaaa.o ../aaaaaa.f
make[1]: O2: No such file or directory

Please let me know if there's anything else you wish me to try.

[majoc-at-astro (majoc-at-astro)]

For completeness, here's work/src/static/makefile as patched, which seems to not define ${FC}. Should I be looking somewhere else .... ?

[ryandesign (Ryan Carsten Schmidt)]

This port uses the compilers portgroup, which I have never understood very well, so it is difficult for me to know in advance what will work and what will not. Now that I look at it closer, I understand that the compilers portgroup creates variants for you to choose what compiler to use, and the code that chooses that compiler is in each variant. Variants get evaluated after the main part of the portfile has been evaluated, which is why adding FC=${configure.fc} to build.args in the main part of the portfile doesn't work right, because configure.fc hasn't been set by that point. But appending to build.args in a pre-fetch block wasn't right either, since the fetch phase doesn't need that information; the build phase does. So it should be done in a pre-build block.

Unfortunately this port's build system evidently doesn't know to exit when an error occurs. It would be nice if we could fix that. But since this problem exists, we now have broken archives published on our packages server, and installed on some user systems, so when the above is fixed, the revision will need to be increased.

I had filed similar tickets for other ports; maybe those ports have the same problems, so they should be checked as well.

[majoc-at-astro (majoc-at-astro)]

Replying to ryandesign:

Unfortunately this port's build system evidently doesn't know to exit when an error occurs. It would be nice if we could fix that.

This I think is the most entertaining part of this: ${FC} -O other_args -> -O other_args -> O other_args plus an instruction to Make to ignore the error-exit value. It's actually two features of Make interacting to produce a bug, for which the only portable fix afaict is "don't do that". With gmake, I've used startup-time traps before now of the form:

ifeq "" "${FC}"
 $(error I see an empty FC value here)
endif

.... which isn't entirely complete (checking for ${FC} being all-whitespace is left as an exercise), and would have to be replicated for all other interesting variables. I've no idea what the BSD-make version would be; and, erm, is there a cmake expert in the house?

Hope this helps.

[smaret (Sebastien Maret)]

Replying to ryandesign:

This port uses the compilers portgroup, which I have never understood very well, so it is difficult for me to know in advance what will work and what will not. Now that I look at it closer, I understand that the compilers portgroup creates variants for you to choose what compiler to use, and the code that chooses that compiler is in each variant. Variants get evaluated after the main part of the portfile has been evaluated, which is why adding FC=${configure.fc} to build.args in the main part of the portfile doesn't work right, because configure.fc hasn't been set by that point. But appending to build.args in a pre-fetch block wasn't right either, since the fetch phase doesn't need that information; the build phase does. So it should be done in a pre-build block.

Thanks for looking into this. I've tried to set FC in a pre-build block (with an export) but it didn't work either. The only solution I could come up with is the following:

build {
    system -W ${worksrcpath}  "${build.cmd} -j${build.jobs} FC=${configure.fc} ${build.target}"
}

Not very elegant, but it works.

[smaret (Sebastien Maret)]

Just opened a PR for it. Feedback welcome. ​https://github.com/macports/macports-ports/pull/2827

[ryandesign (Ryan Carsten Schmidt)]

Replying to smaret:

I've tried to set FC in a pre-build block (with an export) but it didn't work either.

It worked for me:

--- Portfile	(revision 151828)
+++ Portfile	(working copy)
@@ -31,8 +31,10 @@
 
 compilers.choose    fc f77 f90
 compilers.setup     require_fortran
-	
-build.args-append   FC=${configure.fc}
+
+pre-build {
+    build.args-append   FC=${configure.fc}
+}
 build.target        libslatec.a
 
 destroot {

Are you sure this doesn't work for you?

[smaret (Sebastien Maret)]

Indeed, it works. Not sure what happened the first time I tried. I've updated the PR.

[Sebastien Maret <sebastien.maret@…>]

In 2e9192c89f2a7d4280efce09564f47331c48c0cf/macports-ports (master):

slatec: set the fortran compiler properly

Setting the Fortran compiler with FC=${configure.fc} in
build.args-append results in an empty FC variable. Oddly, the build
with an empty FC does not fail, but the libslatec.a it produces is
broken. Fix this by setting the build.args-append within a pre-build
block, and increase the revision number to force the rebuild of broken
slatec installations.

Closes #57365