Linker error with `CesiumGltfReader`
jaadelgren opened this issue · comments
CesiumGltfReader
makes use of stb_image
image resizing functionality (specifically, stbir_resize_uint8
, see GltfReader.cpp, but does not include the implementation by defining STB_IMAGE_RESIZE_IMPLEMENTATION
before the stb_image_resize.h
include. Because the implementation is never built, linking to CesiumGltfReader
will result in an error, assuming clients don't separately build stb_image_resize
or link against CesiumGltfContent
(see below).
It looks like CesiumGltfContent
does define the macro (in ImageManipulation.cpp, and therefore does have the necessary stbir_resize_XX
functions implemented. However, CesiumGltfReader
does not link against CesiumGltfContent
.
Of course, there may be duplicate symbols issues if both libraries build the implementations. It's unclear to me whether it would be appropriate for CesiumGltfReader
to simply link to CesiumGltfContent
, or if perhaps another, separate library (e.g. CesiumtImageResize
) is a better route.
I've encountered the same linker error, and sure enough I had to link CesiumGltfReader
against CesiumGltfContent
to avoid issues with duplicate symbols.
I'd say a separate library for all stb implementations would make the most sense, to avoid similar problems in the future.
It sounds like the output libraries from cesium-native might need to be looked at again, but from a usage perspective.
For example, if CesiumGltfReader
isn't meant to be used by itself, but also with CesiumGltfContent
, maybe it shouldn't even be compiled into a separate lib? Could be all the Gltf related logic just goes into a single CesiumGltf
lib.
This inspired me to write up #855. This relates to the general question of "what are the ways I can use cesium-native?". If cherry picking libs is something we intend users to do, we should have some reference for this, or at least document it.
Fixed in #860