Windows (and by extension Visual Studio) does not have any way to let alter the criteria where a particular dll is found by modifying the dll itself. You can alter the run time search criteria by several means but that isn't any part of the dll itself. This is very unlike osx or linux dynamic linker and their rpath and associated functionality.
- James On Apr 14, 2013, at 12:46 PM, Alexandre Gauthier wrote: > Well in the input files to link against I specified to link against Half.lib > (among others). > Since openEXR was compiled as dynamic build (dll), I think it is loading > Half.dll ...maybe I didn't specified correctly the location of Half.dll, > though I don't know how to tell visual to look for a specific location for > the dll's (a part from the build dir) > > > On Sun, Apr 14, 2013 at 8:12 PM, Simon Eves <si...@eves.us> wrote: > I'm pretty sure that toFloat.h is not supposed to be a public header for > OpenEXR, copied to the deploy folder. It's internal to the OpenEXR build, and > the values get embedded as binary in Half.dll. > > If the OpenEXR build itself didn't fail, then that is surely happening > correctly. > > Are you sure you have Half.dll (or rather, Half.lib) in the libraries-to-link > for your application build? > > > On Sun, Apr 14, 2013 at 10:57 AM, Alexandre Gauthier <immaresp...@gmail.com> > wrote: > Indeed the toFloat.h is autogenerated. > In the include folder of my project I reference only the headers that were > copied to the Deploy folder when I compiled OpenEXR, not toFloat.h. Even when > adding toFloat.h to the headers of my project or to the Deploy folder it does > not compile. > I tried many things and I can't see any workaround besides changing the > sources right now > > > On Sun, Apr 14, 2013 at 7:38 PM, Simon Eves <si...@eves.us> wrote: > The toFloat.h header is supposed to be autogenerated, and just contains the > values for that assignment, which is why the #include is right there in the > .cpp file. > > I've not built OpenEXR for ages, so I have no idea why the stage that's > supposed to generate that file isn't running, but maybe this gives you a clue > where to look. > > > On Sun, Apr 14, 2013 at 10:35 AM, Alexandre Gauthier <immaresp...@gmail.com> > wrote: > Hello, > I recently compiled all the Ilmbase + OpenEXR for win32. > I compiled it using visual studio 2010, and I had to tweak the solution files > a little bit to make it work (there were some files missing in the solution). > Anyway, now I'm trying to use it in my application and here is the unresolved > external I get : > > error LNK2001: unresolved external symbol "private: static union half::uif > const * const half::_toFloat" (?_toFloat@half@@0QBTuif@1@B) > > > Any clue where it can come from? > > When looking at the sources in half.cpp I see : > > HALF_EXPORT_CONST half::uif half::_toFloat[1 << 16] = > #include "toFloat.h" > > is a statement like this normal? I've never seen such assignment before, > although I think it comes from somewhere else. > > Regards, > > Alexandre > > _______________________________________________ > Openexr-devel mailing list > Openexr-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/openexr-devel > > > > > -- > SUPPORT COMMUNITY THEATRE! > > > > > -- > SUPPORT COMMUNITY THEATRE! > > _______________________________________________ > Openexr-devel mailing list > Openexr-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/openexr-devel
_______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
