I've found myself in a position where I have a few days before a package
release, so I've decided to take another look at this in the hope that
we can release with OpenEXR support on Windows as well as Linux.
So far, I've managed to successfully build IlmBase, with a minor change
to the thread source, and specific configure options, under MSYS that
now builds and installs apparently ok.
OpenEXR itself is proving to be more of a problem. The main cause of the
problem at the moment seems to revolve around using LDFLAGS in places
where apparently (I'm relying on advice here, as auto* isn't my forte)
LIBS should be used. The outcome is that the options to the link phase
to add extra libraries are being passed 'before' the object files. Under
MinGW, the order is important, and it seems that the general advice is
to use LDFLAGS to specify options, and LIBS to specify additional
libraries for this very reason.
I've tried to get my head round how to rectify this, but soon got out of
my depth. I managed to get ./configure to run and ILMBASE_CXXFLAGS and
ILMBASE_LDFLAGS seem to be setup properly to reasonable defaults,
however, the ordering problem has stopped the ilmbasetest part of
./configure working. I've re-run with --disable-ilmbasetest, and when I
run make, IlmImf fails immediately when compiling b44ExpLogTable.cpp as
half.h could not be found. It's at this point I've given up, as I can
find no place in the configuration files that tells the compilation to
use ILMBASE_CXXFLAGS, and as such, the command line to compile this file
is...
g++ -g -O2 b44ExpLogTable.cpp -o b44ExpLogTable
...apparently completely ignoring the ILMBASE_CXXFLAGS set earlier as
reported by configure...
using default as guess for ILMBASE_CXXFLAGS and ILMBASE_LDFLAGS:
ILMBASE_CXXFLAGS = -pthread -I/usr/local/include/OpenEXR
ILMBASE_LDFLAGS = -L/usr/local/lib -lImath -lHalf -lIex -lIlmThread
-L/usr/lib64/ -lpthread
It seems that I'm making some progress, but can't quite figure out the
next step, if someone more familiar with the auto* build system could
offer some help that would be great here.
Thanks
Paul Gregory
On 12/21/06, *Paul Gregory* <address@hidden <mailto:address@hidden>>
wrote:
Hi,
This is exactly the problem I'm looking into now, I have a modified
version of the IlmThread files you mention that works properly in
MinGW with --disable-threading and --disable-posix-sem. With my
small changes I can successfully compile ilmbase-0.9.0 on MinGW.
However, OpenEXR is proving to be a bit more work, I'll continue
looking into it today, and hopefully be in a position to provide a
patch that gets OpenEXR to work on MinGW without threading initially.
Cheers
Paul Gregory
On 12/20/06, *Florian Kainz* < address@hidden <mailto:address@hidden>>
wrote:
Hi Guiseppe,
the problem you are having could be caused by the build
scripts. I've
never used minGW, so I can't really debug this myself. Assuming
I can
somehow create an environment on Linux where pthreads are
unavailable,
I might be able reproduce the problem, but I won't be able to
work on
this for a while.
Which parts of the IlmThread library are compiled (dummy
implementation,
Posix threads or Windows threads) is governed by a couple of
compile-time
flags. For example, IlmThreadMutex.cpp looks like this:
#include "IlmBaseConfig.h"
#if !defined (_WIN32) && !(_WIN64) && !(HAVE_PTHREAD)
#include "IlmThreadMutex.h "
namespace IlmThread {
Mutex::Mutex () {}
Mutex::~Mutex () {}
void Mutex::lock () const {}
void Mutex::unlock () const {}
} // namespace IlmThread
#endif
You may want to try hard-wiring the settings of those flags.
For example in IlmThreadMutex.cpp, replace
#if !defined (_WIN32) && !(_WIN64) && !(HAVE_PTHREAD)
with
#if 1
replace the corresponding lines in IlmThreadMutexPosix.cpp
and IlmThreadMutexWindows.cpp with
#if 0
After you re-compile, the mutex-related symbols should no
longer be missing. If this works, fix the rest of IlmThread
in a similar way.
Florian
Giuseppe Rota wrote:
It seems like the problem is in the building of IlmThread
itself. We
cannot complete the linking step: there are a lot of undefined
references (see attachment). Could this be a problem with the
autotools,
maybe?
As far as using the precompiled DLLs is concerned, I tried but
I was not
able to link against them: I had the same problem with the
win32 native
build of ImageMagick, and they told me that it was a problem
of name
mangling of the compiler.
Giuseppe
On 12/20/06, *Florian Kainz* < address@hidden
<mailto:address@hidden> <mailto:address@hidden
<mailto:address@hidden>>> wrote:
I must admit that I don't know anything about minGW, but maybe
the following helps:
The IlmThread library will be built even if you disable
threading.
It will contain dummy implementations for threads, mutexes and
semaphores. Creating a thread always throws an exception, and
attempts to lock mutexes and semaphores always succeed.
The IlmImf library should work even with the dummy IlmThread
implementation, as long as you don't enable threading. You
should
be able to compile and link the IlmImfTest
executable. When you
run the executable, any tests that involve multithreading will
fail, but that doesn't necessarily mean that the IlmImf library
is broken. The tests should run to completion if you
comment out
all calls to setGlobalThreadCount() in test*.cpp.
Alternatively, can your application be linked against DLLs
from a
native Windows build? OpenEXR comes with Visual C++
project files,
and threading does work on Windows.
Florian
Paul Gregory wrote:
> Hi All,
>
> I've been trying to get OpenEXR to compile on MinGW for
some time
now so
> that we (the Aqsis team) can release a version of Aqsis that
supports
> OpenEXR on both Windows and Posix. However, as others
have found
on this
> list, it doesn't seem that OpenEXR is well setup to
compile on MinGW.
>
> The main stumbling block I've hit so far is threading,
I've tried to
> fool it into using the Win32 threading code, no joy,
I've tried to
> install and get it to use the Win32 port of pthreads,
again no
joy. The
> wierdest of all is that --disable-threading doesn't
actually seem to
> disable threading, it still tries and fails to build the
IlmThread
> project of ilmbase. I've hit these problems with both
the stable
1.4.0
> source archive, and the newer split 1.5.0 of OpenEXR and
0.9.0
IlmBase
> source archive.
>
> If anyone has any suggestions on how to get this all to
compile on
> MinGW/MSYS, it would be most appreciated.
>
> Thanks
>
> --
> Paul Gregory
> http://www.aqsis.org
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
<mailto:address@hidden> <mailto:
address@hidden <mailto:address@hidden>>
> http://lists.nongnu.org/mailman/listinfo/openexr-devel
< http://lists.nongnu.org/mailman/listinfo/openexr-devel>
--
Paul Gregory
http://www.aqsis.org
ICQ: 156088409
--
Paul Gregory
http://www.aqsis.org
ICQ: 156088409
------------------------------------------------------------------------
_______________________________________________
Openexr-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/openexr-devel