So... for me, just commenting out the "iex_debugTrap" function in the global namespace seems to solve the problem. (IexBaseExc.cpp) This function isn't called anywhere else in the ilmbase namespace, could it just be an error that it is here at all? This function is the only one I encounter a problem with.
On Wed, Jan 6, 2016 at 12:25 PM, Nick Porcino <[email protected]> wrote: > Not yet > > > > > > On Wed, Jan 6, 2016 at 11:30 AM -0800, "Christopher Horvath" < > [email protected]> wrote: > > Do you know of a workaround? > > On Wed, Jan 6, 2016 at 11:25 AM, Christopher Horvath < > [email protected]> wrote: > >> It's almost like they're breaking things on purpose. >> >> On Wed, Jan 6, 2016 at 11:22 AM, Nick Porcino <[email protected]> >> wrote: >> >>> Fwiw, this is a significant bug on OSX as well. IIRC They also export >>> Alembic symbols. Arrgh. >>> >>> >>> >>> >>> >>> On Wed, Jan 6, 2016 at 11:18 AM -0800, "Christopher Horvath" < >>> [email protected]> wrote: >>> >>> Hey folks, >>> >>> I'm emailing this list because I'm not sure who to ask. I am trying to >>> build an application on Windows that has both FBX and Alembic support, and >>> I am therefore linking against the ilmbase libraries, version 2.2.0. (with >>> namespacing). >>> >>> During linking, I get the following error in Visual Studio 2013: >>> Error 1 error LNK2005: "void __cdecl iex_debugTrap(void)" >>> (?iex_debugTrap@@YAXXZ) already defined in >>> libfbxsdk-mt.lib(IexBaseExc.obj) Iex-2_2.lib(IexBaseExc.cpp.obj) >>> >>> Does anyone have any experience with this? Is there any way I can get >>> around it, perhaps by fidgeting with the versioned namespace? Why would FBX >>> be exporting Iex symbols? >>> >>> I am running out of hair to pull out. >>> >>> Thanks in advance, >>> Chris >>> >> >> >
_______________________________________________ Openexr-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/openexr-devel
