openexr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Openexr-devel] [Half] Unresolved external when using Half.lib on wi


From: James Burgess
Subject: Re: [Openexr-devel] [Half] Unresolved external when using Half.lib on windows
Date: Sun, 14 Apr 2013 17:22:16 -0700

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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 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" (address@hidden@@address@hidden@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
address@hidden
https://lists.nongnu.org/mailman/listinfo/openexr-devel




--
SUPPORT COMMUNITY THEATRE!




--
SUPPORT COMMUNITY THEATRE!

_______________________________________________
Openexr-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/openexr-devel


reply via email to

[Prev in Thread] Current Thread [Next in Thread]