Pre-built libraries/examples for Windows?
Paul Miller
I'll probably end up just compiling the code directly in anyway, but I want to get built tools to play around with how it's "supposed to work" before I dive in.
Thanks!
Jeremy Selan
We're sorry you're having difficulties building OCIO on Windows.
Unfortunately, I dont have daily access to a Windows machine for
testing, but I know the Foundry is successfully using OCIO on Windows.
I will contact them and see if they can assist us, and possibly
release step by step Windows OCIO build instructions.
Making the installation process simpler (perhaps including binary
installs) is one of my top summer goals, and we'll make sure to
include windows support in this task.
https://github.com/imageworks/OpenColorIO/issues/99
-- Jeremy
Peter
I've also been working on gettting a windows version of the OCIO
libraries here, and I ran into similar problems to you.
We managed to build the GCC version fine, but on windows I resorted to
just manually setting up a VC2005 project and pulling in whatever
files were necessary.
I'm hoping to look in to the cmake problems further this week so that
we can get a consistent build sytem across all platforms here. I''ll
post here anything I find out, and if you have any insights in this
area please feel free to share them with me too ;)
Regards,
Peter.
Colin Doncaster
Cmake seems to generate usable MSCV 2008 solutions for me when I do
cmake -G "Visual Studio 9 2008 Win64" ..
in the build dir.
There were a few changes I've had to make to successfully compile the OpenColorIO.lib file, here's a quick list
- I had to download patch for windows, this comes with Cygwin so just make sure that's in your PATH environment
- I added an if( NOT WIN32 ) around the CMAKE_CXX_FLAGS as the compiler wasn't happy with most of them
- I had to use _DUSE_BOOST_PTR=ON and then added INCLUDE_DIRECTORIES ( ${Boost_INCLUDE_DIRS} ) to the CMake file ( I assume everyone else has boost in their global search paths on *nix systems? )
- I had to have add_definitions("-DWIN64") as the yaml code uses that vs WIN32 to determine if it needs GCC specific template definitions
- defined an isnan to replace the missing std::isnan
- realpath doesn't exist on Windows so I had to put PathCanonicalize in a define instead and include Shlwapi.lib
- fixed the cmake file as the yaml and tinyxml STATIC_LINK paths are explicitly pointing at *nix library names ( libtinyxml.a instead of tinyxml.lib )
That seems to build fine.
Just to re-iterate though, the issue wasn't with CMake not working.
I can fork OCIO and make these changes and let someone else try it if you want.
cheers
Paul Hudson
I'm resurrecting this thread to see about the current state of
building OCIO for Windows.
I was able to get Cmake to generate a VS 2008 solution, but it isn't
compiling.
Colin's list of fixes seem related to at least some of the errors I am
seeing. I will try to implement these myself, but I was just curious
what successes/failures people have had building on Windows recently.
Has any further effort been put into Windows in the master git repo?
Thanks,
Paul
---------- Forwarded message ----------
From: Colin Doncaster <colin.doncas...@gmail.com>
Date: May 23, 12:10 pm
Subject: Pre-built libraries/examples for Windows?
To: OpenColorIO Developers
What problems were you having?
Cmake seems to generate usable MSCV 2008 solutions for me when I do
cmake -G "Visual Studio 9 2008 Win64" ..
in the build dir.
There were a few changes I've had to make to successfully compile the
OpenColorIO.lib file, here's a quick list
- I had to download patch forwindows, this comes with Cygwin so just
make sure that's in your PATH environment
- I added an if( NOT WIN32 ) around the CMAKE_CXX_FLAGS as the
compiler wasn't happy with most of them
- I had to use _DUSE_BOOST_PTR=ON and then added INCLUDE_DIRECTORIES
( ${Boost_INCLUDE_DIRS} ) to the CMake file ( I assume everyone else
has boost in their global search paths on *nix systems? )
- I had to have add_definitions("-DWIN64") as the yaml code uses that
vs WIN32 to determine if it needs GCC specific template definitions
- defined an isnan to replace the missing std::isnan
- realpath doesn't exist onWindowsso I had to put PathCanonicalize in
a define instead and include Shlwapi.lib
- fixed the cmake file as the yaml and tinyxml STATIC_LINK paths are
explicitly pointing at *nix library names ( libtinyxml.a instead of
tinyxml.lib )
That seems to build fine.
Just to re-iterate though, the issue wasn't with CMake not working.
I can fork OCIO and make these changes and let someone else try it if
you want.
cheers
On 2011-05-23, at 5:49 AM, Peter wrote:
> Hi Paul,
> I've also been working on gettting awindowsversion of the OCIO
> libraries here, and I ran into similar problems to you.
> We managed to build the GCC version fine, but onwindowsI resorted to
> just manually setting up a VC2005 project and pulling in whatever
> files were necessary.
> I'm hoping to look in to the cmake problems further this week so that
> we can get a consistent build sytem across all platforms here. I''ll
> post here anything I find out, and if you have any insights in this
> area please feel free to share them with me too ;)
> Regards,
> Peter.
> On May 20, 7:44 pm, Paul Miller <p...@fxtech.com> wrote:
>> Hey folks. I'm starting to look at OCIO for integration into one or more of
>> my applications and am having trouble getting it built onWindows(my
>> primary dev machine). I use Visual Studio 2008. I downloaded from github and
>> tried using cygwin cmake, which doesn't know about VS, so I grabbed the
>> latest native CMake forWindowsand that was missing all sorts of
>> dependencies and creating vcproj files that wouldn't build. I'm likely doing
>> something wrong but I don't have any experience with cmake. Is there
>> step-by-step "how to build this onWindows, n00b" document? (I'm also having
Jeremy Selan
presume you're using 1.0.X, correct?
Colin's email you cite below is from May. In August, the Foundry
committed 2 changes should make Windows builds work. (Mari is
currently shipping with OCIO on all platforms, so it at least works in
their build environment).
What specific issues are you seeing?
-- Jeremy
Paul Hudson
1.) I saw errors that patch is not a recognized program. (As Colin
mentioned I downloaded cygwin and put it on the path).
2.) Finding the OCIO_USE_BOOST_PTR Cmake setting cleared out a lot of
these errors:
\OpenColorIO_out\export\OpenColorABI.h(63) : fatal error C1189:
#error : OCIO needs gcc 4 or later to get access to <tr1/memory> (or
specify USE_BOOST_PTR instead)
3.) Even though I turned on the OCIO_USE_BOOST_PTR, a few projects
(ociocheck, ocioconvert, ociodisplay, ociobakelut) did not have the
Boost include directory added to their additional includes
4.) The LCMS-configure.rule had '.\configure' instead of 'configure'.
However once it was able to run configure, it errors stating:
3>Unknown option --prefix=C:/dev/src/OpenColorIO/build/ext/dist
3>Usage: configure [-buildkey <key>]
3> [-release] [-debug] [-debug-and-release] [-shared] [-static]
3> [-no-fast] [-fast] [-no-exceptions] [-exceptions]
3> [-no-accessibility] [-accessibility] [-no-rtti] [-rtti]
3> [-no-stl] [-stl] [-no-sql-<driver>] [-qt-sql-<driver>]
3> [-plugin-sql-<driver>] [-system-sqlite] [-arch <arch>]
3> [-D <define>] [-I <includepath>] [-L <librarypath>]
3> [-help] [-no-dsp] [-dsp] [-no-vcproj] [-vcproj]
3> [-no-qmake] [-qmake] [-dont-process] [-process]
3> [-no-style-<style>] [-qt-style-<style>] [-redo]
3> [-saveconfig <config>] [-loadconfig <config>]
3> [-qt-zlib] [-system-zlib] [-no-gif] [-qt-gif] [-no-libpng]
3> [-qt-libpng] [-system-libpng] [-no-libtiff] [-qt-libtiff]
3> [-system-libtiff] [-no-libjpeg] [-qt-libjpeg] [-system-
libjpeg]
3> [-no-libmng] [-qt-libmng] [-system-libmng] [-no-qt3support] [-
mmx]
3> [-no-mmx] [-3dnow] [-no-3dnow] [-sse] [-no-sse] [-sse2] [-no-
sse2]
3> [-no-iwmmxt] [-iwmmxt] [-openssl] [-openssl-linked]
3> [-no-openssl] [-no-dbus] [-dbus] [-dbus-linked] [-platform
<spec>]
3> [-qtnamespace <namespace>] [-qtlibinfix <infix>] [-no-phonon]
3> [-phonon] [-no-phonon-backend] [-phonon-backend]
3> [-no-multimedia] [-multimedia] [-no-audio-backend] [-audio-
backend]
3> [-no-script] [-script] [-no-scripttools] [-scripttools]
3> [-no-webkit] [-webkit] [-webkit-debug] [-graphicssystem
3> raster|opengl|openvg]
5.) LINK error 'dl.lib'. Is this against Python?
11>------ Build started: Project: NukeOCIOLookTransform,
Configuration: Release x64 ------
12>------ Build started: Project: NukeOCIOLogConvert, Configuration:
Release x64 ------
13>------ Build started: Project: NukeOCIODisplay, Configuration:
Release x64 ------
11>Compiling...
12>Compiling...
13>Compiling...
5>main.cpp
6>LINK : fatal error LNK1181: cannot open input file 'dl.lib'
That's where I'm at currently.
Thanks for your help,
Paul
On Nov 8, 1:47 pm, Jeremy Selan <jeremy.se...@gmail.com> wrote:
> As far as I know,Windowsshould be building right out of the box. I
>
> Colin's email you cite below is from May. In August, the Foundry
> their build environment).
>
> What specific issues are you seeing?
>
> -- Jeremy
>
>
>
>
>
>
>
> On Tue, Nov 8, 2011 at 1:34 PM, Paul Hudson <phudson1...@gmail.com> wrote:
> > Hi all,
> > I'm resurrecting this thread to see about the current state of
> > building OCIO forWindows.
> > I was able to get Cmake to generate a VS 2008 solution, but it isn't
> > compiling.
> > Colin's list of fixes seem related to at least some of the errors I am
> > seeing. I will try to implement these myself, but I was just curious
> > what successes/failures people have had building onWindowsrecently.
>
Ivar Rystad
Just want to second that some more windows-friendly documentation/
precompiles would really be appreciated. Not very experienced in this,
but I`m trying to compile thru cygwin and I am almost getting there.
For me it stops here:
$ make install
[ 5%] Built target YAML_CPP_LOCAL
[ 10%] Built target tinyxml
[ 10%] Building CXX object src/core/CMakeFiles/OpenColorIO.dir/
Baker.cpp.o
/tmp/sourceCode/imageworks-OpenColorIO-7a16faa/src/core/Baker.cpp:1:0:
warning: -fPIC ignored for target (all code is position
indep endent)
In file included from /tmp/sourceCode/imageworks-OpenColorIO-7a16faa/
src/core/Mutex.h:68:0,
from /tmp/sourceCode/imageworks-OpenColorIO-7a16faa/
src/core/Processor.h:37,
from /tmp/sourceCode/imageworks-OpenColorIO-7a16faa/
src/core/FileTransform.h:38,
from /tmp/sourceCode/imageworks-OpenColorIO-7a16faa/
src/core/Baker.cpp:34:
/tmp/sourceCode/imageworks-OpenColorIO-7a16faa/src/core/Platform.h:
179:2: error: ‘pthread_spinlock_t’ does not name a type
/tmp/sourceCode/imageworks-OpenColorIO-7a16faa/src/core/Platform.h: In
constructor ‘OpenColorIO::v1::_SpinLock::_SpinLock()’:
/tmp/sourceCode/imageworks-OpenColorIO-7a16faa/src/core/Platform.h:
174:37: error: ‘_spinlock’ was not declared in this scope
/tmp/sourceCode/imageworks-OpenColorIO-7a16faa/src/core/Platform.h:
174:71: error: ‘pthread_spin_init’ was not declared in this scope
/tmp/sourceCode/imageworks-OpenColorIO-7a16faa/src/core/Platform.h: In
destructor ‘OpenColorIO::v1::_SpinLock::~_SpinLock()’:
/tmp/sourceCode/imageworks-OpenColorIO-7a16faa/src/core/Platform.h:
175:40: error: ‘_spinlock’ was not declared in this scope
/tmp/sourceCode/imageworks-OpenColorIO-7a16faa/src/core/Platform.h:
175:49: error: ‘pthread_spin_destroy’ was not declared in this
sc ope
/tmp/sourceCode/imageworks-OpenColorIO-7a16faa/src/core/Platform.h: In
member function ‘void OpenColorIO::v1::_SpinLock::lock()’:
/tmp/sourceCode/imageworks-OpenColorIO-7a16faa/src/core/Platform.h:
176:37: error: ‘_spinlock’ was not declared in this scope
/tmp/sourceCode/imageworks-OpenColorIO-7a16faa/src/core/Platform.h:
176:46: error: ‘pthread_spin_lock’ was not declared in this scope
/tmp/sourceCode/imageworks-OpenColorIO-7a16faa/src/core/Platform.h: In
member function ‘void OpenColorIO::v1::_SpinLock::unlock()’:
/tmp/sourceCode/imageworks-OpenColorIO-7a16faa/src/core/Platform.h:
177:39: error: ‘_spinlock’ was not declared in this scope
/tmp/sourceCode/imageworks-OpenColorIO-7a16faa/src/core/Platform.h:
177:48: error: ‘pthread_spin_unlock’ was not declared in this
sco pe
make[2]: *** [src/core/CMakeFiles/OpenColorIO.dir/Baker.cpp.o] Error 1
make[1]: *** [src/core/CMakeFiles/OpenColorIO.dir/all] Error 2
make: *** [all] Error 2
Sorry if I`m hijacking this thread, but it seemed so similar that I
didn`t want a separate thread.
Colin Doncaster
If no one else beats me to it I'll try to put together a fork of the project that should work out of the box on Windows together in the next week or two along with some pre-built binaries - just need to send in our corporate CLA.
cheers
Jeremy Selan
And now that I have a Windows machine available, once we get the
process sorted out I'm happy to post pre-built installers (mac,
windows, linux?) for each dot release.
-- Jeremy
Malcolm Humphreys
.malcolm
Paul Miller
> Hi there -
>
> If no one else beats me to it I'll try to put together a fork of the project that should work out of the box on Windows together in the next week or two along with some pre-built binaries - just need to send in our corporate CLA.
Colin - made any progress on this?
I'm currently stuck in dependency hell and having a lot of the same
problems you mentioned myself. Part of my problem is I hesitate to stick
cygwin on the master path as some of its toolchain has interfered with
some of my other applications in the past - I like keeping my cygwin
environment as separate as possible.
Would LOVE a set of (64 bit) prebuilt libraries/tools if anyone has
them. Though ideally I'll get this build process sorted out eventually
since I'm going to want it built using my RTM version of VS2008.
Richard Shaw
> I'm currently stuck in dependency hell and having a lot of the same problems
> you mentioned myself. Part of my problem is I hesitate to stick cygwin on
> the master path as some of its toolchain has interfered with some of my
> other applications in the past - I like keeping my cygwin environment as
> separate as possible.
Off the wall idea... What about using a virtual machine for building?
It's kind a big hammer for what you're trying to do, but it would keep
everything separate so you wouldn't have to worry about cygwin
polluting your toolchain.
Richard
Paul Miller
Not a bad idea - I have several "clean" VMs sitting around for testing
anyway. BUT, I figured out a smarter way to do this - I just temporarily
adjusted my PATH to include cygwin and launched VS. What do you know it
works!