Closed nschloe closed 7 years ago
It's a little difficult to find out where the undefined reference comes from. Normally, one would use -Wl,--no-undefined
, e.g.,
cmake \
-DCMAKE_SHARED_LINKER_FLAGS="$CMAKE_SHARED_LINKER_FLAGS -Wl,--no-undefined" \
-DBUILD_SHARED_LIBS:BOOL=ON \
-DTrilinos_ENABLE_Panzer:BOOL=ON \
-DTPL_ENABLE_MPI:BOOL=ON \
-DTrilinos_ENABLE_TESTS:BOOL=ON \
-DTrilinos_ENABLE_EXPLICIT_INSTANTIATION:BOOL=OFF \
-DSEACASExodus_ENABLE_MPI:BOOL=OFF \
../../source-upstream/
but this reveals other linking errors earlier in the build process. A PR is submitted.
Hi Nico,
Below is an email chain from yesterday discussing this problem. Panzer and Phalanx were refactored to completely remove Boost as a TPL dependency. Once these required dependencies were removed, it exposed an incorrect dependency declaration in stk_classic. The implementation in stk_classic forces a required dependency on BoostLib TPL. But it is declared optional in the dependencies file. The fix is simple - in the stk_classic dependencies file:
Trilinos/packages/stk/stk_classic/cmake/Dependencies.cmake
you just change the lines from:
SET(LIB_REQUIRED_DEP_TPLS Boost)
SET(LIB_OPTIONAL_DEP_TPLS BoostLib OpenNURBS)
to:
SET(LIB_REQUIRED_DEP_TPLS BoostLib)
SET(LIB_OPTIONAL_DEP_TPLS OpenNURBS)
When we talked to infrastructure team they were hesitant to change this (see below). So the quick fix is to either patch debian with the above change or to hard enable BoostLib TPL into the configure script with:
-D TPL_ENABLE_BoostLib:BOOL=ON
@bmpersc, should we revisit this decision since it is biting Nico too? The build logic is clearly incorrect and anyone that enables panzer and doesn't hard code the BoostLib TPL to ON will get broken builds.
Long term, we have a branch that changes panzer over to the new stk, away from stk_classic. We are waiting for some missing critical functionality to be added before we switch over. This should be added by end of December. The new stk has the BoostLib dependency correctly declared.
cc'ing @eric-c-cyr
Roger
On 11/19/2015 11:38 AM, Perschbacher, Brent M wrote:
Roger, Unfortunately the way that STKClassic was laid out that dependency needed to be optional because it was only used in certain subdirs of STKClassic and it was possible to not enable them and get value out of STKClassic. ... I¹m not sure what kind of impact changing that would have on others still using STKClassic that aren¹t internal to Sandia. I know Nico has some stake in it, but I¹m not sure if that is because of panzer or direct usage or what.
What I think we can do right now though is to manually enable the boostlib TPL for the continuous testing which should at least get rid of the errors for now. We can then revisit this later once we fix the Sierra integration to work with github. Is that an acceptable solution?
Brent
On 11/19/15, 8:56 AM, "Roger P" wrote:
Brent and Jim,
I just finished removing the Boost TPL requirement from panzer. However, the trilinos CI testing shows that some panzer tests are now failing to link because it can't find the BoostLib libraries. This dependency is coming in from stk classic, but I think the dependencies in stk classic are incorrect. I think the problem is that STK Classic actually has a required dependence on BoostLib, not just an optional one. I would like to make that change in dependencies in stk classic to make BoostLib a required TPL instead of optional dependency. I think that panzer is the only library that has not updated to new stk, so this change should be fine. Is this ok with you?
For the failing build, it turns out that the include path and lib directories for BoostLib are specified in the configure command, but the flag TPL_ENABLE_BoostLib is missing. Therefore, BoostLib is no longer getting enabled for that build. It was getting enabled previously due to panzer having a required dependency on it. Now that this is gone, we can either fix this by changing stk_classic logic to have a required dependency or for the test driver logic to hard enable BoostLib TPL.
Roger
This may or may not be related to https://software.sandia.gov/bugzilla/show_bug.cgi?id=5929.
FYI: Changes to stk_classic do actually happen, cf. https://github.com/trilinos/Trilinos/commits/master/packages/stk/stk_classic.
@nschloe A required library dependence of stk_classic on BoostLib was push recently. Can you confirm that this issue is fixed and close if so?
Thanks for the update. Unfortunately, there are still undefined references within stk_classic. When configuring with
-DCMAKE_SHARED_LINKER_FLAGS="$CMAKE_SHARED_LINKER_FLAGS -Wl,--no-undefined" \
one still gets
Linking CXX shared library libtrilinos_stkclassic_util_env.so
CMakeFiles/trilinos_stkclassic_util_env.dir/RuntimeMessage.cpp.o: In function `stk_classic::report_deferred_messages(ompi_communicator_t*)':
/home/nschloe/software/trilinos/source-upstream/packages/stk/stk_classic/stk_util/stk_util/environment/RuntimeMessage.cpp:296: undefined reference to `stk_classic::parallel_machine_size(ompi_communicator_t*)'
[...]
The fix is implemented in PR https://github.com/trilinos/Trilinos/pull/2. @rppawlo Do you know how stk_classic was modified?
Matt pushed a change to the stk classic Dependencies.cmake file to make BootLib a required instead of optional dependency.
I'm still seeing this with some platforms, @bartlettroscoe and I are going to talk about this tomorrow hopefully after the 8-10 meeting
@nschloe I'm hesitant to accept PR #2 without more testing. This changes the dependencies by adding a parallel library dependency to other libraries. This might break serial builds depending on how it was implemented. I pulled the PR into a local branch and tested it out for panzer builds and everything is fine, but panzer is always built in parallel. If Matt and Ross don't fix this today, then I will do some more serial testing and try to push.
@rppawlo That'd be great, thanks!
@rppawlo Any success with this yet?
@bathmatt @bartlettroscoe did you guys figure anything wrt this? Matt commented above that you two had a meeting to work on this.
For now can you just set -DTPL_ENABLE_BoostTPL=ON
? Does that fix the problem?
I think that part has been fixed by a commit from Matt. The current problem is that one stk_classic library is dependent on another stk_classic library and that dependency is missing. The required library is a parallel only library. So we have to be careful adding this dependency. It may mess up serial builds depending on how the library is built. See Nico's pull request.
No that doesn't fix the problem. do you have a hansen account?
On Fri, Mar 4, 2016 at 6:53 AM, rppawlo notifications@github.com wrote:
I think that part has been fixed by a commit from Matt. The current problem is that one stk_classic library is dependent on another stk_classic library and that dependency is missing. The required library is a parallel only library. So we have to be careful adding this dependency. It may mess up serial builds depending on how the library is built. See Nico's pull request.
— Reply to this email directly or view it on GitHub https://github.com/trilinos/Trilinos/issues/17#issuecomment-192292092.
Waiting for account approval. Can you send me instructions on how to reproduce on hansen?
do you have a hansen account?
@bathmatt, are you asking Roger or me? I have a Hansen account and I am on there now setting up my development environment.
Build panzer, you will find that it ignores your library path. In my home dir you will find Trilinos/build/justPanzer/ and there is a configure in that dir that works, but if you remove boost from the netcdf or hdf5 (don't recall where I hacked it) and use the boostlib flags you will find it doesn't work.
On Fri, Mar 4, 2016 at 8:28 AM, Roscoe A. Bartlett <notifications@github.com
wrote:
do you have a hansen account?
@bathmatt https://github.com/bathmatt, are you asking Roger or me? I have a Hansen account and I am on there now setting up my development environment.
— Reply to this email directly or view it on GitHub https://github.com/trilinos/Trilinos/issues/17#issuecomment-192322946.
Is this still an issue, or has it been solved?
I tried the configuration from the original post and the build error doesn't occur anymore. Closing.
With
I'm getting the linking error