Ok... it wasn't the lib.exe. It was a misconfiguration on my part... sorry
about that.
As I build a bunch of packages on one single script, I made CXX="$CXX
$CXXFLAGS" to simplify the setup. But that was causing ilmBase configure to
fail when checking if g++ could generate a shared file.
that's w
I'll try that.. thanks!!
On Fri, Sep 24, 2010 at 9:57 PM, JonY wrote:
> On 9/25/2010 12:58, Hradec wrote:
>
>> by the way... I'm just having a look at an old build I did on a windows
>> box
>> using msys and al old mingw (3.4.5)... It did compiled susccessfuly and it
>> did output libHalf.dll.a
On 9/25/2010 12:58, Hradec wrote:
> by the way... I'm just having a look at an old build I did on a windows box
> using msys and al old mingw (3.4.5)... It did compiled susccessfuly and it
> did output libHalf.dll.a and libHalf-6.dll in the /bin folder... but the
> libHalf.dll.a is way smaller
by the way... I'm just having a look at an old build I did on a windows box
using msys and al old mingw (3.4.5)... It did compiled susccessfuly and it
did output libHalf.dll.a and libHalf-6.dll in the /bin folder... but the
libHalf.dll.a is way smaller than the one I got now. Also,
libhalf.laha
humm... I got no Visual Studio installed... only lib.exe in my path... Could
it be that libtool is confused because I'm running in Linux and its trying
to build the shared library for windows, but adding the .a because that's
the linux extension?
-H
On Fri, Sep 24, 2010 at 9:24 PM, JonY wrote:
On 9/25/2010 11:29, Hradec wrote:
> Hi there...
>
> Its being a while we spoke about this and I end up deciding to build a linux
> box to do the cross compiling, instead of OSX.
>
> Things are way smoother now, but I'm running into trouble with ilmbase
> again.
>
> This time, I followed Doug Siemer
Hi there...
Its being a while we spoke about this and I end up deciding to build a linux
box to do the cross compiling, instead of OSX.
Things are way smoother now, but I'm running into trouble with ilmbase
again.
This time, I followed Doug Siemer advice and I setup
--host=i686-w64-mingw32.
Thi
I fixed the "::_Exit" error in cstdlib by replacing line 165 by the _Exit
declaration found at line 163, which defines a proper _Exit function that
trows an exception... seems to be compiling correctly now.
Now I got something really weird... Libtool found an weird path that seems
to be hardcoded
Hi there... I got it building past that point... thanks a lot for all the
help!!!
But now I'm getting this when compiling another source:
In file included from
/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/compilers/darwin.mingw32.4.6.0_20100605/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../.
On Tue, Jun 1, 2010 at 10:13 PM, Hradec wrote:
> also, by doing a grep _eLut, this is the result:
>
> hradec$ grep '_eLut'
> /Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/./build/mingw/ilmbase-1.0.1/lib/*
>
> Binary file
> /Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OI
also, by doing a grep _eLut, this is the result:
hradec$ grep '_eLut'
/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/./build/mingw/ilmbase-1.0.1/lib/*
Binary file
/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/./build/mingw/ilmbase-1.0.1/lib/libHalf.a
match
On 6/2/2010 10:08, Hradec wrote:
> i686-w64-mingw32-g++
> -I/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/pthreads/build/GC_x86_4.6.0_20100528/include/
> -L/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/pthreads/build/GC_x86_4.6.0_20100528/lib/
> -I./src/inc
i686-w64-mingw32-g++
-I/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/pthreads/build/GC_x86_4.6.0_20100528/include/
-L/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/pthreads/build/GC_x86_4.6.0_20100528/lib/
-I./src/include -DWINAPI=__stdcall -D__MINGW32__ -D_
On 6/2/2010 06:28, Hradec wrote:
> Works!! I got it linking correctly... I actually found the libtool template
> code inside configure, so it was pretty simple to delete it from there and
> now I got a proper configure patch which generates a patched libtool.
>
> Although it links correctly now, I'
Works!! I got it linking correctly... I actually found the libtool template
code inside configure, so it was pretty simple to delete it from there and
now I got a proper configure patch which generates a patched libtool.
Although it links correctly now, I'm not getting any DLLs out of it... just
.
On 6/1/2010 10:30, Hradec wrote:
> yeah... I already find it... the problem is that libtool is being generated
> after the configure script, and my automatic build system runs before
> configure, so I would have to patch configure in order to get it to output
> libtool already patched... (kinda con
yeah... I already find it... the problem is that libtool is being generated
after the configure script, and my automatic build system runs before
configure, so I would have to patch configure in order to get it to output
libtool already patched... (kinda confusing)...
That's why I was wondering if
On 6/1/2010 09:57, Hradec wrote:
> cool... I'll try that!
>
> a question... the ilmbase configure script if figuring all that out by
> itself... I'm wondering if there's a default mechanism that a configure
> script can use to query gcc in order to obtain those options... if so, is
> there a way
cool... I'll try that!
a question... the ilmbase configure script if figuring all that out by
itself... I'm wondering if there's a default mechanism that a configure
script can use to query gcc in order to obtain those options... if so, is
there a way to change the default options using an enviro
On 5/31/2010 16:11, Hradec wrote:
> thanks for the idea... just tried and now I got multiple definitions:
>
> i686-w64-mingw32-g++
> -I/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/pthreads/build/GC_x86_4.6.0_20100528/include/
> -L/Volumes/Data/Users/hradec/dev/svn/cortex4all/t
thanks for the idea... just tried and now I got multiple definitions:
i686-w64-mingw32-g++
-I/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/pthreads/build/GC_x86_4.6.0_20100528/include/
-L/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/pthreads/build/GC_x86_4
On 5/31/2010 03:42, Hradec wrote:
> Hi there...
>
> before anything I would like to thank you all by the amazing mingw64... In
> my opnion, the best mingw ever... really neat, simple and clean... well
> done!!
>
> I'm working on cross-compile openexr and ilmbase on a mac. I got the latest
> darwin
Hi there...
before anything I would like to thank you all by the amazing mingw64... In
my opnion, the best mingw ever... really neat, simple and clean... well
done!!
I'm working on cross-compile openexr and ilmbase on a mac. I got the latest
darwin binary package, mingw32.4.6.0_20100528, 32 bits
23 matches
Mail list logo
