Date   

Re: error with ociotoicc

Malcolm Humphreys <malcolmh...@...>
 

Hi Gresham,

Where are you these days?

The icc profiles generated from any of the ocio tools can only be used as 'soft-proofing' profiles.

I'm not sure if your interested in the technical details but in brief as ocio is a RGB only system internally (rather than XYZ or Lab). This means that 3D luts can only process in the fwd direction (it doesn't matter which cube format you use).

For a 'working space' icc profile you need 2 transforms a fwd and reverse (in Lab or XYZ) for it to be valid, for this and the above reason this is not possible to generate a profile with ocio and with the RGB cube that you have.

You should be able to load your 'soft-proofing' profile over from the window menu (i think..) in photoshop, I guess we should document this. A 'soft-proofing' profile doesn't change the 'working space' of your file just shows you what your file would look like when viewed/printed on the target device which your profile describes.

.malcolm

On 25 Nov, 2011,at 07:40 PM, Gresham Lochner <gresh...@...> wrote:

Hi everyone,

Recently I've tried using the ociotoicc utility with a lut on the
command line. When I try to load the icc file into photoshop, I receive:
"Could not load the RGB working space because the profile is not a valid
RGB working space profile."

I've tried .cube's, 3dl's. I've even tried changing some of the tags
in the icc profile, nothing has worked so far. When I'm looking at the
different tags, it looks like a normal icc profile. I've attached it to
the document.

Anyone else having this issue?

Thanks!

- Gresham


Re: error with ociotoicc

Marie Fétiveau <m...@...>
 

Hello !

I tried your ICC profil in Gimp and it seems to work.
I ask one of my colleague to try it on Photoshop CS2 but as the profil doesn't have a description I can't find it in the list (may be you can add a --description to your ocio2icc cmdline ?).

But I made a quick try with a 3dl :
ocio2icc -lut aces_to_ODT_sRGB_17.3dl --description "pouet" test.icc
(This 3dl was generated with ocioBakeLut and the IIF profil Jeremy provided few weeks ago).
It works too...

Sorry that's not really helpful ;p

Marie


On Fri, Nov 25, 2011 at 9:40 AM, Gresham Lochner <gresham...@...> wrote:
Hi everyone,

Recently I've tried using the ociotoicc utility with a lut on the command line. When I try to load the icc file into photoshop, I receive:
"Could not load the RGB working space because the profile is not a valid RGB working space profile."

 I've tried .cube's, 3dl's. I've even tried changing some of the tags in the icc profile, nothing has worked so far.  When I'm looking at the different tags, it looks like a normal icc profile. I've attached it to the document.

Anyone else having this issue?

Thanks!

- Gresham


error with ociotoicc

Gresham Lochner <gresham...@...>
 

Hi everyone,

Recently I've tried using the ociotoicc utility with a lut on the command line. When I try to load the icc file into photoshop, I receive:
"Could not load the RGB working space because the profile is not a valid RGB working space profile."

I've tried .cube's, 3dl's. I've even tried changing some of the tags in the icc profile, nothing has worked so far. When I'm looking at the different tags, it looks like a normal icc profile. I've attached it to the document.

Anyone else having this issue?

Thanks!

- Gresham


Review: First pass at Java JNI interface wrap and andriod toolchain

Malcolm Humphreys <malcolmh...@...>
 

This is mostly about the JNI Java interface, you need to run cmake with (-D OCIO_BUILD_JNIGLUE=TRUE) for the binding to be built. Their is no install target for the JNI build currently I am only running the unit tests with (make JNITests). This has only be run on the OSX so will prob blowup on other platforms.

Any feedback on the Java interface in src/jniglue/org/OpenColorIO would be welcome.

I am having a problem for any JNI experts:

This function sig causes a memory error
Java_org_OpenColorIO_Config_addDisplay(JNIEnv * env, jobject self, jstring display, jstring view, jstring colorSpaceName, jstring looks)

