On Thu, Aug 5, 2010 at 5:21 AM, Chris Sutcliffe wrote:
> On 8/04/10 9:10 PM, Ozkan Sezer wrote:
>> What happens if you comment out lines 459 and 462 in
>> win32/osdep.h and allow stdlib.h and mbstring.h to be
>> included and get a proper definition of MB_CUR_MAX ?
>> I don't know why it doesn't w
On 8/04/10 9:10 PM, Ozkan Sezer wrote:
> What happens if you comment out lines 459 and 462 in
> win32/osdep.h and allow stdlib.h and mbstring.h to be
> included and get a proper definition of MB_CUR_MAX ?
> I don't know why it doesn't want to include those headers
> but I just cross-compiled zip3
On Thu, Aug 5, 2010 at 3:45 AM, Chris Sutcliffe wrote:
> Hi Kai,
>
> On 7/31/10 1:13 PM, Kai Tietz wrote:
>> 2010/7/31 Chris Sutcliffe:
>>> It turns out it's not gcc, it's due to the fact that libmsvcrt.a doesn't
>>> export `__p___mb_cur_max'. The mingw.org msvcrt.def file contains:
>>>
>>> __p_
Hi Kai,
On 7/31/10 1:13 PM, Kai Tietz wrote:
> 2010/7/31 Chris Sutcliffe:
>> It turns out it's not gcc, it's due to the fact that libmsvcrt.a doesn't
>> export `__p___mb_cur_max'. The mingw.org msvcrt.def file contains:
>>
>> __p___mb_cur_max
>>
>> where as the mingw-w64-crt does not. Would it
On 7/31/10 1:13 PM, Kai Tietz wrote:
> On x64 you can use here -lwmsvcrt to get this symbol. For 32-bit this
> symbol is exported, so you shouldn't have here any troubles.
Excellent, it works perfectly.
Thank you Kai!
Chris
2010/7/31 Chris Sutcliffe :
> On 7/30/10 11:40 PM, Chris Sutcliffe wrote:
>> Doing a little more digging, it seems like it's not dllwrap at all,
>> it's gcc:
>>
>> x86_64-w64-mingw32-gcc -Wl,--enable-stdcall-fixup -ozip32z64.dll -s
>> -shared windll.o windllrc.o api.o zipl.o cryptl.o ttyiol.o zipf
On 7/31/2010 22:17, JonY wrote:
> On 7/31/2010 22:09, Chris Sutcliffe wrote:
>> On 7/30/10 11:40 PM, Chris Sutcliffe wrote:
>>> Doing a little more digging, it seems like it's not dllwrap at all,
>>> it's gcc:
>>>
>>> x86_64-w64-mingw32-gcc -Wl,--enable-stdcall-fixup -ozip32z64.dll -s
>>> -shared w
On 7/31/2010 22:09, Chris Sutcliffe wrote:
>On 7/30/10 11:40 PM, Chris Sutcliffe wrote:
>> Doing a little more digging, it seems like it's not dllwrap at all,
>> it's gcc:
>>
>> x86_64-w64-mingw32-gcc -Wl,--enable-stdcall-fixup -ozip32z64.dll -s
>> -shared windll.o windllrc.o api.o zipl.o crypt
On 7/30/10 11:40 PM, Chris Sutcliffe wrote:
> Doing a little more digging, it seems like it's not dllwrap at all,
> it's gcc:
>
> x86_64-w64-mingw32-gcc -Wl,--enable-stdcall-fixup -ozip32z64.dll -s
> -shared windll.o windllrc.o api.o zipl.o cryptl.o ttyiol.o zipfilel.o
> zipupl.o fileiol.o uti
On 7/30/10 7:53 PM, Chris Sutcliffe wrote:
> I just tried with the latest Cygwin snapshot (20100726):
>
> $ x86_64-w64-mingw32-dllwrap.exe --version
> GNU x86_64-w64-mingw32-dllwrap (GNU Binutils) 2.20.51.20100726
> Copyright 2010 Free Software Foundation, Inc.
> This program is free software; yo
Hi Kai,
On 7/16/10 8:42 AM, Kai Tietz wrote:
> Hello Chris,
>
>> I'm trying to compile Info-zip's zip 3.1c during the linking stage of
>> the 'dll' target. The command I use to build the dll is:
>>
>> make -f win32/makefile.gcc CC=x86_64-w64-mingw32-gcc
>> RC=x86_64-w64-mingw32-windres NOASM=1
On 16 July 2010 14:02, Chris Sutcliffe wrote:
> Hi Kai,
>
>> This issue is caused by a recent fixed bug in binutils' dllwrap tool.
>> Please use a new binutils version (head) version. Then your problem
>> should be solved.
>
> Thank you for clarifying the source of the issue.
>
> Will this fix be
Hi Kai,
> This issue is caused by a recent fixed bug in binutils' dllwrap tool.
> Please use a new binutils version (head) version. Then your problem
> should be solved.
Thank you for clarifying the source of the issue.
Will this fix be captured in an automated build? I'm currently using
the 20
Hello Chris,
2010/7/16 Chris Sutcliffe :
> Hi All,
>
> I'm trying to compile Info-zip's zip 3.1c during the linking stage of
> the 'dll' target. The command I use to build the dll is:
>
> make -f win32/makefile.gcc CC=x86_64-w64-mingw32-gcc
> RC=x86_64-w64-mingw32-windres NOASM=1 dll
>
> which co
Hi All,
I'm trying to compile Info-zip's zip 3.1c during the linking stage of
the 'dll' target. The command I use to build the dll is:
make -f win32/makefile.gcc CC=x86_64-w64-mingw32-gcc
RC=x86_64-w64-mingw32-windres NOASM=1 dll
which compiles the object files fine, however, when linking:
dll
15 matches
Mail list logo
