Closed jaadelgren closed 4 months ago
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.
CesiumGltfReader
makes use ofstb_image
image resizing functionality (specifically,stbir_resize_uint8
, see GltfReader.cpp, but does not include the implementation by definingSTB_IMAGE_RESIZE_IMPLEMENTATION
before thestb_image_resize.h
include. Because the implementation is never built, linking toCesiumGltfReader
will result in an error, assuming clients don't separately buildstb_image_resize
or link againstCesiumGltfContent
(see below).It looks like
CesiumGltfContent
does define the macro (in ImageManipulation.cpp, and therefore does have the necessarystbir_resize_XX
functions implemented. However,CesiumGltfReader
does not link againstCesiumGltfContent
.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 toCesiumGltfContent
, or if perhaps another, separate library (e.g.CesiumtImageResize
) is a better route.