Linker error with CesiumGltfReader

[jaadelgren]

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.

[appybara13]

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.

[csciguy8]

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.

[lilleyse]

Fixed in #860