ocio-dev@lists.aswf.io | link problem with Visual Studio 2012

Home Messages Hashtags Subgroups Calendar

Date Date 1 - 3 of 3

link problem with Visual Studio 2012

Jeremy Selan <jeremy...@...>

#1511

Are you using the proper generated headers? Are you overriding so version in CMake?

All the symbols are in OpenColorIO::v0, and I would expect them to be in v1 (corresponding to the major version).

See https://github.com/imageworks/OpenColorIO/blob/master/export/OpenColorIO/OpenColorABI.h.in

#define OCIO_NAMESPACE_ENTER namespace OCIO_NAMESPACE { namespace OCIO_VERSION_NS

#define OCIO_VERSION_NS v@SOVERSION@

https://github.com/imageworks/OpenColorIO/blob/master/CMakeLists.txt

set(OCIO_VERSION_MAJOR 1)

set(OCIO_VERSION_MINOR 0)

set(OCIO_VERSION_PATCH 9)

set(SOVERSION ${OCIO_VERSION_MAJOR} CACHE STRING "Set the SO version in the SO name of the output library")

Show quoted text

On Mon, Dec 5, 2016 at 10:24 AM, Paul Miller <pa...@...> wrote:

I'm in the twilight zone today. After a bad merge from Mac->Windows, my application will no longer link against the shared OpenColorIO.lib on Windows, using Visual Studio 2012. This is the exact same set of headers and .lib I've been using for over a year.

The link errors are all like this one:

error LNK2019: unresolved external symbol "__declspec(dllimport) public: static int __cdecl OpenColorIO::v0::FileTransform::getNumFormats(void)" (__imp_?getNumFormats@FileTransform@v0@OpenColorIO@@SAHXZ)

and there seems to be an error for every OCIO function or definition I make use of, including:

error LNK2001: unresolved external symbol "__declspec(dllimport) char const * const OpenColorIO::v0::ROLE_DATA" (__imp_?ROLE_DATA@v0@OpenColorIO@@3PEBDEB)
error LNK2001: unresolved external symbol "__declspec(dllimport) char const * const OpenColorIO::v0::ROLE_COLOR_PICKING" (__imp_?ROLE_COLOR_PICKING@v0@OpenColorIO@@3PEBDEB)
error LNK2001: unresolved external symbol "__declspec(dllimport) char const * const OpenColorIO::v0::ROLE_SCENE_LINEAR" (__imp_?ROLE_SCENE_LINEAR@v0@OpenColorIO@@3PEBDEB)

Just for fun I cloned the current OCIO master branch, ran cmake on it, and rebuilt. I did have to make one change to OpenColorABI.h, and that is to get it to use <memory> and std::shared_ptr instead of boost or the tr1 stuff:

#elif defined(_LIBCPP_VERSION) || defined(WIN32)
#include <memory>
#define OCIO_SHARED_PTR std::shared_ptr
#define OCIO_DYNAMIC_POINTER_CAST std::dynamic_pointer_cast

But that's a minor change.

I'm linking with OpenColorIO.lib, but the linker is acting like nothing is being exported from it.

Has anyone else experienced anything like this?

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Dithermaster <dither...@...>

#1513

Is this 32-bit or 64-bit? If 32-bit, did you change the default calling convention in your project (__cdecl vs __stdcall)? Undecorated headers with .lib files that use the default convention will fail if you've changed the default convention. In 64-bit this is moot since it's all __fastcall.

Show quoted text

On Mon, Dec 5, 2016 at 12:42 PM, Jeremy Selan <jeremy...@...> wrote:

Are you using the proper generated headers? Are you overriding so version in CMake?

All the symbols are in OpenColorIO::v0, and I would expect them to be in v1 (corresponding to the major version).

See https://github.com/imageworks/OpenColorIO/blob/master/export/OpenColorIO/OpenColorABI.h.in

#define OCIO_NAMESPACE_ENTER namespace OCIO_NAMESPACE { namespace OCIO_VERSION_NS

#define OCIO_VERSION_NS v@SOVERSION@

https://github.com/imageworks/OpenColorIO/blob/master/CMakeLists.txt
set(OCIO_VERSION_MAJOR 1)
set(OCIO_VERSION_MINOR 0)
set(OCIO_VERSION_PATCH 9)

set(SOVERSION ${OCIO_VERSION_MAJOR} CACHE STRING "Set the SO version in the SO name of the output library")

On Mon, Dec 5, 2016 at 10:24 AM, Paul Miller <pa...@...> wrote:
I'm in the twilight zone today. After a bad merge from Mac->Windows, my application will no longer link against the shared OpenColorIO.lib on Windows, using Visual Studio 2012. This is the exact same set of headers and .lib I've been using for over a year.

The link errors are all like this one:

error LNK2019: unresolved external symbol "__declspec(dllimport) public: static int __cdecl OpenColorIO::v0::FileTransform::getNumFormats(void)" (__imp_?getNumFormats@FileTransform@v0@OpenColorIO@@SAHXZ)

and there seems to be an error for every OCIO function or definition I make use of, including:

error LNK2001: unresolved external symbol "__declspec(dllimport) char const * const OpenColorIO::v0::ROLE_DATA" (__imp_?ROLE_DATA@v0@OpenColorIO@@3PEBDEB)
error LNK2001: unresolved external symbol "__declspec(dllimport) char const * const OpenColorIO::v0::ROLE_COLOR_PICKING" (__imp_?ROLE_COLOR_PICKING@v0@OpenColorIO@@3PEBDEB)
error LNK2001: unresolved external symbol "__declspec(dllimport) char const * const OpenColorIO::v0::ROLE_SCENE_LINEAR" (__imp_?ROLE_SCENE_LINEAR@v0@OpenColorIO@@3PEBDEB)

