Static builds can't link

[jherico]

The nvtt library depends on other static libraries like bc6h and bc7. In shared library builds these are resolved when generating the nvtt binary and so the static libraries are just artifacts of the build process.

In static builds of nvtt, the cmake line TARGET_LINK_LIBRARIES(nvtt ${LIBS} nvcore nvimage nvthread squish bc6h bc7 nvmath rg_etc1) has no effect because there's no link step. Since the bc6h bc7 and rg_etc1 libraries don't have any install commands, an installed version of nvtt will always have unresolved symbols.

Either the additional libraries should be included in the install step when building static, or the functionality should be directly bundled into the static versions of nvtt, nvimage, etc by directly including the appropriate source files. Unfortunately since nvtt and nvimage both use functionality out of these library, the latter will probably be problematic because it will create duplicated symbols.

[jherico]

After trying to get a fixed build locally, either statc or shared, but buildable on Windows using vcpkg.
The current state of dllimport/dllexport declarations appears to be a total disaster.

I suggest a new strategy, merging the approach used in the current visual studio projects... Create a single build artifact "nvtt". Instead of building all of the dependencies as static libs, use the cmake concept of object libs, so that all the compiled object files are referenced by the one and only output, whether it's shared or static. This should work on Windows and non-windows platforms and should remove the need for the visual studio projects and make building with vcpkg on various platforms less of a headache.

[naccuracy]

I received an undefined reference error when I tried to link to the nvtt and nvimage static libraries in Debian. I solved this by placing nvtt and nvimage at the top of the list of libraries in my ld command.