openexr-devel
[Top][All Lists]
Advanced

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

Re: [Openexr-devel] Compiling on MinGW


From: Paul Gregory
Subject: Re: [Openexr-devel] Compiling on MinGW
Date: Mon, 29 Jan 2007 23:38:37 +0000

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> 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> 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>> 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>
>      > 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
reply via email to

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