search

libMesh / libmesh

libMesh github repository
http://libmesh.github.io
GNU Lesser General Public License v2.1
643 stars 285 forks source link

Linking problems with v1.5.0 opt/dbg and 1.3.1/1.4.1. #2337

Closed jdeaton closed 4 years ago

jdeaton commented 4 years ago

I work on the MAST project with @manavbhatia that builds around the core FEM capability of libMesh. I believe I have two related, but possibly different issues.

I just recently setup Travis CI to test our code on multiple OS/compilers and against different versions of libMesh. We use cmake and and a "Debug" build links against libmesh_dbg and a "Release" build links against libmesh_opt.

First, I'm wondering what might have changed related to communicator.h between libMesh v1.4.1 and v1.5.0. Using clang, I have no trouble building MAST against dbg/opt libMesh 1.4.1, but in v1.5.0 I'm getting Undefined symbols for libMesh::Parallel::Communicator::max<double>(double&) const (https://travis-ci.com/MASTmultiphysics/mast-multiphysics/jobs/257923414). The same issues occur with gcc (https://travis-ci.com/MASTmultiphysics/mast-multiphysics/jobs/257923415).

Second, using gcc-5.4 (old I know, but its distributed with Travis's Ubuntu 16.04 worker), I get tons of linking errors anytime I try to link against libmesh_dbg even when using libMesh 1.3.1/1.4.1 (https://travis-ci.com/MASTmultiphysics/mast-multiphysics/jobs/257923418). I'm able to build successfully against libmesh_opt. Also, I have no trouble building with clang both against both libMesh opt/dbg.

Any ideas on either of these issues?

bboutkov commented 4 years ago

For the first one, I recently ran into a quite similar seeming problem in GRINS (see here) due to changes introduced in #2219. My bet is you need to just include a couple of the relevant headers and you should be fine. Unfortunately, I can't speak to your second issue.

jwpeterson commented 4 years ago

I agree with @bboutkov that including the right files will probably fix the first issue.

Regarding the second issue, I suspect this could be related to the "pedantic" debugging flags that we (used to) use with GCC in debug-mode builds. IIRC, they make it so that other software linking to the build also has to use the same flags, which are:

-D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC

Those flags are no longer used by default as of libmesh 1.5.0. They also aren't used with clang, which could explain why your clang build does work.

roystgnr commented 4 years ago

I agree with @bboutkov that including the right files will probably fix the first issue.

Likewise, but I'm a little perturbed that the issue isn't a compile-time rather than a link-time error. I swear I looked for every "not marked inline when it should be" function and fixed them way back in 7b58040354f4ed328019efa393b890935104d34f, which I see did make it into the v1.5.0 tag.

Those flags are no longer used by default as of libmesh 1.5.0. They also aren't used with clang, which could explain why your clang build does work.

And it would explain why all the missing APIs look to be std::vector based. What's strange though is: how would those flags still be getting into the MAST build? If there's similar code in MAST to manually add them then you'd think it wouldn't have been a confusing issue; if MAST is just scraping libMesh flags from Make.common or libmesh-config or whatever then the glibcxx debugging flags shouldn't be there to scrape anymore and everything (in fresh builds) should still be compatible.

jdeaton commented 4 years ago

I agree with @bboutkov that including the right files will probably fix the first issue.

You guys were right on the first issue. Adding a few includes to parallel.h and libmesh_logging.h were all that was needed to get everything building against both libmesh_dgb and libmesh_opt for v1.5.0.

On the second issue I think I'm just going to take v1.3.1/1.4.1 with GCC out of our CI and just use v1.5.0 going forward.

Thanks for the help. I'll close this issue for now.

jdeaton commented 4 years ago

Adding a few includes to parallel.h and libmesh_logging.h

To clarify, I meant including those two libMesh files a few places in MAST.

jwpeterson commented 4 years ago

What's strange though is: how would those flags still be getting into the MAST build?

My conjecture was they were not using those flags at the MAST level, but then trying to link against a libmesh that was built with those flags... IIRC that can cause an issue.

jdeaton commented 4 years ago

My conjecture was they were not using those flags at the MAST level, but then trying to link against a libmesh that was built with those flags... IIRC that can cause an issue.

We definitely weren't using those extra flags in the MAST build. I think you are probably right (just too lazy to go test it out). Manav and I both do most of our development on macOS with clang and then use Release builds on linux/GCC. It never really came up until I had a colleague trying to use the Debug build with GCC. I've just told them to migrate to libMesh v1.5.0.

jwpeterson commented 4 years ago

@jdeaton thanks for clarifying. @hrittich ran into a similar issue, leading us to not use those flags by default.