Re: [Openexr-devel] looking for a working 2.0.1 Windows build

[Nick]

In a similar vein (apologies if the same one?) -  if one does a clean pull of 
the sidefx fork, does it compile and build and pass unit tests out of the box?

Sent from my iPhone

> On Jun 13, 2014, at 15:36, "Paul Miller" <address@hidden> wrote:
> 
>> On 6/13/2014 5:22 PM, Piotr Stanczyk wrote:
>> Do the IlmBase tests pass?
> 
> No. All the tests fail with "***Exception: Other".
> Package is failing too - no "nsis" compiler whatever that is.
> 
> I had to run the compiler as Admin to get the "install" stage to work.
> 
>> 
>> 
>> On 13 June 2014 15:12, Paul Miller <address@hidden
>> <mailto:address@hidden>> wrote:
>> 
>>    On 6/13/2014 4:43 PM, Nick wrote:
>> 
>>        I guess I should ask the obvious question, is Iex.lib itself on
>>        the link line? If yes, the next thing I would check is if a
>>        dumpbin -exports actually lists the symbols the linker complains
>>        as missing. If yes, I would look for a zombie copy of the link
>>        lib somehow polluting your environment. For example, is an old
>>        copy around as part of someone else's sdk? Much as the cuda sdk
>>        used to drag around an antique copy of glew, causing endless
>>        late night fun until we found the errant libs and got out the
>>        flamethrower.
>> 
>> 
>>    This is weird - dumpbin Iex-2_1.lib doesn't list any symbols at all:
>> 
>>    Dump of file Iex-2_1.lib
>> 
>>    File Type: LIBRARY
>> 
>>       Summary
>> 
>>               C3 .debug$S
>>               14 .idata$2
>>               14 .idata$3
>>                8 .idata$4
>>                8 .idata$5
>>                C .idata$6
>> 
>>    The projects for IlmBase were generated by cmake-gui, and everything
>>    looks ok there. I didn't see any options for controlling namespaces
>>    or anything.
>> 
>>    Other than telling cmake where zlib was, everything seemed to build
>>    fine.
>> 
>> 
>> 
>>        Sent from my iPhone
>> 
>>            On Jun 13, 2014, at 14:12, "Paul Miller" <address@hidden
>>            <mailto:address@hidden>> wrote:
>> 
>>                On 6/13/2014 2:50 PM, Nick wrote:
>>                That happens when you build without the DLL macros set
>>                up for export. Have a look at IexExport.h and you can
>>                follow the breadcrumbs backwards from there. I'm not
>>                currently set up for windows dev so I can't help much
>>                beyond that at the moment.
>> 
>> 
>>            That's the confusing thing - everything looks right with the
>>            DLL macros.
>> 
>>            The IlmBase libraries all have OPENEXR_DLL set, and the
>>            appropriate XXX_EXPORTS set. The relevant XXXExport.h
>>            headers all show XXX_EXPORT_DEFINITION ending up as
>>            __declspec(dllexport) where appropriate, and
>>            __declspec(dllimport) when included in IlmImf.
>> 
>>            Anything else worth checking?
>> 
>> 
>> 
>>                Sent from my iPhone
>> 
>>                        On Jun 13, 2014, at 12:34, "Paul Miller"
>>                        <address@hidden <mailto:address@hidden>> wrote:
>> 
>>                            On 6/10/2014 7:45 AM, Paul Miller wrote:
>>                            On 5/30/2014 10:51 AM, Piotr Stanczyk wrote:
>>                            As you can tell the windows platform does
>>                            not receive a large amount of
>>                            time. I would urge you to go with 2.1.0 and
>>                            use the cmake scripts rather
>>                            than the solution files.  I believe you can
>>                            generate the son files from
>>                            there should you need to, but they should
>>                            give you a build for the most
>>                            part.
>> 
>>                            Indeed, I would be happy to see the baked
>>                            sln stuff go away in the
>>                            future.
>> 
>> 
>>                        Thanks to all who responded. I didn't know there
>>                        was a cmake-based 2.1 -
>>                        that should make things easier.
>> 
>> 
>>                    So I've gotten pretty far with the latest 2.1 branch
>>                    - IlmBase is building with no problems that I can see.
>> 
>>                    But when I'm linking IlmImf, I'm getting hundreds of
>>                    "unresolved external symbol" errors, such as:
>> 
>>                    2>ImfTiledMisc.obj : error LNK2001: unresolved
>>                    external symbol "__declspec(dllimport) public:
>>                    __cdecl Iex::ArgExc::ArgExc(char const *)"
>>                    (address@hidden@@address@hidden@Z)
>>                    2>ImfTiledOutputFile.obj : error LNK2001: unresolved
>>                    external symbol "__declspec(dllimport) public:
>>                    __cdecl Iex::ArgExc::ArgExc(char const *)"
>>                    (address@hidden@@address@hidden@Z)
>>                    2>ImfTileOffsets.obj : error LNK2001: unresolved
>>                    external symbol "__declspec(dllimport) public:
>>                    __cdecl Iex::ArgExc::ArgExc(char const *)"
>>                    (address@hidden@@address@hidden@Z)
>>                    2>ImfTimeCode.obj : error LNK2001: unresolved
>>                    external symbol "__declspec(dllimport) public:
>>                    __cdecl Iex::ArgExc::ArgExc(char const *)"
>>                    (address@hidden@@address@hidden@Z)
>>                    ...
>>                    2>ImfInputFile.obj : error LNK2001: unresolved
>>                    external symbol "__declspec(dllimport) public:
>>                    __cdecl IlmThread::Mutex::Mutex(void)"
>>                    (address@hidden@@address@hidden)
>>                    2>ImfMultiPartInputFile.obj : error LNK2001:
>>                    unresolved external symbol "__declspec(dllimport)
>>                    public: __cdecl IlmThread::Mutex::Mutex(void)"
>>                    (address@hidden@@address@hidden)
>>                    2>ImfAttribute.obj : error LNK2001: unresolved
>>                    external symbol "__declspec(dllimport) public:
>>                    __cdecl IlmThread::Mutex::Mutex(void)"
>>                    (address@hidden@@address@hidden)
>>                    2>ImfDeepScanLineInputFile.obj : error LNK2001:
>>                    unresolved external symbol "__declspec(dllimport)
>>                    public: __cdecl IlmThread::Mutex::Mutex(void)"
>>                    (address@hidden@@address@hidden)
>>                    2>ImfDeepScanLineOutputFile.__obj : error LNK2001:
>>                    unresolved external symbol "__declspec(dllimport)
>>                    public: __cdecl IlmThread::Mutex::Mutex(void)"
>>                    (address@hidden@@address@hidden)
>>                    ...
>>                    etc.
>> 
>>                    I pointed the IlmImf linker to the built *.libs from
>>                    IlmBase, so I don't know what is causing this.
>> 
>>                    I've gotten some build tips from Sebastian but I'm
>>                    using VS2008 here and he's using 2010, and doesn't
>>                    seem to be getting these errors.
>> 
>>                    Anyone know what is going on?
>> 
>> 
>>                    _________________________________________________
>>                    Openexr-devel mailing list
>>                    address@hidden
>>                    <mailto:address@hidden>
>>                    https://lists.nongnu.org/__mailman/listinfo/openexr-devel
>>                    <https://lists.nongnu.org/mailman/listinfo/openexr-devel>
>> 
>> 
>> 
>>            _________________________________________________
>>            Openexr-devel mailing list
>>            address@hidden <mailto:address@hidden>
>>            https://lists.nongnu.org/__mailman/listinfo/openexr-devel
>>            <https://lists.nongnu.org/mailman/listinfo/openexr-devel>
>> 
>> 
>> 
>>    _________________________________________________
>>    Openexr-devel mailing list
>>    address@hidden <mailto:address@hidden>
>>    https://lists.nongnu.org/__mailman/listinfo/openexr-devel
>>    <https://lists.nongnu.org/mailman/listinfo/openexr-devel>
> 
> 
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/openexr-devel