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 what happens when, instead of doing the long path, but doing it
right, we choose the short "kinda wrong" path... lesson learned! =P
really sorry about that and really appreciate the time you put in to help me
out so far, man! =)
-H
On Fri, Sep 24, 2010 at 10:17 PM, Hradec <[email protected]> wrote:
> I'll try that.. thanks!!
>
>
> On Fri, Sep 24, 2010 at 9:57 PM, JonY <[email protected]> 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 and libHalf-6.dll in the /bin folder... but the
>>> libHalf.dll.a is waaaaay smaller than the one I got now. Also,
>>> libhalf.lahas nothing BUT libHalf-6.dll...
>>>
>>>
>>> It definitely looks like configure is going bananas because of the cross
>>> build environment...
>>>
>>> -H
>>>
>>>
>> Hi,
>>
>> lib.exe isn't normally used, but I think it is confusing libtool, possibly
>> considered a bug. I think it should work as intended once you remove
>> lib.exe.
>>
>
>
>
> --
> Hradec
>
--
Hradec
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
