Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

release/public-v1: linking to static libgfortran #6

Closed
climbfuji opened this issue Feb 7, 2020 · 1 comment
Closed

release/public-v1: linking to static libgfortran #6

climbfuji opened this issue Feb 7, 2020 · 1 comment

Comments

@climbfuji
Copy link
Contributor

For release/public-v1: The following linker flags in NCEPLIBS-grib_util/sorc/copygb2.fd/CMakeLists.txt are requiring a static libgfortran:

if(IntelComp)
  set(fortran_flags "-g" "-O3" "-r8" "-convert" "big_endian" "-auto" "-fpp" "${OpenMP_Fortran_FLAGS}")
  set(link_flags "-static-intel")
elseif(GNUComp)
  set(fortran_flags "-g" "-O3" "-fdefault-real-8" "-fconvert=big-endian" "-cpp" 
    "${OpenMP_Fortran_FLAGS}")
  set(link_flags "-static-libgfortran")
else()
  message("unknown compiler!")
  exit()
endif()

This is not something modern Linux distributions are good at. I commented it out and could build the library on Redhat 8 (which has a broken libgfortran.a, i.e. the packages that "provide" it just have symbolic links to a place where no version exists).

Is it really necessary to use static linking for this? Does anyone know? Thanks.

@climbfuji
Copy link
Contributor Author

This was apparently solved in the process of creating the UFS MRW App v1.0.0 release version

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant