search

trilinos / Trilinos

Primary repository for the Trilinos Project
https://trilinos.org/
Other
1.19k stars 565 forks source link

Panzer: undefined reference to `boost::system::system_category()' #17

Closed nschloe closed 7 years ago

nschloe commented 8 years ago

With

cmake \
  -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/

I'm getting the linking error

../../src/libpanzer_stk.a(Panzer_STKConnManager.cpp.o): In function `_GLOBAL__sub_I_Panzer_STKConnManager.cpp':
Panzer_STKConnManager.cpp:(.text.startup+0x4b): undefined reference to `boost::system::generic_category()'
Panzer_STKConnManager.cpp:(.text.startup+0x57): undefined reference to `boost::system::generic_category()'
Panzer_STKConnManager.cpp:(.text.startup+0x63): undefined reference to `boost::system::system_category()'
nschloe commented 8 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.

rppawlo commented 8 years ago

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

nschloe commented 8 years ago

This may or may not be related to https://software.sandia.gov/bugzilla/show_bug.cgi?id=5929.

nschloe commented 8 years ago

FYI: Changes to stk_classic do actually happen, cf. https://github.com/trilinos/Trilinos/commits/master/packages/stk/stk_classic.

rppawlo commented 8 years ago

@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?

nschloe commented 8 years ago

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?

rppawlo commented 8 years ago

Matt pushed a change to the stk classic Dependencies.cmake file to make BootLib a required instead of optional dependency.

bathmatt commented 8 years ago

I'm still seeing this with some platforms, @bartlettroscoe and I are going to talk about this tomorrow hopefully after the 8-10 meeting

rppawlo commented 8 years ago

@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.

nschloe commented 8 years ago

@rppawlo That'd be great, thanks!

nschloe commented 8 years ago

@rppawlo Any success with this yet?

rppawlo commented 8 years ago

@bathmatt @bartlettroscoe did you guys figure anything wrt this? Matt commented above that you two had a meeting to work on this.

bartlettroscoe commented 8 years ago

For now can you just set -DTPL_ENABLE_BoostTPL=ON? Does that fix the problem?

rppawlo commented 8 years ago

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.

bathmatt commented 8 years ago

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.

rppawlo commented 8 years ago

Waiting for account approval. Can you send me instructions on how to reproduce on hansen?

bartlettroscoe commented 8 years ago

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.

bathmatt commented 8 years ago

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.

jmgate commented 7 years ago

Is this still an issue, or has it been solved?

nschloe commented 7 years ago

I tried the configuration from the original post and the build error doesn't occur anymore. Closing.