Compilation fails as spack package for master branch

[fdrui]

Hi!
I used to include libMesh as a library via spack v0.19 for almost a year. Recently I changed to spack v0.20 and still using the master branch for libMesh. Now I get errors during the build stage of libMesh that outputs:

  >> 2412    src/mesh/poly2tri_triangulator.C:188:3: error: there are no arguments to 'LOG_SCOPE' that depend on a template parameter, so a declaration of 'LOG_SCOPE' must be available [-fpermissive]
     2413      188 |   LOG_SCOPE("restore_delaunay()", "Poly2TriTriangulator");
     2414          |   ^~~~~~~~~

or later

  >> 2418    src/mesh/poly2tri_triangulator.C:369:3: error: 'LOG_SCOPE' was not declared in this scope
     2419      369 |   LOG_SCOPE("triangulate()", "Poly2TriTriangulator");
     2420          |   ^~~~~~~~~

Would you have an idea how I can fix this?
Thank you!
Florence

[jwpeterson]

Can you try adding a

#include "libmesh/libmesh_logging.h"

in src/mesh/poly2tri_triangulator.C? I'm not really sure how this made it past all of our testing, unless we are not building with poly2tri enabled anywhere...

[jwpeterson]

Yeah, must be some kind of indirect inclusion that we get in all our testing.

[roystgnr]

We're pretty good about keeping libmesh_logging.h out of our headers. generic_projector.h is the only one doing enough heavyweight work that it needs to be logged itself, and we're certainly not including that indirectly by accident. But threads_foo.h implementations need to be able to turn off logging in threaded sections, and the threaded algorithms that do so need to be templated, so we end up with indirect inclusion practically everywhere.

This should be easy to fix; the algorithms need to be templated but a Threads::enable_logging(bool) shim can be in a .C file. Let me try that and see if it replicates the build failure.

[fdrui]

Thank you very much for your explanations. They have conducted me to disable the poly2tri option (since I don't know exactly how to change libMesh sources via spack) and now it seems to compile without error.

[roystgnr]

Glad to hear it! If your users don't need the Poly2TriTriangulator then you should be good to go - we don't use poly2tri anywhere else.

I've managed to replicate the problem and we'll have a fix in shortly, though, so hopefully you'll be able to reenable soon. That's turned out to be a really useful class for users constructing their own meshes.

[roystgnr]

we'll have a fix in shortly, though

#3661, though due to some CI work it'll take a little while for that to make it all the way from PR->devel->master.

[fdrui]

I have now another issue when I try to compile my code, probably due to a dependency I have on metis, v5.1.0. During the linking stage of my compilation, I get:

/usr/bin/ld: gk_jbuf: TLS definition in ../../../thirdparties-spack/view/lib/libmetis.so section .tbss mismatches non-TLS definition in ../../../thirdparties-spack/view/lib/libmesh_dbg.so section .bss
/usr/bin/ld: ../../../thirdparties-spack/view/lib/libmesh_dbg.so: error adding symbols: bad value
collect2: error: ld returned 1 exit status
make[2]: *** [src/manta/core/CMakeFiles/manta-core.dir/build.make:1773: src/manta/core/libmanta-core.so] Error 1
make[1]: *** [CMakeFiles/Makefile2:1212: src/manta/core/CMakeFiles/manta-core.dir/all] Error 2
make: *** [Makefile:146: all] Error 2

I will try to remove all dependencies on metis, but somehow, I think I will need it...

Thank you for your help!

[jwpeterson]

In theory, we support configuring libmesh with a user-provided Metis, you just need to configure with:

--with-metis=/path/to/your/libmetis.so --with-metis-include=/path/to/your/metis.h

where /path/to/your/libmetis.so and /path/to/your/metis.h are specific to your particular system. Alternatively, you could configure libmesh with --disable-metis to avoid this conflict, but you would then not be able to use the Metis-based partitioner in libMesh.