Re: [Openexr-devel] Compiling on MinGW

[Paul Gregory]

Hi Florian,

Thanks for that pointer, I've now checked out the current CVS, and as you suggest, there have been some changes in this area. Now configure in OpenEXR passes cleanly under MinGW, including running ilmbasetest, which is quite encouraging. However, the problem with 
b44ExpLogTable.cpp is still the same, there doesn't seem to be anything in the Makefile.am that adds ILMBASE_CXXFLAGS to the build for that particular part of IlmImf, the command line is still the same bare g++ call with no additional options.

Any thoughts appreciated.

Thanks

PaulG

On 1/29/07, Florian Kainz <address@hidden> wrote:

Hi Paul,

I believe Andrew Kunz just checked a fix for the problems you describe.
into CVS  You may want to get the latest versions of */Makefile.am,
.configure etc. from the CVS tree.  Unfortunately Andrew will be
out of the office for the next couple of weeks, and I don't know
enough about the auto* tools to help you.  We plan to do another
release as soon we've worked out the kinks we introduced into the
build system when we moved from 1.4 to 1.5.

Florian


Paul Gregory wrote:
> 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

-- 
Paul Gregory
http://www.aqsis.org
ICQ: 156088409