openexr-devel
[Top][All Lists]
Advanced

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

RE: [Openexr-devel] OpenEXR 1.6.0, library issues under Windows


From: Nick Porcino
Subject: RE: [Openexr-devel] OpenEXR 1.6.0, library issues under Windows
Date: Mon, 27 Aug 2007 09:35:05 -0700

The reason it didn't work is because the linking libraries internally
encode the name of the DLL to load. So renaming a DLL won't cause the
lib to rebind - it'll still bind to whatever it was compiled for.

-----Original Message-----
From: address@hidden
[mailto:address@hidden On
Behalf Of Ben Ochoa
Sent: Sunday, August 26, 2007 10:51 PM
To: address@hidden
Subject: Re: [Openexr-devel] OpenEXR 1.6.0, library issues under Windows

Renaming the debug stub libraries and DLLs didn't work---linked to the 
debug stub libraries, but loaded the release DLLs.  Looks like the vc 
solution will need to be modified to output DLLs of the desired name.

Ben

On 8/26/2007 8:18 AM, Luc-Eric Rousseau wrote:
>  > I don't want to have copies of the OpenEXR
>  >debug/release DLLs in the same directory
>  > as my debug/release application
>  >executable.  As such, the OpenEXR DLLs will need to be in my path.
> 
> Well, that's how everywhere I've worked (Microsoft,
> Avide, Corel, Softimage) works. MFC and VC++'s DLL
> have different names because the release
> version ships with Windows in the Windows directory,
> but most third-party DLLs do not.
> 
> First, VC++ allows you to specify different startup
> folders for Debug and Release, in the Debug tab
> of the solution.  You specify there what is the
> current directory to use when you run your app from
> VC++, that could be the folder where the appropriate
> .DLLs are located.
> 
> Secondly, Visual C++ by default put the resulting .exe in a
> debug directory underneath your solution, along with the .objs. 
> But that's not where you want it, as soon as you begin
> to use .dlls. You want go and change the linker options
> so that your .exe and .dlls are produced
> in a global directory like \Myapp\Debug\bin and
> \MyApp\Release\Bin.  The .obj files and other
> temp file remain in the sub-folder of the solution.
> 
> You put your own .dll and the third party .dlls
> in that global folder.  When you do a 'clean build'
> from VC++, it will not delete the third-party .dlls
> 
> In any case, if you do not want any of this,
> if I'm not mistaken all you need to do is copy the
> debug openexr .lib and .dll to new names.
> 
> -----Original Message-----
> From: Ben Ochoa [mailto:address@hidden
> Sent: Sun 8/26/2007 2:15 AM
> To: Luc-Eric Rousseau
> Subject: Re: [Openexr-devel] OpenEXR 1.6.0, library issues under
Windows
> 
> Yes; if one's workflow is as you suggest, then this is not a problem.
> However, under Windows, third-party debug and release .lib and .dll
> files are typically named differently due to the convention that
> Microsoft established long ago and continues to use.  Agree with it or
> not, Windows third-party library producers usually follow this
> convention, even for open source libraries (e.g., ImageMagick).
> 
> The problem is only with debug and release DLLs of the same name, not
> the .lib files.  DLLs must reside in the path or the same folder as
the
> application that loads them.  Let's say that I'm developing an
> application that uses OpenEXR and for some reason (you don't need to
> agree with the reason), I don't want to have copies of the OpenEXR
> debug/release DLLs in the same directory as my debug/release
application
> executable.  As such, the OpenEXR DLLs will need to be in my path.
> Here's where there are problems.  If I'm executing the release build
of
> the application, then I need the OpenEXR release DLL in my path, but
if
> I'm executing the debug build, then the debug DLL needs to be in my
> path.  I don't want to have to change the path to depend on whether or
> not I'm executing the release or debug version, but I must if the
debug
> and release DLLs have the same name.  If they have different names,
then
> there are not any problems.  Further, if they have different names,
then
> they can even reside in the same directory, as was done in OpenEXR
1.4.0.
> 
> If I could link to OpenEXR static libraries, then I would do so and
same
> named release and debug DLLs wouldn't concern me as much.  Perhaps
> someone can address modification of the vc8 solution to include
> configurations for building static debug and static release libraries.
> 
> Ben
> 
> On 8/25/2007 6:08 PM, Luc-Eric Rousseau wrote:
>  > This sounds like a problem with the way your work is setup.
>  > The difference between a Debug and Release builds should only be
the
>  > compilation flags, including the path where to get the libraries.
>  > The list of files and dependencies should normally be the same for
all
>  > configurations.
>  >
>  > Having different names for .lib and .dll between Debug and Release
is
>  > indeed one way to work, but there is no advantages to that, and
>  > there are disadvantages in maintenance of makefiles and setups, and
build
>  > machines.  It's just not how things are done in most places.
>  >
>  > You're supposed to specify a different library directory for Debug
>  > and Release configuration in the linker options
http://tinyurl.com/23fp54
>  > Perhaps you are using a global Library path in the user preference
and
>  > put both the Debug and Release .lib in the same directory, which
you
>  > shouldn't
>  > be doing.   When there are different Debug and Release versions of
a
>  > library,
>  > you need to specify the directory as part of the configuration of
the 
> Visual
>  > Studio project.
>  >
>  > In the same way, you're supposed to produce your Debug and Release
>  > executables
>  > in different folders, along with the appropriate Debug and Release
>  > third-party .dlls
>  >
>  >
>  > -----Original Message-----
>  > From: Ben Ochoa
>  > Sent: Fri 8/24/2007 1:14 PM
>  > To: address@hidden
>  > Subject: [Openexr-devel] OpenEXR 1.6.0, library issues under
Windows
>  >
>  > I've been using OpenEXR 1.4.0 in Windows applications for the past
year
>  > and just tried OpenEXR 1.6.0.  I'm encountering some issues using
the
>  > 1.6.0 libraries in my applications due to conflicting release and
debug
>  > libraries.  I believe that a different directory structure and file
>  > naming convention would resolve these issues.
>  >
>  > For OpenEXR 1.4.0, I use the `pre-compiled for Windows, Visual
Studio
>  > .NET 2005' package.  The 1.4.0 pre-compiled package placed the .lib
and
>  > .dll files in the lib and bin directories, and named the files
according
>  > to the four possible library configurations (e.g., for Half, there
is
>  > Half.lib (static release), Half_d.lib (static debug), Half_dll.lib
and
>  > Half_dll.dll (DLL release), and Half_dll_d.lib and Half_dll_d.dll
(DLL
>  > debug).  For my applications, I always linked to either the static
or
>  > static debug libraries for the respective release or debug build of
my
>  > applications.
>  >
>  > Since a similar pre-compiled package is not currently available for
>  > OpenEXR 1.6.0, I compiled it from source using the vc8 solution.
>  > Compiling 1.6.0 from source only provides configurations for
creating
>  > DLLs.  Although it creates debug and release libraries in different
>  > directories, the file names are the same (e.g., for Half, there is
>  > lib\Release\Half.lib and bin\Release\Half.dll (DLL), and
>  > lib\Debug\Half.lib and \bin\Debug\Half.dll (DLL debug).  It would
be
>  > great if the solution could be modified to create a directory
structure
>  > and file naming convention similar to 1.4.0, doing away with the
Release
>  > and Debug subdirectories, and placing both debug and release files
in
>  > the bin and lib directories, but with different names.  It would be
nice
>  > if the solution also contained configurations for building debug
and
>  > release static libraries, again placing them in the same bin and
lib
>  > directories.
>  >
>  > I don't know Visual Studio well enough to make these changes
myself, but
>  > perhaps someone else does.  Would anyone else benefit from these
changes?
>  >
>  > Thanks,
>  > Ben
>  >
>  >
>  > _______________________________________________
>  > Openexr-devel mailing list
>  > address@hidden
>  > http://lists.nongnu.org/mailman/listinfo/openexr-devel
>  >
>  >
>  >
>  >
------------------------------------------------------------------------
>  >
>  > _______________________________________________
>  > Openexr-devel mailing list
>  > address@hidden
>  > http://lists.nongnu.org/mailman/listinfo/openexr-devel
> 


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





reply via email to

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