Make error in prms/prms/

[ashalper-usgs]

On the 5.0.0_rc branch, on CentOS 7, make is ending in this error:

gfortran -O --static -o ./prms call_modules.o basin.o climateflow.o cascade.o soltab.o setup_param.o convert_params.o prms_time.o obs.o climate_hru.o potet_jh.o potet_pt.o potet_hs.o potet_pm.o potet_pm_sta.o potet_pan.o potet_hamon.o ddsolrad.o ccsolrad.o ide_dist.o xyz_dist.o precip_1sta_laps.o precip_dist2.o temp_1sta_laps.o temp_dist2.o transp_frost.o transp_tindex.o frost_date.o intcp.o snowcomp.o srunoff.o soilzone.o gwflow.o water_use_read.o dynamic_param_read.o water_balance.o routing.o strmflow.o strmflow_in_out.o muskingum.o muskingum_lake.o subbasin.o map_results.o nhru_summary.o nsub_summary.o nsegment_summary.o basin_summary.o write_climate_hru.o prms_summary.o basin_sum.o utils_prms.o ../mmf/libmmf.a -lgfortran -lgcc -lm
/usr/bin/ld: cannot find -lgfortran
/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lgfortran
/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lgfortran
/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lquadmath
/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
make[1]: *** [prms] Error 1
make[1]: Leaving directory `/usr/local/src/prms/prms'
make: *** [standard] Error 2

I think there might be a problem with GFortran and the linker flags (-lgfortran -lgcc -lm) at the end of the command.

[rsregan]

I think we need to figure out what version of gfortran we want to use. There are several on Yeti, I have several on my linux boxes. There are a bunch of version 4 gfortran's, then there are versions 5, 6, 7, 8, and 9. Version 9 is the development version, the 9 standing for 2019. I have version 4.8.5 on my new linux box. I use version 7.2.0 on Yeti. Last I checked, Yeti has gcc/gfortran 4.9.3, 5.3, 6.1, and 7.1.0.

Ideally, I would like to switch to use an Intel compiler, they produce executables that run more than twice as fast on tests I've run with GSFLOW and PRMS.

On Thu, May 16, 2019 at 11:09 AM Andrew Halper notifications@github.com wrote:

On the 5.0.0_rc branch, on CentOS 7, make is ending in this error:

gfortran -O --static -o ./prms call_modules.o basin.o climateflow.o cascade.o soltab.o setup_param.o convert_params.o prms_time.o obs.o climate_hru.o potet_jh.o potet_pt.o potet_hs.o potet_pm.o potet_pm_sta.o potet_pan.o potet_hamon.o ddsolrad.o ccsolrad.o ide_dist.o xyz_dist.o precip_1sta_laps.o precip_dist2.o temp_1sta_laps.o temp_dist2.o transp_frost.o transp_tindex.o frost_date.o intcp.o snowcomp.o srunoff.o soilzone.o gwflow.o water_use_read.o dynamic_param_read.o water_balance.o routing.o strmflow.o strmflow_in_out.o muskingum.o muskingum_lake.o subbasin.o map_results.o nhru_summary.o nsub_summary.o nsegment_summary.o basin_summary.o write_climate_hru.o prms_summary.o basin_sum.o utils_prms.o ../mmf/libmmf.a -lgfortran -lgcc -lm /usr/bin/ld: cannot find -lgfortran /usr/bin/ld: cannot find -lm /usr/bin/ld: cannot find -lgfortran /usr/bin/ld: cannot find -lm /usr/bin/ld: cannot find -lgfortran /usr/bin/ld: cannot find -lm /usr/bin/ld: cannot find -lquadmath /usr/bin/ld: cannot find -lm /usr/bin/ld: cannot find -lc collect2: error: ld returned 1 exit status make[1]: [prms] Error 1 make[1]: Leaving directory `/usr/local/src/prms/prms' make: [standard] Error 2

