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

[Sebastian Elsner]

I tested the sidefx repo here and first it seemed to work, but my build 
env was screwed up. So after cleaning up folders and getting the paths 
straigt it fails with the error:
NMAKE : fatal error U1073: don't know how to make 
'R:\development\libraries\openexr\sidefx-openexr\OpenEXR\b44ExpLogTable.h'

This happens with vc9 and vc10, while building from Nicolas Yues Repo ( 
https://github.com/nyue/openexr) works.


Am 14.06.2014 00:48, schrieb 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
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/openexr-devel




Am 14.06.2014 00:48, schrieb 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
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/openexr-devel