Linking issues on Windows about ptex

[lgritz]

I'm in critical danger of stepping beyond my windows knowledge, but there are a few common gotchas that I would double check first:

• That you're not accidentally picking up a set of ptex .h files that don't exactly correspond to the ptex libraries you have? (Sometimes weird things happen if you inadvertently have two different Ptex versions installed.)
• One library is release, the other is debug? (I think MSVS actually changes ABI slightly between debug and release builds)
• Mismatch in some other MSVS compiler flags that are required to be the same across all compilation units? (That __ptr64 that's found but not expected is very suspicious.)

[KelSolaar]

Hi Larry/@lgritz,

Thanks for replying!

• I have only a single Ptex library that I built the same way I build OIIO and all the VFX Reference Platform on Windows.
• The cmake configuration always use this generator and toolset: -G "Visual Studio 15 2017 Win64" -T v141,host=x64 (I have a variant for Visual Studio 14 2015 Win64 but it is not used for OIIO) and it is build as follows: cmake --build . --config Release --target INSTALL
• For what its worth, I'm linking OIIO against OpenEXR and Imath just fine and the symbols have the __ptr64 type:

undname ?rgb2hsv_d@Imath_2_5@@YA?AV?$Vec3@N@1@AEBV21@@Z
Microsoft (R) C++ Name Undecorator
Copyright (C) Microsoft Corporation. All rights reserved.

Undecoration of :- "?rgb2hsv_d@Imath_2_5@@YA?AV?$Vec3@N@1@AEBV21@@Z"
is :- "class Imath_2_5::Vec3<double> __cdecl Imath_2_5::rgb2hsv_d(class Imath_2_5::Vec3<double> const & __ptr64)"

[cbnflx]

I too am having this issue, I was curious if you ended up finding anything. My only guess was that OIIO was somehow looking for static ptex even during shared lib linking because of the __declspec(dllimport) prefix in the error and the following snippet in the Ptexture.h file

#if defined(_WIN32) || defined(_WINDOWS) || defined(_MSC_VER)
# ifndef PTEXAPI
#  ifndef PTEX_STATIC
#    ifdef PTEX_EXPORTS
#       define PTEXAPI __declspec(dllexport)
#    else
#       define PTEXAPI __declspec(dllimport)
#    endif
#  else
#    define PTEXAPI
#  endif
# endif
#else
#  ifndef PTEXAPI
#    define PTEXAPI
#  endif
#  ifndef DOXYGEN
#    define PTEX_USE_STDSTRING
#  endif
#endif

But I could not find anything in my OIIO vcxprojs or cmake files to suggest that OIIO is looking for static so I am scratching my head on this as well.

EDIT:
Turns out USD solved this themselves (from their build_usd.py file)

        # Ptex has a bug where the import library for the dynamic library and
        # the static library both get the same name, Ptex.lib, and as a
        # result one clobbers the other. We hack the appropriate CMake
        # file to prevent that. Since we don't need the static library we'll
        # rename that.
        #
        # In addition src\tests\CMakeLists.txt adds -DPTEX_STATIC to the 
        # compiler but links tests against the dynamic library, causing the 
        # links to fail. We patch the file to not add the -DPTEX_STATIC
        PatchFile('src\\ptex\\CMakeLists.txt', 
                  [("set_target_properties(Ptex_static PROPERTIES OUTPUT_NAME Ptex)",
                    "set_target_properties(Ptex_static PROPERTIES OUTPUT_NAME Ptexs)")])
        PatchFile('src\\tests\\CMakeLists.txt',
                  [("add_definitions(-DPTEX_STATIC)", 
                    "# add_definitions(-DPTEX_STATIC)")])

Updating those files fixed it for me

[davvid]

Oh, nice find! We don't actually use the static libs much, and Windows even less, so this is a blind spot for us on Linux where we have libPtex.so and libPtex.a that don't conflict.

We should probably add some notes to the README about the PTEX_BUILD_STATIC_LIBS and PTEX_BUILD_SHARED_LIBS controls that the build system supports. They both default to ON, so disabling one and enabling another explicitly should be a way to fix the build without any build tweaks on Windows.

I'll leave this issue open since we should probably change this so that the static lib are output as libPtex-static.a (aka Ptex-static.lib). That should resolve this issue if I'm understanding this correctly. Does that sound about right?

Heads-up @sunyab ~ hopefully that'll simplify build_usd.py too.

[NeedsMoar]

The DLLImport thing is sort of a red herring, it's only there to generate headers for things that link to the DLL and need to know about the class interfaces so the export decls get put on the functions during the build and the headers are generated with the import symbols.

Normally you build the shared and static libs by setting two targets in CMake with different names (not output names), one with static and one with shared linkage... it'll naturally put them in different output directories and use the add_library name as the base name. This is cleaner because it makes CMake auto-sort things into the right places vs trying to find where you buried the output name definition and it allows importing from the project using the shared or static name and having everything else automagically work.

See this -- it's supposed to be controlled with the output directory variables, then whatever wants to link to it uses that structure if it's not integrating with the project CMakeFiles or selects shared vs. static linkage using the variables cmake creates in its caches (see this).