I think there might be a problem with GFortran and the linker flags (-lgfortran -lgcc -lm) at the end of the command.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/nhm-usgs/prms/issues/1?email_source=notifications&email_token=ACLN2FM2N4EFDTN3IO4R7PTPVWIKRA5CNFSM4HNOQ4X2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GUHF7SQ, or mute the thread https://github.com/notifications/unsubscribe-auth/ACLN2FLX2P5KENVF2KOJMITPVWIKRANCNFSM4HNOQ4XQ .

-- R. Steve Regan USGS Water Mission Area (WMA) Integrated Modeling and Prediction Division (IMPD) Earth Systems Modeling Branch (ESMD) 303-236-5008 (office) PO Box 25046, MS 413 Bldg 53 Denver Federal Center Lakewood, CO 80225-0046 success is rarely about finding the right solution to a problem — it’s more about finding the right problem to solve

[markstro-usgs]

I think that the problem is that the gcc installation does not include the static libraries. The --static flag is causing it to look for the .so versions of the libraries.

[ashalper-usgs]

OK, that's fine. From my perspective though, I'd prefer the Make to be as compiler "agnostic" as possible (i.e., if you want to use a specific compiler/version, that's fine; but I don't want to be compelled to use the same one).

That's probably something for me to write with GNU Autotools on an unstable branch, however. On this branch, it's OK to require a specific compiler/version, and I'll leave that decision up to you. Pick one, and I'm happy to help integrate it on this branch.

[markstro-usgs]

If we are going to make in the container, then set the flags according to the compiler and libraries that we are going to have available in the container. If we are going to include a precompiled executable in the container, then we should link statically, because we don't know (and dont want to depend on) whatever dynamic libraries happen to be available when the image is instantiated.

[ashalper-usgs]

If you want to statically link for that or any other reason, that's fine with me. Be aware that dynamic linking is fine too, as the dependency graph can be implemented by libtool and/or the package management system (both of which are outside the scope of containerization).

[markstro-usgs]

OK, that's good.

Do we (anyone) have an opinion about whether it is better to pull the code and recompile every time the container is instantiated from the image, or is it better to include a compiled executable when we build the image?

If we do the later, then I think it is better to link to static libraries.

[ashalper-usgs]

It's mostly context sensitive. In a development environment, where there are going to be modifications of the source on a frequent basis, it's better (some might say "essential") to build/install from source.

In a testing environment, it depends much more on the testing and configuration management processes. In a production environment, it's more common to use pre-built binaries (but building from source is not unheard of).

[ashalper-usgs]

If you're used to static linking, by all means, keep doing that. I just wanted to be clear that dynamic linking is an option (one that is neither "better" nor "worse"), and that the decision to link statically or dynamically need not be related to containerization.

[rsregan]

I think for the operational version, the code should be static, thus one approved exe that is based on an approved release.

I think it should be pulled, compiled, and tested anytime there is a commit to any branch.

On Thu, May 16, 2019 at 12:15 PM Steve Markstrom notifications@github.com wrote:

OK, that's good.

Do we (anyone) have an opinion about whether it is better to pull the code and recompile every time the container is instantiated from the image, or is it better to include a compiled executable when we build the image?

If we do the later, then I think it is better to link to static libraries.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/nhm-usgs/prms/issues/1?email_source=notifications&email_token=ACLN2FKXNT2E2J6J56ZF56LPVWQEDA5CNFSM4HNOQ4X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVSUM2A#issuecomment-493176424, or mute the thread https://github.com/notifications/unsubscribe-auth/ACLN2FPBQTKIKOJAC3T7W5DPVWQEDANCNFSM4HNOQ4XQ .

-- R. Steve Regan USGS Water Mission Area (WMA) Integrated Modeling and Prediction Division (IMPD) Earth Systems Modeling Branch (ESMD) 303-236-5008 (office) PO Box 25046, MS 413 Bldg 53 Denver Federal Center Lakewood, CO 80225-0046 success is rarely about finding the right solution to a problem — it’s more about finding the right problem to solve

[ashalper-usgs]

Very good.

@rsregan , to close this issue, could you update the Make system on 5.0.0_rc to compile with GFortran (and any other Fortran compilers you want), and I'll make it a non-issue on a 5.1.0 branch?

