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

[Nick]

That looks like the output without the exports flag. The command line should be

Dumpbin /exports

Before I said with a dash, not slash. 
And it should give the same results on the dll as the lib. 

Sent from my iPhone

> On Jun 13, 2014, at 15:12, "Paul Miller" <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> 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> 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
>>>>> https://lists.nongnu.org/mailman/listinfo/openexr-devel
>>> 
>>> 
>>> _______________________________________________
>>> Openexr-devel mailing list
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/openexr-devel
> 
> 
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/openexr-devel