Add nceplibs to libgfsphys.so

[climbfuji]

This PR adds the NCEP LIBS to the compile/link command for libgfsphys.so. If these are not linked in, the code aborts because of undefined symbols in the library.

[llpcarson]

Dom - I'm a bit confused by this change. You're including the nceplibs in the build of the libgfsphys.so? And, the location of that lib is added to the LD_LIBRARY_PATH. But, how does that help the executable find the nceplib routines at run-time?

[climbfuji]

@llpcarson the ncep libs are all static libraries and linked into libgfsphys.so at compile time. This PR doesn't change the LD_LIBRARY_PATH, are you referring to another PR or already existing code? In any case, if the ncep libs are not added to the linker line as described here in the PR, running the model fails: once ccpp loads libgfsphys,.so using dlopen(), it aborts because of undefined symbols (mainly from the w3 libraries)

[llpcarson]

That's definitely an issue - but I thought we (Julie, Tim & I) solved this last summer by using the -Bexport_all_symbols at link time. This may be a more specific way to solve the same issue - but I'm confused about how the executable knows to search this lib (libgfsphys.so) after the ccpp loads the referenced routines. Oh wait - is the ccpp loading the entire library? I had assumed (!) that it was specifically only loading those needed by the suite. But, that wouldn't work, actually.

So - this is one way to solve the dependent libs issue, and probably a better way for a "stand-alone" release. I hope, though, in the longer term that we can reference pre-built libs on the NOAA platforms and not be in the business of supporting the libs for all users - which would then need to use something like -Bexport_all_symbols.

[climbfuji]

Ok, now I am a bit confused ... the -Bexport_all_symbols is still there, but as I said when trying to run the code it aborts, because it can't find certain symbols (such as stuff from w3 lib). What happens I believe is that the dlopen() does stuff independently of the main executable (which might have all the symbols) and treats libgfsphys.so as one entity that needs to contain all information. And I thought that we had agreed last week that it is better to ship the thirdparty libraries (aka NCEP libs) with the code - eventually even including esmf, so that we only rely on a compiler, mpi and netcdf library being present. But we can for sure discuss this later.

[llpcarson]

Approved.

[llpcarson]

That's odd, that you were getting a failure. I know we had this issue early on, and thought we had solved it. I wonder if there are some new libs or dependencies due to the extra diagnostics or something? I wonder if it's because (I think?) I took out the libgfsphys.so from the link command for the NEMS.x main program, figuring it was not needed there. But maybe that triggered some dependencies in the loader? I'm definitely not an expert in all the ways of managing dynamic libs! The question of bundling libraries is a challenging one. For a general community user, who may or may not have access to a well-defined environment, it is valuable to bundle these libs. However, for users working on a shared resource where these packages are installed and supported - having an extra copy that may or may not get the latest bug fix (rare, but definitely not zero), often causes more problems than it solves. EMC is likely to insist on using the supported, pre-installed versions of these libs. But, for a community user, we will need to bundle. cheyenne is sort of in the middle - it usually does not have the nceplibs installed, but definitely has modules packaged for ESMF, for example.

…

On Tue, Nov 21, 2017 at 11:10 AM, Dom Heinzeller ***@***.***> wrote: Ok, now I am a bit confused ... the -Bexport_all_symbols is still there, but as I said when trying to run the code it aborts, because it can't find certain symbols (such as stuff from w3 lib). What happens I believe is that the dlopen() does stuff independently of the main executable (which might have all the symbols) and treats libgfsphys.so as one entity that needs to contain all information. And I thought that we had agreed last week that it is better to ship the thirdparty libraries (aka NCEP libs) with the code - eventually even including esmf, so that we only rely on a compiler, mpi and netcdf library being present. But we can for sure discuss this later. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHTrIk6r2WB2FIShPsNBf-qpK4CEmExBks5s4xH8gaJpZM4Qiy_d> .