Where this one wouldn't
Java_org_OpenColorIO_Config_addDisplay(JNIEnv * env, jobject self, jstring display, jstring view, jstring colorSpaceName)

Having 4 jstring parameters seems to be the problem, this might just be an issue with the OSX version of Java I'm using I'm not sure. For now Config.addDisplay() is implemented but commented out.

.malcolm


Re: Handling of bundled apps/libraries for Linux distro packaging.

Colin Doncaster <colin.d...@...>
 

Will do - I'll try and get everything humming along on Windows too, at least with the core tools. I'm hoping I'll have a few days this coming week to tackle this.

cheers

On 2011-11-20, at 8:21 PM, Jeremy Selan wrote:

- Colin - Getting OCIO ready for inclusion on distros is going to take a bit of work, and I see no reason to delay the cpack installs. So COLIN, why dont you start on the 'core' install? Let us know if there's anything holding you up?


Re: Handling of bundled apps/libraries for Linux distro packaging.

Paul Miller <pa...@...>
 

On 11/20/2011 7:44 PM, Jeremy Selan wrote:
Oh - one other dependency consideration I forgot is our use of an
external shared_ptr header.

Currently the default is to look for tr1, and if it's not enabled you
can optionally specify boost. What should the standard installation do?
Maybe on linux / osx, we always assume the existence of tr1? How about
on windows?
I'm not sure you can assume tr1 on Windows. It first showed up in VS2008 SP1, but some people (including us) aren't using SP1, for compatibility reasons with certain runtimes. However, if you need tr1 you can get it from boost (which is what we do). I have no problem with requiring boost, though I can see it being quite the pain for people who aren't yet using it on Windows. A catch 22 if I ever saw one. Maybe you should just assume people have tr1 afterall. :-)


Re: Handling of bundled apps/libraries for Linux distro packaging.

Jeremy Selan <jeremy...@...>
 

Oh - one other dependency consideration I forgot is our use of an external shared_ptr header.

Currently the default is to look for tr1, and if it's not enabled you can optionally specify boost. What should the standard installation do?  Maybe on linux / osx, we always assume the existence of tr1? How about on windows?

-- Jeremy


Re: Handling of bundled apps/libraries for Linux distro packaging.

Richard Shaw <hobbe...@...>
 

On Sun, Nov 20, 2011 at 7:21 PM, Jeremy Selan <jeremy...@...> wrote:
- Richard.  Any thoughts on how we can make the unit tests part of the
installation / build process?
On the RPM side (including Suse and other RPM systems), it's easy. The
spec file supports a %check section and a failure in this area
(non-zero exit) will fail the build. I'm sure Debian based systems
have an equivalent.

Richard


Re: Handling of bundled apps/libraries for Linux distro packaging.

Jeremy Selan <jeremy...@...>
 

So i've learned a lot about packaging these last few days!  Who knew there was so much to it? ;)

For those who want to come up to speed as well, these links are great places to start:


First off, I'm now totally sold on us (eventually) using the system install for all dependencies. (Which doesnt mean we cant ship with those in ext, we just need to play nicely with the system installed ones)

And for those interested, here is Richard's the fedora listserv link:
(thanks Richard for asking)

My hesitancy to pull out yaml / tinyxml was only based on wanting to guarantee serialization compatibility, but I now believe all of my concerns about serialization precision, etc, can be addressed with additional unit tests.  That's better than just locking down to a single library anyways.  Perhaps we could make the unit tests part of the build process, so if they fail we can mark the install as failed too?

The fedora team also mentions that it's okay to include bundled libs for convenience, as long as you defer to the system installs if they exist. (or something similar)  That seems like the best of both worlds (with the new unit tests, of course).

For md5, we dont have to worry about including the source code as the version we use is an accepted copylib.  The same also applies to pystring. (I will update the pystring website docs to make this explicit) ;)

