missing DEPLIBS for stk

[nschloe]

This commit fixes missing symbols errors revealed by linking with -Wl,--no-undefined. Evolved from https://software.sandia.gov/bugzilla/show_bug.cgi?id=5929.

@bmpersc @gsjaardema Probably for you to review/merge.

[nschloe]

Without this, I'm also getting build errors like

[ 76%] Linking CXX executable STK_stk_io_doc_tests.exe
../../stk_util/stk_util/environment/libstk_util_env.so.12.9: undefined reference to `boost::program_options::detail::cmdline::cmdline(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&)'
../../stk_util/stk_util/environment/libstk_util_env.so.12.9: undefined reference to `boost::program_options::detail::cmdline::set_additional_parser(boost::function1<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&>)'
../../stk_util/stk_util/environment/libstk_util_env.so.12.9: undefined reference to `boost::program_options::to_internal(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
../../stk_util/stk_util/environment/libstk_util_env.so.12.9: undefined reference to `boost::program_options::abstract_variables_map::operator[](std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const'
collect2: error: ld returned 1 exit status
packages/stk/stk_doc_tests/stk_io/CMakeFiles/STK_stk_io_doc_tests.dir/build.make:1197: recipe for target 'packages/stk/stk_doc_tests/stk_io/STK_stk_io_doc_tests.exe' failed
make[2]: *** [packages/stk/stk_doc_tests/stk_io/STK_stk_io_doc_tests.exe] Error 1
CMakeFiles/Makefile2:116565: recipe for target 'packages/stk/stk_doc_tests/stk_io/CMakeFiles/STK_stk_io_doc_tests.dir/all' failed
make[1]: *** [packages/stk/stk_doc_tests/stk_io/CMakeFiles/STK_stk_io_doc_tests.dir/all] Error 2
Makefile:160: recipe for target 'all' failed

when building tests. @bmpersc, could you take a look?

[bartlettroscoe]

I think we are still not allowed to push changes to STK. And it looks like there is little hope that will ever change. Someone on the Sierra side would have to do it.

@trilinos/stk, can one of the STK developers please apply this patch to the native STK repo? I think I have access to the native STK repo so I could push these changes if there are no objections? Since these only impact CMakeLists.txt files, this will not affect that native BJAM build of STK in its host application.

[nschloe]

Ah, I had been under the impression that the CMake part of STK is handled on the Trilinos side.

In any case, thanks Ross for the reply!

[bartlettroscoe]

Ah, I had been under the impression that the CMake part of STK is handled on the Trilinos side.

We are not allowed to make any changes to STK at all on the Trilinos side, even to just the CMakeLists.txt files. Unfortunately, this is unlikely to ever change judging how things are going with a new integration effort with STK.

[nschloe]

Unfortunately, this is unlikely to ever change judging how things are going with a new integration effort with STK.

That's perfectly fine if there is a way to submit issues/PRs to STK directly.

[bartlettroscoe]

That's perfectly fine if there is a way to submit issues/PRs to STK directly.

I don't think there can be given the way things are going. I think you would need to be an application developer in the Sandia code base where the STK code is embedded in order to do that. You can only do that if your are a Sandian and pay thousands of $$ a year to get access to that code base.

[nschloe]

@trilinos/stk Ping.

[maherou]

It is not clear to me that any one on the @trilinos/stk team is both paying attention and able to do something about this issue. @trilinos/framework: What can be done to resolve this issue?

[jwillenbring]

@bmpersc Is there some way to push this through since it only affects CMakelists files, or should we try to file a STK ticket? This is a poster child for why the integration has to be redone in the right way.

[nschloe]

Unfortunately, this hasn't been resolved yet. Is there anything I can do to help?

[bartlettroscoe]

Realistically, I think @bmpersc is the only person who can really make this happen.

[bmpersc]

@nschloe I am in the middle of fixing other build errors that have cropped up with an updated STK, once I have addressed those I will look into applying your suggested changes as well.

[bmpersc]

I have applied this to STK with some minor changes to address warnings in the build. The only substantive change was to remove stating the boost_program_options dependency. That was causing a warning in the build and it should be redundant since the subpackage was correctly optionally depending on the BoostLib TPL.

I will be working to get this back into Trilinos next week.

[nschloe]

@bmpersc Have you had the chance to look into this yet?

[bmpersc]

@nschloe yes and no. Yes I was working on getting these back into Trilinos when we discovered something in the integration that was completely unacceptable. That forced our hand to instead make the planned move to a new integration system earlier than we'd planned. I'm currently working on that revamp now.

[nschloe]

@bmpersc How is the revamp going?

[nschloe]

@jwillenbring I still see the error. Anything I can do to help getting this merged?

[mhoemmen]

@nschloe It's been a while since STK got merged into Trilinos. Not sure of the schedule for the next merge.

@khpierson may want to know about this.

[jwillenbring]

@bmpersc Has this been essentially applied at this point through the integration process? Can we close this?