Re: looking for a working 2.0.1 Windows build
"Mike Wong | ax.gmail" <[email protected]>
| Newsgroups | gmane.comp.video.openexr.devel |
|---|---|
| Message-ID | <CAEmkyAvWKpAFXKkEdnRebiLMpgvRY1f8ZR34A0jfAxCtP5jbeA@mail.gmail.com> |
Attached is my build journal for vanilla 2.1.0, using vc10 with Intel compiler, I hope this has useful information for your porting. On Sat, Jun 14, 2014 at 3:49 PM, Sebastian Elsner <[email protected]> wrote: > 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" <[email protected]> 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 <[email protected] >>>> <mailto:[email protected]>> 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" <[email protected] >>>> <mailto:[email protected]>> 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" >>>> <[email protected] <mailto:[email protected]>> >>>> 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 *)" >>>> (__imp_??0ArgExc@Iex@@QEAA@__PEBD@Z) >>>> 2>ImfTiledOutputFile.obj : error LNK2001: unresolved >>>> external symbol "__declspec(dllimport) public: >>>> __cdecl Iex::ArgExc::ArgExc(char const *)" >>>> (__imp_??0ArgExc@Iex@@QEAA@__PEBD@Z) >>>> 2>ImfTileOffsets.obj : error LNK2001: unresolved >>>> external symbol "__declspec(dllimport) public: >>>> __cdecl Iex::ArgExc::ArgExc(char const *)" >>>> (__imp_??0ArgExc@Iex@@QEAA@__PEBD@Z) >>>> 2>ImfTimeCode.obj : error LNK2001: unresolved >>>> external symbol "__declspec(dllimport) public: >>>> __cdecl Iex::ArgExc::ArgExc(char const *)" >>>> (__imp_??0ArgExc@Iex@@QEAA@__PEBD@Z) >>>> ... >>>> 2>ImfInputFile.obj : error LNK2001: unresolved >>>> external symbol "__declspec(dllimport) public: >>>> __cdecl IlmThread::Mutex::Mutex(void)" >>>> (__imp_??0Mutex@IlmThread@@__QEAA@XZ) >>>> 2>ImfMultiPartInputFile.obj : error LNK2001: >>>> unresolved external symbol "__declspec(dllimport) >>>> public: __cdecl IlmThread::Mutex::Mutex(void)" >>>> (__imp_??0Mutex@IlmThread@@__QEAA@XZ) >>>> 2>ImfAttribute.obj : error LNK2001: unresolved >>>> external symbol "__declspec(dllimport) public: >>>> __cdecl IlmThread::Mutex::Mutex(void)" >>>> (__imp_??0Mutex@IlmThread@@__QEAA@XZ) >>>> 2>ImfDeepScanLineInputFile.obj : error LNK2001: >>>> unresolved external symbol "__declspec(dllimport) >>>> public: __cdecl IlmThread::Mutex::Mutex(void)" >>>> (__imp_??0Mutex@IlmThread@@__QEAA@XZ) >>>> 2>ImfDeepScanLineOutputFile.__obj : error LNK2001: >>>> unresolved external symbol "__declspec(dllimport) >>>> public: __cdecl IlmThread::Mutex::Mutex(void)" >>>> (__imp_??0Mutex@IlmThread@@__QEAA@XZ) >>>> ... >>>> 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 >>>> [email protected] >>>> <mailto:[email protected]> >>>> https://lists.nongnu.org/__ >>>> mailman/listinfo/openexr-devel >>>> <https://lists.nongnu.org/ >>>> mailman/listinfo/openexr-devel> >>>> >>>> >>>> >>>> _________________________________________________ >>>> Openexr-devel mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.nongnu.org/__mailman/listinfo/openexr-devel >>>> <https://lists.nongnu.org/mailman/listinfo/openexr-devel> >>>> >>>> >>>> >>>> _________________________________________________ >>>> Openexr-devel mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.nongnu.org/__mailman/listinfo/openexr-devel >>>> <https://lists.nongnu.org/mailman/listinfo/openexr-devel> >>>> >>> _______________________________________________ >>> Openexr-devel mailing list >>> [email protected] >>> https://lists.nongnu.org/mailman/listinfo/openexr-devel >>> >> _______________________________________________ >> Openexr-devel mailing list >> [email protected] >> 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" <[email protected]> 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 <[email protected] >>>> <mailto:[email protected]>> 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" <[email protected] >>>> <mailto:[email protected]>> 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" >>>> <[email protected] <mailto:[email protected]>> >>>> 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 *)" >>>> (__imp_??0ArgExc@Iex@@QEAA@__PEBD@Z) >>>> 2>ImfTiledOutputFile.obj : error LNK2001: unresolved >>>> external symbol "__declspec(dllimport) public: >>>> __cdecl Iex::ArgExc::ArgExc(char const *)" >>>> (__imp_??0ArgExc@Iex@@QEAA@__PEBD@Z) >>>> 2>ImfTileOffsets.obj : error LNK2001: unresolved >>>> external symbol "__declspec(dllimport) public: >>>> __cdecl Iex::ArgExc::ArgExc(char const *)" >>>> (__imp_??0ArgExc@Iex@@QEAA@__PEBD@Z) >>>> 2>ImfTimeCode.obj : error LNK2001: unresolved >>>> external symbol "__declspec(dllimport) public: >>>> __cdecl Iex::ArgExc::ArgExc(char const *)" >>>> (__imp_??0ArgExc@Iex@@QEAA@__PEBD@Z) >>>> ... >>>> 2>ImfInputFile.obj : error LNK2001: unresolved >>>> external symbol "__declspec(dllimport) public: >>>> __cdecl IlmThread::Mutex::Mutex(void)" >>>> (__imp_??0Mutex@IlmThread@@__QEAA@XZ) >>>> 2>ImfMultiPartInputFile.obj : error LNK2001: >>>> unresolved external symbol "__declspec(dllimport) >>>> public: __cdecl IlmThread::Mutex::Mutex(void)" >>>> (__imp_??0Mutex@IlmThread@@__QEAA@XZ) >>>> 2>ImfAttribute.obj : error LNK2001: unresolved >>>> external symbol "__declspec(dllimport) public: >>>> __cdecl IlmThread::Mutex::Mutex(void)" >>>> (__imp_??0Mutex@IlmThread@@__QEAA@XZ) >>>> 2>ImfDeepScanLineInputFile.obj : error LNK2001: >>>> unresolved external symbol "__declspec(dllimport) >>>> public: __cdecl IlmThread::Mutex::Mutex(void)" >>>> (__imp_??0Mutex@IlmThread@@__QEAA@XZ) >>>> 2>ImfDeepScanLineOutputFile.__obj : error LNK2001: >>>> unresolved external symbol "__declspec(dllimport) >>>> public: __cdecl IlmThread::Mutex::Mutex(void)" >>>> (__imp_??0Mutex@IlmThread@@__QEAA@XZ) >>>> ... >>>> 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 >>>> [email protected] >>>> <mailto:[email protected]> >>>> https://lists.nongnu.org/__ >>>> mailman/listinfo/openexr-devel >>>> <https://lists.nongnu.org/ >>>> mailman/listinfo/openexr-devel> >>>> >>>> >>>> >>>> _________________________________________________ >>>> Openexr-devel mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.nongnu.org/__mailman/listinfo/openexr-devel >>>> <https://lists.nongnu.org/mailman/listinfo/openexr-devel> >>>> >>>> >>>> >>>> _________________________________________________ >>>> Openexr-devel mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.nongnu.org/__mailman/listinfo/openexr-devel >>>> <https://lists.nongnu.org/mailman/listinfo/openexr-devel> >>>> >>> >>> _______________________________________________ >>> Openexr-devel mailing list >>> [email protected] >>> https://lists.nongnu.org/mailman/listinfo/openexr-devel >>> >> _______________________________________________ >> Openexr-devel mailing list >> [email protected] >> https://lists.nongnu.org/mailman/listinfo/openexr-devel >> > > > _______________________________________________ > Openexr-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/openexr-devel > _______________________________________________ Openexr-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/openexr-devel
OpenEXR2.1.0Win64icl_14.0vc10BUILDJournal.pdf
(application/pdf, 123.5 KB) - not displayed