STK: undefined reference to `null_streambuf::null_streambuf()'

[nschloe]

As of recently, STK fails to link with undefined references,

[...]
Linking CXX shared library libtrilinos_stk_util_env.so
CMakeFiles/trilinos_stk_util_env.dir/EnvData.cpp.o: In function `stk::EnvData::EnvData()':
/home/nschloe/software/trilinos/source-upstream/packages/stk/stk_util/stk_util/environment/EnvData.cpp:76: undefined reference to `null_streambuf::null_streambuf()'
[...]

This is with

  -DCMAKE_SHARED_LINKER_FLAGS="$CMAKE_SHARED_LINKER_FLAGS -Wl,--no-undefined"

[pbosler]

I finally got a work around for this bug -- for some reason TriBITS & CMake aren't finding the dependencies of the stk libraries.

I edited the TRIBITS_ADD_LIBRARY command in four CMakeLists.txt files: stk_util/stk_util/use_cases/CMakeLists.txt, stk_util/stk_util/registry/CMakeLists.txt, stk_util/stk_util/diag/CMakeLists.txt, and stk_util/stk_util/environment/CMakeLists.txt.

To each file I added arguments to the DEPLIBS part of the TRIBITS_ADD_LIBRARY command to explicitly state the following dependencies:

1. stk_util_use_cases depends on stk_util_parallel, stk_util_env, and stk_util_diag
2. stk_util_registry depends on stk_util_env
3. stk_util_diag depends on stk_util_env
4. stk_util_env depends on stk_util_util and stk_util_parallel

The Trilinos build now completes and installs successfully; however, due to these changes I now get a TriBITS/CMake warning:

CMake Warning at cmake/tribits/core/package_arch/TribitsLibraryMacros.cmake:601 (MESSAGE):
WARNING: 'stk_util_parallel' in DEPSLIBS is not a lib defined in the
current cmake project! Such usage is deprecated (and will result in a
configure error soon). If this is an external lib you are trying to link
in, it should likely be handled as a TriBITS TPL. Otherwise, it should be
passed in through IMPORTEDLIBS. However, the only case we have found where
IMPORTEDLIBS had to be used instead of through a proper TriBITS TPL is the
C math library 'm'.
Call Stack (most recent call first):
packages/stk/stk_util/stk_util/environment/CMakeLists.txt:69 (TRIBITS_ADD_LIBRARY)

[dalg24]

@pbosler: Thank you for the work around. It worked for me.

[dalg24]

Did you submit a pull request?

[pbosler]

@dalg24 No, I didn't, for several reasons.

1. After doing this for Trilinos, I had similar problems building/linking Albany which has too many dependencies within itself for this work around to be practical.
2. I switched to a static build, and these problems didn't show up.
3. The CMake warning (above) made me think I had done something wrong. I thought TriBits and CMake were supposed to find all of these dependencies automatically (especially within the same project), so this work around seems like a hack to me that doesn't really solve the underlying problem.

[nschloe]

@bartlettroscoe Any thoughts here?

[bartlettroscoe]

@bartlettroscoe Any thoughts here?

I can look at fixing the issue properly and avoiding the TriBITS warnings, but I don't think that I can make changes to STK in Trilinos and push to 'master' (soon to be 'develop'). I think the only person who can push changes to STK is @bmpersc.

Hopefully this will be resolved in FY17 with a restructuring of SIERRA, STK, SEACAS and Trilinos with a planned milestone.

[nschloe]

As far as I recall, changes to STK (as opposed to stk_classic) are okay. @bmpersc, could you check @pbosler's suggestions above and include them?

[matthewhoffman]

Is there an updated status for this issue? I am an Albany user so I switched to a static build as per @pbosler 's second suggestion above. However, I also need to use exodus.py which requires that Trilinos be built with shared libraries.

I guess my workaround would be to build a second version of Trilinos with shared libraries using @pbosler 's first suggestion above just for using exodus.py, but it would be nice to not need to maintain two versions of Trilinos.

[github-actions]

This issue has had no activity for 365 days and is marked for closure. It will be closed after an additional 30 days of inactivity.
If you would like to keep this issue open please add a comment and remove the MARKED_FOR_CLOSURE label.
If this issue should be kept open even with no activity beyond the time limits you can add the label DO_NOT_AUTOCLOSE.

[alanw0]

This has been resolved.