[rsregan]

Hmm, The Makefile and makelist that I will use to make the PRMS 5.0.0 Linux release will use ifort and icc (Intel) with some comments about switching to gfortran. What I'm reading into this, is that I should push those to the 5.0.0_rc branch as they will be included with the Linux distribution, correct?

On Thu, May 16, 2019 at 2:15 PM Andrew Halper notifications@github.com wrote:

Very good.

@rsregan https://github.com/rsregan , to close this issue, could you update the Make system on 5.0.0_rc to compile with GFortran (and any other Fortran compilers you want), and I'll make it a non-issue on a 5.1.0 branch?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nhm-usgs/prms/issues/1?email_source=notifications&email_token=ACLN2FORMMU7R2UZCBJWZNLPVW6F3A5CNFSM4HNOQ4X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVS6BUI#issuecomment-493215953, or mute the thread https://github.com/notifications/unsubscribe-auth/ACLN2FNY5C4P7QG4JYAWCC3PVW6F3ANCNFSM4HNOQ4XQ .

-- R. Steve Regan USGS Water Mission Area (WMA) Integrated Modeling and Prediction Division (IMPD) Earth Systems Modeling Branch (ESMD) 303-236-5008 (office) PO Box 25046, MS 413 Bldg 53 Denver Federal Center Lakewood, CO 80225-0046 success is rarely about finding the right solution to a problem — it’s more about finding the right problem to solve

[rsregan]

Note, for the Windows release zip file, the Makefiles are included, though they are not used. I use a Visual Studio solution to make the executable, but, have not included the VS solution/project files in any other release. Traditionally, we have included Makefiles with a statement that no support is provided for user's to build their own exe in a readme file.

On Thu, May 16, 2019 at 2:15 PM Andrew Halper notifications@github.com wrote:

Very good.

@rsregan https://github.com/rsregan , to close this issue, could you update the Make system on 5.0.0_rc to compile with GFortran (and any other Fortran compilers you want), and I'll make it a non-issue on a 5.1.0 branch?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nhm-usgs/prms/issues/1?email_source=notifications&email_token=ACLN2FORMMU7R2UZCBJWZNLPVW6F3A5CNFSM4HNOQ4X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVS6BUI#issuecomment-493215953, or mute the thread https://github.com/notifications/unsubscribe-auth/ACLN2FNY5C4P7QG4JYAWCC3PVW6F3ANCNFSM4HNOQ4XQ .

-- R. Steve Regan USGS Water Mission Area (WMA) Integrated Modeling and Prediction Division (IMPD) Earth Systems Modeling Branch (ESMD) 303-236-5008 (office) PO Box 25046, MS 413 Bldg 53 Denver Federal Center Lakewood, CO 80225-0046 success is rarely about finding the right solution to a problem — it’s more about finding the right problem to solve

[ashalper-usgs]

I'm pretty certain we can't redistribute the Intel compilers due to license constraints. So any Makefiles can be compatible with commercial compilers (and I would encourage you to write them that way, though there are easier ways of doing it), but we can't bundle them with any of our software. If someone wants to use them to compile our software, they would need to install them from the 3rd party owner.

[ashalper-usgs]

You would need to check the Visual Studio license to be sure, but I would expect it's OK to distribute VS project files with the source. [In fact I vaguely recall I have seen precedent for this in the past.]

[rsregan]

I didn't mean to imply distributing the Intel compilers. I just build an exe that I use an Intel compiler and link statically so that user's don't need anything. We include Makefile's as an example for user's to use if they so desire with no guarantee that they can get them to work or support to help them get them to work.

Here's a statement from the GSFLOW release candidate readme file. We tell them how an exe is made, (windows in this case). I have to modify the readme for the Linux release as I've switched to compiling on Yeti with the Intel compiler.

                  GSFLOW - Version: 2.0.0
      Coupled Groundwater and Surface-water FLOW model

NOTE: Any use of trade, product or firm names is for descriptive purposes only and does not imply endorsement by the U.S. Government.