Just for fun I cloned the current OCIO master branch, ran cmake on it, and rebuilt. I did have to make one change to OpenColorABI.h, and that is to get it to use <memory> and std::shared_ptr instead of boost or the tr1 stuff:

#elif defined(_LIBCPP_VERSION) || defined(WIN32)
#include <memory>
#define OCIO_SHARED_PTR std::shared_ptr
#define OCIO_DYNAMIC_POINTER_CAST std::dynamic_pointer_cast

But that's a minor change.

I'm linking with OpenColorIO.lib, but the linker is acting like nothing is being exported from it.

Has anyone else experienced anything like this?

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Paul Miller <pa...@...>

#1514

On 12/5/2016 4:12 PM, Dithermaster wrote:
Is this 32-bit or 64-bit? If 32-bit, did you change the default calling
convention in your project (__cdecl vs __stdcall)? Undecorated headers
with .lib files that use the default convention will fail if you've
changed the default convention. In 64-bit this is moot since it's
all __fastcall.No, 64 bit only.

I used the default cmake settings, though I did run cmake and build with cygwin in my path (so "patch" would work when building tinyxml).

I'll look into the v0 vs v1 issue - that looks like it may be the culprit.


On Mon, Dec 5, 2016 at 12:42 PM, Jeremy Selan <jeremy...@...
<mailto:jeremy...@...>> wrote:

    Are you using the proper generated headers? Are you overriding so
    version in CMake?

    All the symbols are in OpenColorIO::v0, and I would expect them to
    be in v1 (corresponding to the major version).

    See https://github.com/imageworks/OpenColorIO/blob/master/export/OpenColorIO/OpenColorABI.h.in
    <https://github.com/imageworks/OpenColorIO/blob/master/export/OpenColorIO/OpenColorABI.h.in>

    #define OCIO_NAMESPACE_ENTER namespace OCIO_NAMESPACE { namespace
    OCIO_VERSION_NS

    #define OCIO_VERSION_NS v@SOVERSION@


    https://github.com/imageworks/OpenColorIO/blob/master/CMakeLists.txt
    <https://github.com/imageworks/OpenColorIO/blob/master/CMakeLists.txt>
    set(OCIO_VERSION_MAJOR 1)
    set(OCIO_VERSION_MINOR 0)
    set(OCIO_VERSION_PATCH 9)


    set(SOVERSION ${OCIO_VERSION_MAJOR}CACHESTRING "Set the SO version
    in the SO name of the output library")



    On Mon, Dec 5, 2016 at 10:24 AM, Paul Miller <pa...@...
    <mailto:pa...@...>> wrote:

        I'm in the twilight zone today. After a bad merge from
        Mac->Windows, my application will no longer link against the
        shared OpenColorIO.lib on Windows, using Visual Studio 2012.
        This is the exact same set of headers and .lib I've been using
        for over a year.

        The link errors are all like this one:

        error LNK2019: unresolved external symbol "__declspec(dllimport)
        public: static int __cdecl
        OpenColorIO::v0::FileTransform::getNumFormats(void)"
        (__imp_?getNumFormats@FileTransform@v0@OpenColorIO@@SAHXZ)

        and there seems to be an error for every OCIO function or
        definition I make use of, including:

        error LNK2001: unresolved external symbol "__declspec(dllimport)
        char const * const OpenColorIO::v0::ROLE_DATA"
        (__imp_?ROLE_DATA@v0@OpenColorIO@@3PEBDEB)
        error LNK2001: unresolved external symbol "__declspec(dllimport)
        char const * const OpenColorIO::v0::ROLE_COLOR_PICKING"
        (__imp_?ROLE_COLOR_PICKING@v0@OpenColorIO@@3PEBDEB)
        error LNK2001: unresolved external symbol "__declspec(dllimport)
        char const * const OpenColorIO::v0::ROLE_SCENE_LINEAR"
        (__imp_?ROLE_SCENE_LINEAR@v0@OpenColorIO@@3PEBDEB)

        Just for fun I cloned the current OCIO master branch, ran cmake
        on it, and rebuilt. I did have to make one change to
        OpenColorABI.h, and that is to get it to use <memory> and
        std::shared_ptr instead of boost or the tr1 stuff:

        #elif defined(_LIBCPP_VERSION) || defined(WIN32)
        #include <memory>
        #define OCIO_SHARED_PTR std::shared_ptr
        #define OCIO_DYNAMIC_POINTER_CAST std::dynamic_pointer_cast

        But that's a minor change.

        I'm linking with OpenColorIO.lib, but the linker is acting like
        nothing is being exported from it.

        Has anyone else experienced anything like this?

        --
        You received this message because you are subscribed to the
        Google Groups "OpenColorIO Developers" group.
        To unsubscribe from this group and stop receiving emails from
        it, send an email to ocio-dev+u...@...
        <mailto:ocio-dev%2B...@...>.
        For more options, visit https://groups.google.com/d/optout
        <https://groups.google.com/d/optout>.


    --
    You received this message because you are subscribed to the Google
    Groups "OpenColorIO Developers" group.
    To unsubscribe from this group and stop receiving emails from it,
    send an email to ocio-dev+u...@...
    <mailto:ocio-dev+u...@...>.
    For more options, visit https://groups.google.com/d/optout
    <https://groups.google.com/d/optout>.


--
You received this message because you are subscribed to the Google
Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to ocio-dev+u...@...
<mailto:ocio-dev+u...@...>.
For more options, visit https://groups.google.com/d/optout.

1 - 3 of 3

Previous Topic Next Topic

Home Hashtags Subgroups Calendar Terms