In terms of how we split up the libs, I'm willing to defer to experts.  But if I had to wager a guess for what ocio 'core' would consist of, I'd consider it:

- src
- core (lib + shell apps)
- dev (headers etc)

which would require the dependencies:
 lcms, tinyxml, yaml-cpp

I'd probably leave out nuke / mari from all installs (other than the source), as they'll be disted with the apps anyways.  So that just leaves the docs targets remaining?

Also, in terms of the shell apps, the two that depend on oiio (ociodisplay,ocioconvert) are not really intended to be used or installed necessarily, they're really more included as simple working code examples.   But the other command-line apps (ociocheck, ocio2icc, ociobakelut) are useful parts of the base install.

As far as python is concerned, it'd be great if it were part of the core install, but how does this work with regards to python versions?  With the new installation location, is it possible to have both 2.6 / 2.7 installs on the same system? (not sure if this is critical or not)


ACTION ITEMS:

- Colin - Getting OCIO ready for inclusion on distros is going to take a bit of work, and I see no reason to delay the cpack installs.  So COLIN, why dont you start on the 'core' install?  Let us know if there's anything holding you up?

- Jeremy (me): I'll need to add unit tests for serialization, and to push our yamlcpp edit upstream.  I'll also update to the latest version of all serialization libs and make sure everything still works fine.  I'll also update pystring's website to clarify its expected use as a copylib.

- Richard.  Any thoughts on how we can make the unit tests part of the installation / build process? 

-- Jeremy


Re: Handling of bundled apps/libraries for Linux distro packaging.

Richard Shaw <hobbe...@...>
 

Also worth mentioning... Although Toshio (from Fedora devel list)
thought it was strange for the python library to serve a dual purpose,
he agreed that the most appropriate action was to put the library
(with lib prefix) in /usr/lib{,64} and symlink it to site-packages (I
created the link without lib prefix).

Richard


Re: Handling of bundled apps/libraries for Linux distro packaging.

Richard Shaw <hobbe...@...>
 