GSFLOW version 2.0.0 is packaged for personal computers using one of the Microsoft Windows operating systems. An executable file compiled for 64-bit operating systems is provided. The executable was compiled on a personal computer with the Intel(R) Xeon(R) CPU E3-1545M v5 Processor, running the Microsoft Windows 10 Enterprise, Version 1803, 64-bit operating system, using the Microsoft Visual Studio 2015 Version 14.0.25425.01 Update 3, development environment and the Intel® Parallel Studio XE 2017 Update 7 Composer Edition for Fortran Windows Integration for Microsoft Visual Studio 2015, Version 17.0.0053.14 and Intel® Parallel Studio XE 2017 Update 2 Composer Edition for C++ Windows Integration for Microsoft Visual Studio 2015, Version 17.0.72.14 compilers.

The source code and Linux Makefiles are provided to aid users in compilation on other computers. However, no support is provided for compilation.

**** Also, at the bottom of the save readme file we include this section. I just noticed this is incorrect as currently I am using an Intel Fortran compiler and the C++ compiler provided with Visual Studio.

E. COMPILING

The executable file provided in GSFLOW_2.0.0\bin was created using the Intel Visual Fortran and C++ compilers. Although executable versions of the program are provided, the source code also is provided in the GSFLOW_2.0.0\src directory so that GSFLOW can be recompiled if necessary. However, the USGS cannot provide assistance to those compiling GSFLOW. In general, the requirements are a Fortran compiler, a compatible C compiler, and the knowledge of using the compilers. Makefiles are included in the GSFLOW_2.0.0\src directories as an example for compiling GSFLOW.

On Thu, May 16, 2019 at 2:35 PM Andrew Halper notifications@github.com wrote:

I'm pretty certain we can't redistribute the Intel compilers due to license constraints. So any Makefiles can be compatible with commercial compilers (and I would encourage you to write them that way, though there are easier ways of doing it), but we can't bundle them with any of our software. If someone wants to use them to compile our software, they would need to install them from the 3rd party.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nhm-usgs/prms/issues/1?email_source=notifications&email_token=ACLN2FPXDEV5T6Z6T2FGI7DPVXAQ7A5CNFSM4HNOQ4X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVS7T7I#issuecomment-493222397, or mute the thread https://github.com/notifications/unsubscribe-auth/ACLN2FNLC4QWJ6JHTID7OVLPVXAQ7ANCNFSM4HNOQ4XQ .

-- R. Steve Regan USGS Water Mission Area (WMA) Integrated Modeling and Prediction Division (IMPD) Earth Systems Modeling Branch (ESMD) 303-236-5008 (office) PO Box 25046, MS 413 Bldg 53 Denver Federal Center Lakewood, CO 80225-0046 success is rarely about finding the right solution to a problem — it’s more about finding the right problem to solve

[ashalper-usgs]

Yes, that's fine. On Unix/Linux/POSIX, the binary executable is typically distributed in a package, which would not normally include Makefiles, although sometimes there are related "devel" packages that contain API prerequisites, such as C header files.

[markstro-usgs]

Remember that each of you (Andy and Steve R) are building for different purposes. Regan and I build (have built) to make the zipped up distribution that people download and install on their machines. Andy is building for the inside of a completely controlled environment container. Maybe it's the same thing and maybe it's not.

In my opinion, it's not worth trying to use a compiler or libraries that are not gnu when we are creating the docker image. Performance (ie runtimes) do not justify using proprietary libraries in our docker images. And unless we can build statically with the intel compiler, it is not justified to use in our standard distribution method either. Just my $.02

[ashalper-usgs]

They are fairly different things, which is part of the reasoning for the "agnosticism". With a little bit of forethought about "this code may be compiled by more than one method", it's relatively easy for the two (or more) build systems to co-exist without interference. I don't have a favorite compiler. My goal is to have it work with $CC and $FC, and have the details "hidden" by the Make system.

[markstro-usgs]

Works now that everything is pointing at the 5.0.0 version of the sources