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

Problem linking to static NetCDF when shared lib is also available #46

Open
kgerheiser opened this issue Oct 7, 2020 · 2 comments
Open

Comments

@kgerheiser
Copy link
Contributor

kgerheiser commented Oct 7, 2020

I had a problem with FindNetCDF and static linking.

There were two NetCDF libraries available: one static and one shared, and I wanted to use the static one, so I changed CMAKE_FIND_LIBRARY_SUFFIXES to ".a;.so" (to favor .a)

The problem is with how nc-config reports the libraries in this block of code:

#Use nc-config to set per-component LIBRARIES variable if possible

#Use nc-config to set per-component LIBRARIES variable if possible
  netcdf_config( ${NetCDF_${_comp}_CONFIG_EXECUTABLE} ${_${_comp}_libs_flag} _val )
  if( _val )
    set( NetCDF_${_comp}_LIBRARIES ${_val} )
    if(NOT NetCDF_${_comp}_LIBRARY_SHARED AND NOT NetCDF_${_comp}_FOUND) #Static targets should use nc_config to get a proper link line with all necessary static targets.
      list( APPEND NetCDF_LIBRARIES ${NetCDF_${_comp}_LIBRARIES} )
    endif()
  else()
    set( NetCDF_${_comp}_LIBRARIES ${NetCDF_${_comp}_LIBRARY} )
    if(NOT NetCDF_${_comp}_LIBRARY_SHARED)
      message(SEND_ERROR "Unable to properly find NetCDF.  Found static libraries at: ${NetCDF_${_comp}_LIBRARY} but could not run nc-config: ${NetCDF_CONFIG_EXECUTABLE}")
    endif()
  endif()

and then this:

set_target_properties(NetCDF::NetCDF_${_comp} PROPERTIES

add_library(NetCDF::NetCDF_${_comp} ${_library_type} IMPORTED)
      set_target_properties(NetCDF::NetCDF_${_comp} PROPERTIES
        IMPORTED_LOCATION ${NetCDF_${_comp}_LIBRARY}
        INTERFACE_INCLUDE_DIRECTORIES "${NetCDF_${_comp}_INCLUDE_DIRS}"
        INTERFACE_LINK_LIBRARIES ${NetCDF_${_comp}_LIBRARIES} )

It takes the value nc-config reports for libs, which in my case was -L/path/netcdf -lnetcdf and adds it to the imported target's INTERFACE_LINK_LIBRARIES. Then the final link flags are/path/netcdf/lib/libnetcdf.a (from IMPORTED_LOCATION) -L/path/netcdf/ -lnetcdf and that -lnetcdf picks up the dynamic library, overriding the static one. If there were only the static library in the path it would work fine.

The reason the libraries are added to INTERFACE_LINK_LIBRARIES is to pick up the necessary flags to link to dependencies, but in what I've seen is that all it links to is itself (e.g. -L/path/netcdf -lnetcdf) which shouldn't be necessary because its IMPORTED_LOCATIONS contains libnetcdf.a and is added to the link line.

Anyway, I think the solution is to remove NetCDF itself from INTERFACE_LINK_LIBRARIES so that only the .a is added on the link line.

Any thoughts @aerorahul or @edwardhartnett

@climbfuji
Copy link
Collaborator

The "solution" we came up with for the MRW/SRW releases is to only build the static netCDF libraries. This seemed to work fine and it sounds like it would work for you, too. But not sure if it is a feasible and practical approach for your case.

@aerorahul
Copy link
Collaborator

@kgerheiser

In a environment, such as on the NOAA RDHPCS, where we only build static libraries this is not an issue.
In a environment where both static and shared libraries are built, this is also not an issue, because this FindNetCDF.cmake properly finds the netCDF library and its dependency list and passes that to the user program.

In an environment where a user asks for a specific type of library (static) and both (static and shared) are present, this is an issue as you noticed. I think all these conditions will need extensive testing with different combinations of static/shared along with netCDF's dependencies (HDF5, PNetCDF, etc.)

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

3 participants