Open jonesmz opened 2 years ago
Hmm, tried to reproduce here on Linux with clang, libc++ and -flto
but no success. So I guess I'd have to dig up the Mac Mini I have buried somewhere and try there. One fix for similar warnings was already done in mosra/corrade@7ae90319e42871efaa5c59395ee5d3e18e388e47 back in 2019, but this seems to be a different case.
global weak symbol 'guard variable for
... this is apparently due to a static
function-local variable. Not sure if that changes anything.
My CI build reports a similar problem in the MeshOptimizerSceneConverter plugin, so I'll look into this problem instead and maybe if I find a fix for it, it'll fix the TinyGltfImporter issue as well.
ld: warning: direct access in function 'meshopt_IndexAdapter<unsigned short, false>::meshopt_IndexAdapter(unsigned short*, unsigned short const*, unsigned long)' from file 'src/MagnumPlugins/MeshOptimizerSceneConverter/CMakeFiles/MeshOptimizerSceneConverter.dir/MeshOptimizerSceneConverter.cpp.o' to global weak symbol 'meshopt_Allocator::StorageT<void>::allocate' from file '/Users/distiller/deps/lib/libmeshoptimizer.a(overdrawanalyzer.cpp.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in function 'meshopt_IndexAdapter<unsigned short, false>::~meshopt_IndexAdapter()' from file 'src/MagnumPlugins/MeshOptimizerSceneConverter/CMakeFiles/MeshOptimizerSceneConverter.dir/MeshOptimizerSceneConverter.cpp.o' to global weak symbol 'meshopt_Allocator::StorageT<void>::deallocate' from file '/Users/distiller/deps/lib/libmeshoptimizer.a(overdrawanalyzer.cpp.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in function 'meshopt_IndexAdapter<unsigned char, false>::meshopt_IndexAdapter(unsigned char*, unsigned char const*, unsigned long)' from file 'src/MagnumPlugins/MeshOptimizerSceneConverter/CMakeFiles/MeshOptimizerSceneConverter.dir/MeshOptimizerSceneConverter.cpp.o' to global weak symbol 'meshopt_Allocator::StorageT<void>::allocate' from file '/Users/distiller/deps/lib/libmeshoptimizer.a(overdrawanalyzer.cpp.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in function 'meshopt_IndexAdapter<unsigned char, false>::~meshopt_IndexAdapter()' from file 'src/MagnumPlugins/MeshOptimizerSceneConverter/CMakeFiles/MeshOptimizerSceneConverter.dir/MeshOptimizerSceneConverter.cpp.o' to global weak symbol 'meshopt_Allocator::StorageT<void>::deallocate' from file '/Users/distiller/deps/lib/libmeshoptimizer.a(overdrawanalyzer.cpp.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
let me know if work was done in this area since
Actually, yes, it was -- there's a completely new plugin, CgltfImporter, which is based on cgltf. Compared to tiny_gltf it compiles way faster as there's no humongous modern C++ JSON parser library behind, it doesn't use the STL containers so it's way more memory efficient, and it also parses everything way faster. All effort now goes into this new plugin, TinyGltfImporter
is kept in a maintenance mode for projects that rely on its specific features like peeking into the internal tinygltf structures through importerState()
. It should be a drop-in replacement, the only difference is that messages in case of a JSON or glTF error are a bit underwhelming. But that's being worked on.
If you switch to this plugin, you should no longer get those warnings as the 3rd party code is way simpler and better. Nevertheless, I'm keeping the issue open until I make the build warning-free again.
See github action run: https://github.com/TheOpenSpaceProgram/osp-magnum/runs/5082185747
This is happening on Mac OS X, which for my project is not a platform we really care about, but we do run a Mac OS X CI just for the heck of it.
I haven't noticed this problem on other platforms.
Happening with commit 3102678d19811a735f0da7e294a2acff40ffc6cf , let me know if work was done in this area since and i can try a newer commit.