On Fri, Nov 18, 2011 at 9:40 AM, Malcolm Humphreys
<malcolmh...@...> wrote:
Off list Jeremy, Colin and myself were chatting about this when talking
about the windows build.
....
We need to have a consensus on how the project will be split up into
packages (ie different sets of rpm's / debs etc).

Something along the lines of
- src
- core (lib + shell apps)
- dev (headers etc)
- gui apps (qt dependancy)
- nuke
- mari
- python (this could be part of core??)
Usually it's the packagers job to decide on how to break up the
packages as the guidelines differ somewhat between distros, but
documented suggestions are very welcome.


Depending on if the goal is to get these packages included as part of the
base linux distributions this creates a bit of work with the bundled in
dependancies. To me this feels like a second step on getting ocio accepted
into the most relevant distributions.
Does ocio include significant testing yet? I'm sure RPM does and deb
based systems probably also have the ability to test the builds during
the building process. In RPM's this is done in the %check section. I'd
have to look it up but I'm pretty sure exiting with anything other
than "0" will fail the build. This may do a lot to ease the burden of
having to worry about the versions of yaml-cpp and tinyxml the host
system uses.


....
Thinking about this more it doesn't feel like we need to work out how to
package everything just the main bits. Something like (note. these would map
to the install options in the NIS installer on windows):
- OpenColorIO-src-1.0.1
- OpenColorIO-core-1.0.1
  [ libOpenColorIO, headers, ocio2icc, ociobakelut, ociocheck ]
- OpenColorIO-python{ver}-1.0.1
- OpenColorIO-docs-1.0.1
  [ html, pdf, man (need to add)]
OpenColorIO-core-1.0.1 would depend on lcms2-2.1, tinyxml-2.6.1,
yaml-cpp-??, pystring-?? and possibly the md5 code.
If it helps, here's the current versions of the software in ext on my
Fedora 15 system:

tinyxml-devel-2.6.1-2.fc15.x86_64
yaml-cpp-devel-0.2.5-2.fc15.x86_64
python-docutils-0.8-0.1.20110517svn7036.fc15.noarch
python-jinja2-2.5.5-4.fc15.noarch
lcms2-devel-2.2-1.fc15.x86_64
python-pygments-1.4-1.fc15.noarch
python-setuptools-0.6.24-1.fc15.noarch
python-sphinx-1.0.7-2.fc15.noarch

I can get the same information for Fedora 16 and EL 6 if it would help
(EL means RHEL 6 and derivatives, CentOS, SL, etc.). Are you worried
about EL 5? I would think that's the oldest EL that would matter.


Later on when OpenImageIO has be also successfully been packaged we could
have another package for ocioconvert and ociodisplay.
Do you mean for other distro's? oiio is already in Fedora as I'm the
maintainer for it. I haven't packaged it for any EL's but that could
be added fairly easily.


The nuke and mari code probably can be left to be compiled/used on a need
basis as this is pretty site dependant setup wise.
Yes, since nuke and Truelight are non-free they will not be in Fedora.
If someone wants to build a commercial system based on Fedora they can
use the source RPM and build their own packages very easily. That's
the nice thing about using a source RPM. Most of the hard work is done
for you.

Thanks,
Richard


Re: Handling of bundled apps/libraries for Linux distro packaging.

Malcolm Humphreys <malcolmh...@...>
 

Off list Jeremy, Colin and myself were chatting about this when talking about the windows build.

....
We need to have a consensus on how the project will be split up into packages (ie different sets of rpm's / debs etc).

Something along the lines of
- src
- core (lib + shell apps)
- dev (headers etc)
- gui apps (qt dependancy)
- nuke
- mari
- python (this could be part of core??)

Depending on if the goal is to get these packages included as part of the base linux distributions this creates a bit of work with the bundled in dependancies. To me this feels like a second step on getting ocio accepted into the most relevant distributions.
....

Thinking about this more it doesn't feel like we need to work out how to package everything just the main bits. Something like (note. these would map to the install options in the NIS installer on windows):
- OpenColorIO-src-1.0.1
- OpenColorIO-core-1.0.1
  [ libOpenColorIO, headers, ocio2icc, ociobakelut, ociocheck ]
- OpenColorIO-python{ver}-1.0.1
- OpenColorIO-docs-1.0.1
  [ html, pdf, man (need to add)]

OpenColorIO-core-1.0.1 would depend on lcms2-2.1, tinyxml-2.6.1, yaml-cpp-??, pystring-?? and possibly the md5 code.

Later on when OpenImageIO has be also successfully been packaged we could have another package for ocioconvert and ociodisplay.

The nuke and mari code probably can be left to be compiled/used on a need basis as this is pretty site dependant setup wise.

Thoughts?

Do we have to worry about have different compiler versions of the core package, depending on which host app it might be used in?

.malcolm


On 17/11/2011, at 4:06 PM, Richard wrote:

Placeholder for continued discussion from:



Handling of bundled apps/libraries for Linux distro packaging.

Richard <hobbe...@...>
 

Placeholder for continued discussion from:


Review: Update library locations for multi-lib *nix systems

Jeremy Selan <jeremy...@...>
 


Re: Pre-built libraries/examples for Windows?

Malcolm Humphreys <malcolmh...@...>
 

I did start to play around with using cpack for this to create the relevant installers (rpm, deb, tar, exe etc..) I should have some free time to get around to cleaning this up and committing it.

.malcolm

On 16/11/2011, at 3:38 PM, Jeremy Selan wrote:

Awesome!

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

On Wed, Nov 16, 2011 at 7:10 AM, Colin Doncaster
<colin.d...@...> wrote:
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.

cheers

On 2011-11-16, at 9:45 AM, Ivar Rystad wrote:

Hi guys!
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.




On 9 Nov, 02:05, Paul Hudson <phuds...@...> wrote:
Yes, 1.0.1.

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...@...> wrote:







As far as I know,Windowsshould be building right out of the box. I
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 makeWindowsbuilds 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
On Tue, Nov 8, 2011 at 1:34 PM, Paul Hudson <phuds...@...> 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.
Has any further effort been put intoWindowsin the master git repo?
Thanks,
Paul
---------- Forwarded message ----------
From: Colin Doncaster <colin.d...@...>
Date: May 23, 12:10 pm
Subject: Pre-built libraries/examples forWindows?
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


Re: Pre-built libraries/examples for Windows?

Jeremy Selan <jeremy...@...>
 

Awesome!

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

On Wed, Nov 16, 2011 at 7:10 AM, Colin Doncaster
<colin.d...@...> wrote:
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.

cheers

On 2011-11-16, at 9:45 AM, Ivar Rystad wrote:

Hi guys!
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.




On 9 Nov, 02:05, Paul Hudson <phuds...@...> wrote:
Yes, 1.0.1.

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...@...> wrote:







As far as I know,Windowsshould be building right out of the box. I
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 makeWindowsbuilds 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
On Tue, Nov 8, 2011 at 1:34 PM, Paul Hudson <phuds...@...> 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.
Has any further effort been put intoWindowsin the master git repo?
Thanks,
Paul
---------- Forwarded message ----------
From: Colin Doncaster <colin.d...@...>
Date: May 23, 12:10 pm
Subject: Pre-built libraries/examples forWindows?
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


Re: Pre-built libraries/examples for Windows?

Colin Doncaster <colin.d...@...>
 

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.

cheers

On 2011-11-16, at 9:45 AM, Ivar Rystad wrote:

Hi guys!
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.




On 9 Nov, 02:05, Paul Hudson <phuds...@...> wrote:
Yes, 1.0.1.

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...@...> wrote:







As far as I know,Windowsshould be building right out of the box. I
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 makeWindowsbuilds 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
On Tue, Nov 8, 2011 at 1:34 PM, Paul Hudson <phuds...@...> 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.
Has any further effort been put intoWindowsin the master git repo?
Thanks,
Paul
---------- Forwarded message ----------
From: Colin Doncaster <colin.d...@...>
Date: May 23, 12:10 pm
Subject: Pre-built libraries/examples forWindows?
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


Re: Pre-built libraries/examples for Windows?

Ivar Rystad <iv...@...>
 

Hi guys!
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.

On 9 Nov, 02:05, Paul Hudson <phuds...@...> wrote:
Yes, 1.0.1.

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...@...> wrote:







As far as I know,Windowsshould be building right out of the box. I
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 makeWindowsbuilds 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
On Tue, Nov 8, 2011 at 1:34 PM, Paul Hudson <phuds...@...> 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.
Has any further effort been put intoWindowsin the master git repo?
Thanks,
Paul
---------- Forwarded message ----------
From: Colin Doncaster <colin.d...@...>
Date: May 23, 12:10 pm
Subject: Pre-built libraries/examples forWindows?
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


Re: Pre-built libraries/examples for Windows?

Paul Hudson <phuds...@...>
 

Yes, 1.0.1.


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...@...> wrote:
As far as I know,Windowsshould be building right out of the box. I
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 makeWindowsbuilds 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







On Tue, Nov 8, 2011 at 1:34 PM, Paul Hudson <phuds...@...> 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.
Has any further effort been put intoWindowsin the master git repo?
Thanks,
Paul
---------- Forwarded message ----------
From: Colin Doncaster <colin.d...@...>
Date: May 23, 12:10 pm
Subject: Pre-built libraries/examples forWindows?
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


Re: OCIO 1.0 Build Issues On Snow Leopard

Jordan Soles <jor...@...>
 

This works like a charm now!

Thanks,
Jordan

1561 - 1580 of 2242