Re: [Mingw-w64-public] Issues compiling Info-zip's zip 3.1c
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 utill.o crc32l.o globalsl.o deflatel.o treesl.o zbz2errl.o win32l.o win32zpl.o win32i64l.o ntl.o -luser32 -ladvapi32 zipfilel.o:zipfile.c:(.text+0x15b1): undefined reference to `__p___mb_cur_max' fileiol.o:fileio.c:(.text+0x508): undefined reference to `__p___mb_cur_max' fileiol.o:fileio.c:(.text+0x59a): undefined reference to `__p___mb_cur_max' fileiol.o:fileio.c:(.text+0x5b7): undefined reference to `__p___mb_cur_max' fileiol.o:fileio.c:(.text+0x61b): undefined reference to `__p___mb_cur_max' fileiol.o:fileio.c:(.text+0x64c): more undefined references to `__p___mb_cur_max' follow Yet as previously mentioned, mb_cur_max is exported my libmsvcrt.a. I'm stumped. 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 be possible to have this added? Thank you, Chris -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Issues compiling Info-zip's zip 3.1c
2010/7/31 Chris Sutcliffe ir0nh...@gmail.com: 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 utill.o crc32l.o globalsl.o deflatel.o treesl.o zbz2errl.o win32l.o win32zpl.o win32i64l.o ntl.o -luser32 -ladvapi32 zipfilel.o:zipfile.c:(.text+0x15b1): undefined reference to `__p___mb_cur_max' fileiol.o:fileio.c:(.text+0x508): undefined reference to `__p___mb_cur_max' fileiol.o:fileio.c:(.text+0x59a): undefined reference to `__p___mb_cur_max' fileiol.o:fileio.c:(.text+0x5b7): undefined reference to `__p___mb_cur_max' fileiol.o:fileio.c:(.text+0x61b): undefined reference to `__p___mb_cur_max' fileiol.o:fileio.c:(.text+0x64c): more undefined references to `__p___mb_cur_max' follow Yet as previously mentioned, mb_cur_max is exported my libmsvcrt.a. I'm stumped. 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 be possible to have this added? Thank you, Chris -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public 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. Regards, Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] pdh - 32bit
On Fri, Jul 30, 2010 at 4:55 AM, Ozkan Sezer seze...@gmail.com wrote: On Fri, Jul 30, 2010 at 7:14 AM, Alon Bar-Lev alon.bar...@gmail.com wrote: Thank you! You're welcome! When do you consider releasing 1.1 or something similar with new improvements from trunk but stable? Admins can answer that better. Hopefully soon. We (read: I) have to put together a wiki page describing our release policies and whatnot. -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] oaidl.h incorrect definitions for VARDESC, TYPEDESC and ELEMDESC for anonymous functions
Hello,
I've installed i686-w64-mingw32 for darwin target (20100730), and I'm
trying to cross-compile a Ruby extension that uses oleauto (it is
bundled with Ruby sources and is called win32ole).
During the cross compilation, I've received the following (in this
gist), pasted below:
/Users/luis/.rake-compiler/sources/ruby-1.9.2-rc2/ext/win32ole/win32ole.c:
In function ‘ole_const_load’:
/Users/luis/.rake-compiler/sources/ruby-1.9.2-rc2/ext/win32ole/win32ole.c:2504:39:
error: ‘VARDESC’ has no member named ‘u’
/Users/luis/.rake-compiler/sources/ruby-1.9.2-rc2/ext/win32ole/win32ole.c:
In function ‘ole_usertype2val’:
/Users/luis/.rake-compiler/sources/ruby-1.9.2-rc2/ext/win32ole/win32ole.c:4541:44:
error: ‘TYPEDESC’ has no member named ‘u’
/Users/luis/.rake-compiler/sources/ruby-1.9.2-rc2/ext/win32ole/win32ole.c:
In function ‘ole_ptrtype2val’:
/Users/luis/.rake-compiler/sources/ruby-1.9.2-rc2/ext/win32ole/win32ole.c:4564:13:
error: ‘TYPEDESC’ has no member named ‘u’
/Users/luis/.rake-compiler/sources/ruby-1.9.2-rc2/ext/win32ole/win32ole.c:
In function ‘ole_variable_value’:
/Users/luis/.rake-compiler/sources/ruby-1.9.2-rc2/ext/win32ole/win32ole.c:6297:31:
error: ‘VARDESC’ has no member named ‘u’
/Users/luis/.rake-compiler/sources/ruby-1.9.2-rc2/ext/win32ole/win32ole.c:
In function ‘ole_param_flag_mask’:
/Users/luis/.rake-compiler/sources/ruby-1.9.2-rc2/ext/win32ole/win32ole.c:7373:9:
error: ‘ELEMDESC’ has no member named ‘u’
/Users/luis/.rake-compiler/sources/ruby-1.9.2-rc2/ext/win32ole/win32ole.c:
In function ‘ole_param_default’:
/Users/luis/.rake-compiler/sources/ruby-1.9.2-rc2/ext/win32ole/win32ole.c:7475:19:
error: ‘ELEMDESC’ has no member named ‘u’
/Users/luis/.rake-compiler/sources/ruby-1.9.2-rc2/ext/win32ole/win32ole.c:7477:25:
error: ‘ELEMDESC’ has no member named ‘u’
After looking into win32ole.c, found that it defined the following:
#if defined NONAMELESSUNION __GNUC__
#define V_UNION1(X, Y) ((X)-u.Y)
Also, found this part:
#if defined NONAMELESSUNION __GNUC__
#undef V_UNION
#define V_UNION(X,Y) ((X)-n1.n2.n3.Y)
Which clearly indicates hardcoded information for the Variant elements
of the union.
Since Ruby compiled successfully with GCC 3.4.5 and TDM-1 binary
distributions, took the liberty to inspect into w64 headers, specially
where VARDESC and others are defined (oaidl.h).
Found the following:
typedef struct tagVARDESC {
MEMBERID memid;
LPOLESTR lpstrSchema;
__MINGW_EXTENSION union {
ULONG oInst;
VARIANT *lpvarValue;
};
ELEMDESC elemdescVar;
WORD wVarFlags;
VARKIND varkind;
} VARDESC;
Clearly, the use of __MINGW_EXTENSION differs from mingw headers where
uses _ANONYMOUS_UNION
Also, it lacks a name for the union, something that in tdm and mingw
headers is defined as DUMMYUNIONNAME
Changed the definition of VARDESC, TYPEDESC and ELEMDESC to
_ANONYMOUS_UNION and named the union DUMMYUNIONNAME:
typedef struct tagVARDESC {
MEMBERID memid;
LPOLESTR lpstrSchema;
_ANONYMOUS_UNION union {
ULONG oInst;
VARIANT *lpvarValue;
} DUMMYUNIONNAME;
ELEMDESC elemdescVar;
WORD wVarFlags;
VARKIND varkind;
} VARDESC;
Doing the above change removed the compilation issue, succeed
compiling natively with GCC 3.4.5 and TDM1
I've also changed Ruby extension to use DUMMYUNIONNAME and
__VARIANT_NAME_1/2/3 to refer to n1, n2 and n3.
Apologize for my naive change, would like to know if is valid or not
and if so, if more details are needed to report it back.
Thank you.
--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] oaidl.h incorrect definitions for VARDESC, TYPEDESC and ELEMDESC for anonymous functions
On Sat, Jul 31, 2010 at 11:48 PM, Luis Lavena luislav...@gmail.com wrote:
Hello,
I've installed i686-w64-mingw32 for darwin target (20100730), and I'm
trying to cross-compile a Ruby extension that uses oleauto (it is
bundled with Ruby sources and is called win32ole).
During the cross compilation, I've received the following (in this
gist), pasted below:
/Users/luis/.rake-compiler/sources/ruby-1.9.2-rc2/ext/win32ole/win32ole.c:
In function ‘ole_const_load’:
/Users/luis/.rake-compiler/sources/ruby-1.9.2-rc2/ext/win32ole/win32ole.c:2504:39:
error: ‘VARDESC’ has no member named ‘u’
/Users/luis/.rake-compiler/sources/ruby-1.9.2-rc2/ext/win32ole/win32ole.c:
In function ‘ole_usertype2val’:
/Users/luis/.rake-compiler/sources/ruby-1.9.2-rc2/ext/win32ole/win32ole.c:4541:44:
error: ‘TYPEDESC’ has no member named ‘u’
/Users/luis/.rake-compiler/sources/ruby-1.9.2-rc2/ext/win32ole/win32ole.c:
In function ‘ole_ptrtype2val’:
/Users/luis/.rake-compiler/sources/ruby-1.9.2-rc2/ext/win32ole/win32ole.c:4564:13:
error: ‘TYPEDESC’ has no member named ‘u’
/Users/luis/.rake-compiler/sources/ruby-1.9.2-rc2/ext/win32ole/win32ole.c:
In function ‘ole_variable_value’:
/Users/luis/.rake-compiler/sources/ruby-1.9.2-rc2/ext/win32ole/win32ole.c:6297:31:
error: ‘VARDESC’ has no member named ‘u’
/Users/luis/.rake-compiler/sources/ruby-1.9.2-rc2/ext/win32ole/win32ole.c:
In function ‘ole_param_flag_mask’:
/Users/luis/.rake-compiler/sources/ruby-1.9.2-rc2/ext/win32ole/win32ole.c:7373:9:
error: ‘ELEMDESC’ has no member named ‘u’
/Users/luis/.rake-compiler/sources/ruby-1.9.2-rc2/ext/win32ole/win32ole.c:
In function ‘ole_param_default’:
/Users/luis/.rake-compiler/sources/ruby-1.9.2-rc2/ext/win32ole/win32ole.c:7475:19:
error: ‘ELEMDESC’ has no member named ‘u’
/Users/luis/.rake-compiler/sources/ruby-1.9.2-rc2/ext/win32ole/win32ole.c:7477:25:
error: ‘ELEMDESC’ has no member named ‘u’
After looking into win32ole.c, found that it defined the following:
#if defined NONAMELESSUNION __GNUC__
#define V_UNION1(X, Y) ((X)-u.Y)
Also, found this part:
#if defined NONAMELESSUNION __GNUC__
#undef V_UNION
#define V_UNION(X,Y) ((X)-n1.n2.n3.Y)
Which clearly indicates hardcoded information for the Variant elements
of the union.
Since Ruby compiled successfully with GCC 3.4.5 and TDM-1 binary
distributions, took the liberty to inspect into w64 headers, specially
where VARDESC and others are defined (oaidl.h).
Found the following:
typedef struct tagVARDESC {
MEMBERID memid;
LPOLESTR lpstrSchema;
__MINGW_EXTENSION union {
ULONG oInst;
VARIANT *lpvarValue;
};
ELEMDESC elemdescVar;
WORD wVarFlags;
VARKIND varkind;
} VARDESC;
Clearly, the use of __MINGW_EXTENSION differs from mingw headers where
uses _ANONYMOUS_UNION
Also, it lacks a name for the union, something that in tdm and mingw
headers is defined as DUMMYUNIONNAME
Changed the definition of VARDESC, TYPEDESC and ELEMDESC to
_ANONYMOUS_UNION and named the union DUMMYUNIONNAME:
typedef struct tagVARDESC {
MEMBERID memid;
LPOLESTR lpstrSchema;
_ANONYMOUS_UNION union {
ULONG oInst;
VARIANT *lpvarValue;
} DUMMYUNIONNAME;
ELEMDESC elemdescVar;
WORD wVarFlags;
VARKIND varkind;
} VARDESC;
Doing the above change removed the compilation issue, succeed
compiling natively with GCC 3.4.5 and TDM1
I've also changed Ruby extension to use DUMMYUNIONNAME and
__VARIANT_NAME_1/2/3 to refer to n1, n2 and n3.
Apologize for my naive change, would like to know if is valid or not
and if so, if more details are needed to report it back.
Thank you.
--
Luis Lavena
We might need a DUMMY* name audit for DUMMYUNIONNAME, however I do
wonder why you actually _need_ DUMMYUNIONNAME and use those union/struct
members with dummy names in the first place?
--
Ozkan
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] oaidl.h incorrect definitions for VARDESC, TYPEDESC and ELEMDESC for anonymous functions
On Sat, Jul 31, 2010 at 6:10 PM, Ozkan Sezer seze...@gmail.com wrote: We might need a DUMMY* name audit for DUMMYUNIONNAME, however I do wonder why you actually _need_ DUMMYUNIONNAME and use those union/struct members with dummy names in the first place? Sorry, I really meant why you actually _need_ the NONAMELESSUNION define Thank you for your answer. Looking at Ruby's source code and history, looks like this was defined in 2002 (!) in two blocks: #if defined NONAMELESSUNION __GNUC__ #define V_UNION1(X, Y) ((X)-u.Y) #else #define V_UNION1(X, Y) ((X)-Y) #endif V_UNION1 which is used further in the code as this: hr = pTypeInfo-lpVtbl-GetRefTypeInfo(pTypeInfo, V_UNION1(pTypeDesc, hreftype), pRefTypeInfo); And The following ones: #if defined NONAMELESSUNION __GNUC__ #undef V_UNION #define V_UNION(X,Y) ((X)-n1.n2.n3.Y) #undef V_VT #define V_VT(X) ((X)-n1.n2.vt) #undef V_BOOL #define V_BOOL(X) V_UNION(X,boolVal) #endif Which clearly indicates these elements didn't behave as expected by MinGW. I'm guessing as I'm not 100% familiarized with OLE If you think that is necessary today (2010), I'm going to send a patch for Ruby to get that fixed. Thank you for your time. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exupéry -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] oaidl.h incorrect definitions for VARDESC, TYPEDESC and ELEMDESC for anonymous functions
On Sat, Jul 31, 2010 at 6:28 PM, Ozkan Sezer seze...@gmail.com wrote: If that change goes back to 2002, then it was intended for really old gcc versions, The oldest I currently use from time to time is 3.4.5 and AFAIK it has no problems with nameless unions and structs. And surely the current 4.4.x and newer are also fine with them. Notice that the above macros still need NONAMELESSUNION to be explicitly defined somewhere. Therefore, I suspect it is defined in your makefiles? It is defined by the configure process which checks if platform is cygwin or mingw and defines it. If you think that is necessary today (2010), I'm going to send a patch for Ruby to get that fixed. All I can say is that defining NONAMELESSUNION is not necessary these days (actually not necessary for quite some time), and is obsolete. This is of course my personal opinion. I've checked in Ruby's source code and this is the only place been used. I have no idea in relation to cygwin's GCC and headers, but just removed mingw of that list and the extension compiled successfully. Thank you for your time and your valuable answers. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exupéry -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] oaidl.h incorrect definitions for VARDESC, TYPEDESC and ELEMDESC for anonymous functions
On Sun, Aug 1, 2010 at 12:52 AM, Luis Lavena luislav...@gmail.com wrote: On Sat, Jul 31, 2010 at 6:28 PM, Ozkan Sezer seze...@gmail.com wrote: If that change goes back to 2002, then it was intended for really old gcc versions, The oldest I currently use from time to time is 3.4.5 and AFAIK it has no problems with nameless unions and structs. And surely the current 4.4.x and newer are also fine with them. Notice that the above macros still need NONAMELESSUNION to be explicitly defined somewhere. Therefore, I suspect it is defined in your makefiles? It is defined by the configure process which checks if platform is cygwin or mingw and defines it. Well, it tries to play safe, but it would be more appropriate if it had also checked agaist the gcc version in use: If gcc = 3.4, I guess no need for that, at all. If you think that is necessary today (2010), I'm going to send a patch for Ruby to get that fixed. All I can say is that defining NONAMELESSUNION is not necessary these days (actually not necessary for quite some time), and is obsolete. This is of course my personal opinion. I've checked in Ruby's source code and this is the only place been used. I have no idea in relation to cygwin's GCC and headers, but just removed mingw of that list and the extension compiled successfully. Glad that it worked! (I still note that someday we need an audit for cases where NONAMELESSUNION is defined...) Thank you for your time and your valuable answers. You are welcome. If you have more questions in the future, don't hesitate to ask. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exupéry Cheers -- Ozkan -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Issues compiling Info-zip's zip 3.1c
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 -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] pdh - 32bit
On Sat, Jul 31, 2010 at 11:24 PM, NightStrike nightstr...@gmail.com wrote: Hopefully soon. We (read: I) have to put together a wiki page describing our release policies and whatnot. -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
