[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Openexr-devel] looking for a working 2.0.1 Windows build
From: |
Nick |
Subject: |
Re: [Openexr-devel] looking for a working 2.0.1 Windows build |
Date: |
Fri, 13 Jun 2014 15:48:55 -0700 |
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
- Re: [Openexr-devel] looking for a working 2.0.1 Windows build, (continued)
- Re: [Openexr-devel] looking for a working 2.0.1 Windows build, Paul Miller, 2014/06/13
- Re: [Openexr-devel] looking for a working 2.0.1 Windows build, Nick, 2014/06/13
- Re: [Openexr-devel] looking for a working 2.0.1 Windows build, Paul Miller, 2014/06/13
- Re: [Openexr-devel] looking for a working 2.0.1 Windows build, Piotr Stanczyk, 2014/06/13
- Re: [Openexr-devel] looking for a working 2.0.1 Windows build, Sebastian Elsner, 2014/06/13
- Re: [Openexr-devel] looking for a working 2.0.1 Windows build, Paul Miller, 2014/06/13
- Re: [Openexr-devel] looking for a working 2.0.1 Windows build,
Nick <=
- Re: [Openexr-devel] looking for a working 2.0.1 Windows build, Halfdan Ingvarsson, 2014/06/13
- Re: [Openexr-devel] looking for a working 2.0.1 Windows build, Nick, 2014/06/13
- Re: [Openexr-devel] looking for a working 2.0.1 Windows build, Sebastian Elsner, 2014/06/14
- Re: [Openexr-devel] looking for a working 2.0.1 Windows build, Mike Wong | ax.gmail, 2014/06/14
- Re: [Openexr-devel] looking for a working 2.0.1 Windows build, Nicholas Yue, 2014/06/14
- Re: [Openexr-devel] looking for a working 2.0.1 Windows build, Brendan Bolles, 2014/06/14
- Re: [Openexr-devel] looking for a working 2.0.1 Windows build, Nicholas Yue, 2014/06/14
- Re: [Openexr-devel] looking for a working 2.0.1 Windows build, Brendan Bolles, 2014/06/16
- Re: [Openexr-devel] looking for a working 2.0.1 Windows build, Nick, 2014/06/16
- Re: [Openexr-devel] looking for a working 2.0.1 Windows build, Piotr Stanczyk, 2014/06/17