Re: [Mingw-w64-public] Fwd: [PATCH v1] setup: allow building with i686-w64-mingw32

2012-06-15 Thread Jacek Caban 
On 06/14/12 11:55, Yaakov (Cygwin/X) wrote:
 On 2012-06-12 03:51, Jacek Caban wrote:
 On 06/12/12 07:06, Yaakov (Cygwin/X) wrote:
 On 2012-06-04 04:04, Jacek Caban wrote:
 Where? I don't see any. There is one change to propkeydef.h, but and I
 believe incorrect. Generally, this patch makes REFIID and similar
 typedefs depend on CINTERFACE, which is not present in MSVC.
 According to these, it is:

 http://msdn.microsoft.com/en-us/library/ak5wyby1(v=vs.71).aspx
 http://social.msdn.microsoft.com/forums/en/vcgeneral/thread/80485378-3978-472b-ac76-a6a193cb9e47
 http://social.msdn.microsoft.com/Forums/en/vclanguage/thread/9e520505-5d05-4aad-83d9-a1b73042c531
 http://social.msdn.microsoft.com/Forums/en/vclanguage/thread/9b1b2189-c518-4cd8-80cc-2656b9c0d37f
 If there is any source of informations more misleading than MSDN, that's
 MSDN forums:) Why do you need that change? That's not what mingw.org
 does
 Both mingw.org and Wine support CINTERFACE wrt the REF*ID defines.


Thanks for the report, I've fixed Wine [1]. About mingw.org, it's up to
them, they are aware of the bug.

I took a look at Cygwin's source to see what all this discussion is
about and the problem is easier than I expected. It's just a matter of
one CoCreateInstance call that hits the problem, so even ugly ifdefs
wouldn't hurt too much. Anyway, I don't see why you use CINTERFACE at
all. Dropping it seems like a nice clean up and will solve the problem
(C++ variants of REF*IDs are compatible in all mingw variants and MSVC,
I believe). See the attached (not even compile-tested) patch. To fix the
problem, its main.cc part is enough. mlink2.cc is just a clean up.

Cheers,
Jacek


[1]
http://source.winehq.org/git/wine.git/commitdiff/4626db2bb2a61cdceb00e0e346628062ee51aade
Index: main.cc
===
RCS file: /cvs/cygwin-apps/setup/main.cc,v
retrieving revision 2.67
diff -u -p -r2.67 main.cc
--- main.cc 3 Jun 2012 15:00:06 -   2.67
+++ main.cc 14 Jun 2012 21:41:14 -
@@ -33,7 +33,6 @@ static const char *cvsid =
 
 #undef _WIN32_WINNT
 #define _WIN32_WINNT 0x0501
-#define CINTERFACE
 #include win32.h
 #include commctrl.h
 #include shlobj.h
@@ -161,8 +160,8 @@ main_display ()
   // done later, in the thread which actually creates the shortcuts.
   extern IShellLink *sl;
   CoInitializeEx (NULL, COINIT_APARTMENTTHREADED);
-  HRESULT res = CoCreateInstance (CLSID_ShellLink, NULL,
- CLSCTX_INPROC_SERVER, IID_IShellLink,
+  HRESULT res = CoCreateInstance (CLSID_ShellLink, NULL,
+ CLSCTX_INPROC_SERVER, IID_IShellLink,
  (LPVOID *)  sl);
   if (res)
 {
@@ -209,7 +208,7 @@ main_display ()
 
   // Uninitalize COM
   if (sl)
-sl-lpVtbl-Release (sl);
+sl-Release ();
   CoUninitialize ();
 }
 
Index: mklink2.cc
===
RCS file: /cvs/cygwin-apps/setup/mklink2.cc,v
retrieving revision 2.12
diff -u -p -r2.12 mklink2.cc
--- mklink2.cc  10 Aug 2010 20:38:00 -  2.12
+++ mklink2.cc  14 Jun 2012 21:41:14 -
@@ -1,4 +1,3 @@
-#define CINTERFACE
 #include stdlib.h
 #include wchar.h
 #include win32.h
@@ -29,16 +28,16 @@ make_link_2 (char const *exepath, char c
   WCHAR widepath[MAX_PATH];
   if (sl)
 {
-  sl-lpVtbl-QueryInterface (sl, IID_IPersistFile, (void **) pf);
+  sl-QueryInterface (IID_IPersistFile, (void **) pf);
 
-  sl-lpVtbl-SetPath (sl, exepath);
-  sl-lpVtbl-SetArguments (sl, args);
-  sl-lpVtbl-SetIconLocation (sl, icon, 0);
+  sl-SetPath (exepath);
+  sl-SetArguments (args);
+  sl-SetIconLocation (icon, 0);
 
   MultiByteToWideChar (CP_ACP, 0, lname, -1, widepath, MAX_PATH);
-  pf-lpVtbl-Save (pf, widepath, TRUE);
+  pf-Save (pf, widepath, TRUE);
 
-  pf-lpVtbl-Release (pf);
+  pf-Release ();
 }
 }
 
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fwd: [PATCH v1] setup: allow building with i686-w64-mingw32

2012-06-15 Thread Yaakov (Cygwin/X) 
On 2012-06-15 03:46, Jacek Caban wrote:
 On 06/14/12 11:55, Yaakov (Cygwin/X) wrote:
 Both mingw.org and Wine support CINTERFACE wrt the REF*ID defines.

 Thanks for the report, I've fixed Wine [1].

Not AFAICS.  Look at all the places where REF*ID is taken as an argument 
which are conditional on CINTERFACE, e.g. later in Wine's guiddef.h, I 
don't think the CINTERFACE IsEqualGUID is going to work with C++ REF*ID 
types.  Also, you won't be able to test equality with C++ types without 
the operators.

Look also at mingw-w64's shobjidl.h (among others); the CINTERFACE 
QueryInterface vfuncs take REF*ID arguments, are those going to compile 
with C++ REF*ID?  I'm sure I could find many more examples, but if you 
look at all the 183 headers which use CINTERFACE, most (all?) of which 
use REF*ID types, doesn't it make sense that REF*ID must be C types if 
CINTERFACE?


Yaakov
Cygwin/X

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fwd: [PATCH v1] setup: allow building with i686-w64-mingw32

2012-06-15 Thread Jacek Caban 
On 06/15/12 11:42, Yaakov (Cygwin/X) wrote:
 On 2012-06-15 03:46, Jacek Caban wrote:
 On 06/14/12 11:55, Yaakov (Cygwin/X) wrote:
 Both mingw.org and Wine support CINTERFACE wrt the REF*ID defines.
 Thanks for the report, I've fixed Wine [1].
 Not AFAICS.  Look at all the places where REF*ID is taken as an argument 
 which are conditional on CINTERFACE, e.g. later in Wine's guiddef.h, I 
 don't think the CINTERFACE IsEqualGUID is going to work with C++ REF*ID 
 types.  Also, you won't be able to test equality with C++ types without 
 the operators.

 Look also at mingw-w64's shobjidl.h (among others); the CINTERFACE 
 QueryInterface vfuncs take REF*ID arguments, are those going to compile 
 with C++ REF*ID?

Sure they are going to compile, why not? You simply have to pass it as a
C++ reference, not a pointer. It's only the code that followed *broken*
mingw.org behaviour won't work.

 I'm sure I could find many more examples, but if you 
 look at all the 183 headers which use CINTERFACE, most (all?) of which 
 use REF*ID types, doesn't it make sense that REF*ID must be C types if 
 CINTERFACE?

I've explained it a few times already. Can you please take my patch
(call it clean up if you don't consider it a fix) and be done with it?

Jacek

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fwd: [PATCH v1] setup: allow building with i686-w64-mingw32

2012-06-14 Thread Yaakov (Cygwin/X) 
On 2012-06-12 03:51, Jacek Caban wrote:
 On 06/12/12 07:06, Yaakov (Cygwin/X) wrote:
 On 2012-06-04 04:04, Jacek Caban wrote:
 Where? I don't see any. There is one change to propkeydef.h, but and I
 believe incorrect. Generally, this patch makes REFIID and similar
 typedefs depend on CINTERFACE, which is not present in MSVC.
 According to these, it is:

 http://msdn.microsoft.com/en-us/library/ak5wyby1(v=vs.71).aspx
 http://social.msdn.microsoft.com/forums/en/vcgeneral/thread/80485378-3978-472b-ac76-a6a193cb9e47
 http://social.msdn.microsoft.com/Forums/en/vclanguage/thread/9e520505-5d05-4aad-83d9-a1b73042c531
 http://social.msdn.microsoft.com/Forums/en/vclanguage/thread/9b1b2189-c518-4cd8-80cc-2656b9c0d37f

 If there is any source of informations more misleading than MSDN, that's
 MSDN forums:) Why do you need that change? That's not what mingw.org
 does

Both mingw.org and Wine support CINTERFACE wrt the REF*ID defines.


Yaakov


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fwd: [PATCH v1] setup: allow building with i686-w64-mingw32

2012-06-14 Thread Yaakov (Cygwin/X) 
On 2012-06-12 04:37, Kai Tietz wrote:
 2012/6/12 Yaakov (Cygwin/X):
 Currently I get:

 /usr/i686-w64-mingw32/sys-root/mingw/lib/libmsvcrt.a(daqubs01139.o):(.text+0x0):
 multiple definition of `_swprintf'
 io_stream_file.o:/usr/i686-w64-mingw32/sys-root/mingw/include/wchar.h:547:
 first defined here

 How about this change instead to both headers:

 --- crt/wchar.h (revision 5094)
 +++ crt/wchar.h (working copy)
 @@ -450,10 +450,10 @@
int __cdecl __mingw_vsnwprintf (wchar_t * __restrict__ , size_t, const
 wchar_t * __restrict__ , va_list);

   #undef __mingw_ovr
 -#ifdef __cplusplus
 -#define __mingw_ovr  inline __cdecl
 -#elif defined (__GNUC__)
 +#if defined (__GNUC__)
   #define __mingw_ovr static __attribute__ ((__unused__)) __inline__ __cdecl
 +#elif defined(__cplusplus)
 +#define __mingw_ovr inline __cdecl
   #else
   #define __mingw_ovr static __cdecl
   #endif

 Hmm, that's looking wrong to me, too.  __GNUC__ gets defined also for
 c++, So issue might be more related to inline being not inlined.
 Could you provide me a small sample to reproduce this issue?

$ cat test.cc
#include string

int
test_printf(const std::string str)
{
   return printf (str.c_str());
}

$ x86_64-w64-mingw32-g++ -c test.cc

$ x86_64-w64-mingw32-nm -C test.o
 b .bss
 d .data
 t .text
 t .text$printf
 T test_wprintf(std::string const)
  U std::string::c_str() const
  U __mingw_vprintf
 T printf

$ x86_64-w64-mingw32-g++ -shared -Wl,--out-implib,libtest.dll.a -o 
libtest.dll test.o
Creating library file: libtest.dll.a

$ x86_64-w64-mingw32-nm -C libtest.dll.a  | grep  ' T '
 T printf
 T test_printf(std::string const)

This code has no business exporting printf!  With my suggested change, 
however:

$ x86_64-w64-mingw32-nm -C test.o
 b .bss
 d .data
 t .text
003c T test_printf(std::string const)
  U std::string::c_str() const
  U __mingw_vprintf
 t printf

$ x86_64-w64-mingw32-nm -C libtest.dll.a | grep ' T '
 T test_printf(std::string const)


Yaakov
Cygwin/X

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fwd: [PATCH v1] setup: allow building with i686-w64-mingw32

2012-06-12 Thread Yaakov (Cygwin/X) 
On 2012-06-04 02:10, Kai Tietz wrote:
 The change in crt/wchar.h about __mingw_ovr macro looks wrong to me,
 or at least inconsistent.  As stdio.h has same macro.  At least a
 libstdc++ bootstrap test is required for this change.

Currently I get:

/usr/i686-w64-mingw32/sys-root/mingw/lib/libmsvcrt.a(daqubs01139.o):(.text+0x0):
 
multiple definition of `_swprintf'
io_stream_file.o:/usr/i686-w64-mingw32/sys-root/mingw/include/wchar.h:547: 
first defined here

How about this change instead to both headers:

--- crt/wchar.h (revision 5094)
+++ crt/wchar.h (working copy)
@@ -450,10 +450,10 @@
int __cdecl __mingw_vsnwprintf (wchar_t * __restrict__ , size_t, 
const wchar_t * __restrict__ , va_list);

  #undef __mingw_ovr
-#ifdef __cplusplus
-#define __mingw_ovr  inline __cdecl
-#elif defined (__GNUC__)
+#if defined (__GNUC__)
  #define __mingw_ovr static __attribute__ ((__unused__)) __inline__ __cdecl
+#elif defined(__cplusplus)
+#define __mingw_ovr inline __cdecl
  #else
  #define __mingw_ovr static __cdecl
  #endif

 The hunk in winnt.h:
 @@ -88,7 +88,7 @@ extern C {

   #includebasetsd.h

 -#if defined(_X86_) || defined(__ia64__) || defined(__x86_64)
 +#if defined(__W32API_USE_DLLIMPORT__)  (defined(_X86_) ||
 defined(__ia64__) || defined(__x86_64))
   #define DECLSPEC_IMPORT __declspec(dllimport)
   #else
   #define DECLSPEC_IMPORT

 I would like to see here a different macro-name and the logic needs to
 be inverted.  Our default scenario uses dllimport and just in cygwin's
 setup-case we don't want it.
 So I would like to see here instead: !defined (__NO_USE_DLLIMPORT)

How about just !defined(DECLSPEC_IMPORT)?


Yaakov
Cygwin/X

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fwd: [PATCH v1] setup: allow building with i686-w64-mingw32

2012-06-12 Thread Yaakov (Cygwin/X) 
On 2012-06-04 04:04, Jacek Caban wrote:
 Where? I don't see any. There is one change to propkeydef.h, but and I
 believe incorrect. Generally, this patch makes REFIID and similar
 typedefs depend on CINTERFACE, which is not present in MSVC.

According to these, it is:

http://msdn.microsoft.com/en-us/library/ak5wyby1(v=vs.71).aspx
http://social.msdn.microsoft.com/forums/en/vcgeneral/thread/80485378-3978-472b-ac76-a6a193cb9e47
http://social.msdn.microsoft.com/Forums/en/vclanguage/thread/9e520505-5d05-4aad-83d9-a1b73042c531
http://social.msdn.microsoft.com/Forums/en/vclanguage/thread/9b1b2189-c518-4cd8-80cc-2656b9c0d37f


Yaakov
Cygwin/X

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fwd: [PATCH v1] setup: allow building with i686-w64-mingw32

2012-06-12 Thread Jacek Caban 
On 06/12/12 07:06, Yaakov (Cygwin/X) wrote:
 On 2012-06-04 04:04, Jacek Caban wrote:
 Where? I don't see any. There is one change to propkeydef.h, but and I
 believe incorrect. Generally, this patch makes REFIID and similar
 typedefs depend on CINTERFACE, which is not present in MSVC.
 According to these, it is:

 http://msdn.microsoft.com/en-us/library/ak5wyby1(v=vs.71).aspx
 http://social.msdn.microsoft.com/forums/en/vcgeneral/thread/80485378-3978-472b-ac76-a6a193cb9e47
 http://social.msdn.microsoft.com/Forums/en/vclanguage/thread/9e520505-5d05-4aad-83d9-a1b73042c531
 http://social.msdn.microsoft.com/Forums/en/vclanguage/thread/9b1b2189-c518-4cd8-80cc-2656b9c0d37f

If there is any source of informations more misleading than MSDN, that's
MSDN forums:) Why do you need that change? That's not what mingw.org
does nor MSVC, so why is it needed for your code? Can you please point
me to the code that doesn't compile without this change?

Jacek

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fwd: [PATCH v1] setup: allow building with i686-w64-mingw32

2012-06-12 Thread Jacek Caban 
On 06/12/12 10:51, Jacek Caban wrote:
 On 06/12/12 07:06, Yaakov (Cygwin/X) wrote:
 On 2012-06-04 04:04, Jacek Caban wrote:
 Where? I don't see any. There is one change to propkeydef.h, but and I
 believe incorrect. Generally, this patch makes REFIID and similar
 typedefs depend on CINTERFACE, which is not present in MSVC.
 According to these, it is:

 http://msdn.microsoft.com/en-us/library/ak5wyby1(v=vs.71).aspx
 http://social.msdn.microsoft.com/forums/en/vcgeneral/thread/80485378-3978-472b-ac76-a6a193cb9e47
 http://social.msdn.microsoft.com/Forums/en/vclanguage/thread/9e520505-5d05-4aad-83d9-a1b73042c531
 http://social.msdn.microsoft.com/Forums/en/vclanguage/thread/9b1b2189-c518-4cd8-80cc-2656b9c0d37f
 If there is any source of informations more misleading than MSDN, that's
 MSDN forums:) Why do you need that change? That's not what mingw.org
 does nor MSVC, so why is it needed for your code? Can you please point
 me to the code that doesn't compile without this change?

I double checked and mingw.org apparently has this bug. Anyway, that's
still a bug on their side that I don't think we want to duplicate.

Jacek

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fwd: [PATCH v1] setup: allow building with i686-w64-mingw32

2012-06-12 Thread Earnie Boyd 
On Tue, Jun 12, 2012 at 5:11 AM, Jacek Caban wrote:
 On 06/12/12 10:51, Jacek Caban wrote:
 On 06/12/12 07:06, Yaakov (Cygwin/X) wrote:
 On 2012-06-04 04:04, Jacek Caban wrote:
 Where? I don't see any. There is one change to propkeydef.h, but and I
 believe incorrect. Generally, this patch makes REFIID and similar
 typedefs depend on CINTERFACE, which is not present in MSVC.
 According to these, it is:

 http://msdn.microsoft.com/en-us/library/ak5wyby1(v=vs.71).aspx

Isn't this specific to COM and an IDL compiler?

quote
Remarks

By default, only COM-interfaces that are base classes of the coclass
are added in the IDL coclass. implements lets you force other
interfaces to be IDL coclass members.
/quote

 http://social.msdn.microsoft.com/forums/en/vcgeneral/thread/80485378-3978-472b-ac76-a6a193cb9e47
 http://social.msdn.microsoft.com/Forums/en/vclanguage/thread/9e520505-5d05-4aad-83d9-a1b73042c531
 http://social.msdn.microsoft.com/Forums/en/vclanguage/thread/9b1b2189-c518-4cd8-80cc-2656b9c0d37f

I didn't bother looking at social.msdn because it might influence me
with code I don't want to see.

 If there is any source of informations more misleading than MSDN, that's
 MSDN forums:) Why do you need that change? That's not what mingw.org
 does nor MSVC, so why is it needed for your code? Can you please point
 me to the code that doesn't compile without this change?

 I double checked and mingw.org apparently has this bug. Anyway, that's
 still a bug on their side that I don't think we want to duplicate.

We (mingw.org) doesn't support COM and never has.  A GCC supported IDL
compiler would be great but whose going to pick up the support on
that?

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fwd: [PATCH v1] setup: allow building with i686-w64-mingw32

2012-06-12 Thread Earnie Boyd 
On Tue, Jun 12, 2012 at 6:53 AM, Earnie Boyd wrote:
 We (mingw.org) doesn't support COM and never has.  A GCC supported IDL
 compiler would be great but whose going to pick up the support on
 that?

Please excuse my improper English, s/doesn't/do not/

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fwd: [PATCH v1] setup: allow building with i686-w64-mingw32

2012-06-12 Thread Jacek Caban 
On 06/12/12 12:53, Earnie Boyd wrote:
 On Tue, Jun 12, 2012 at 5:11 AM, Jacek Caban wrote:
 On 06/12/12 10:51, Jacek Caban wrote:
 On 06/12/12 07:06, Yaakov (Cygwin/X) wrote:
 On 2012-06-04 04:04, Jacek Caban wrote:
 Where? I don't see any. There is one change to propkeydef.h, but and I
 believe incorrect. Generally, this patch makes REFIID and similar
 typedefs depend on CINTERFACE, which is not present in MSVC.
 According to these, it is:

 http://msdn.microsoft.com/en-us/library/ak5wyby1(v=vs.71).aspx
 Isn't this specific to COM and an IDL compiler?

 quote
 Remarks

 By default, only COM-interfaces that are base classes of the coclass
 are added in the IDL coclass. implements lets you force other
 interfaces to be IDL coclass members.
 /quote

There is some misunderstanding here, perhaps I wasn't clear enough,
sorry. Let me explain it in more details.

IDL interfaces (and classes) have two forms. One is class-based for C++
and another is struct-based for C. Those are binary compatible as the C
version contains C++-compatible vtbls. It's possible to use C form of
interfaces from C++. That's what CINTERFACE does - it causes headers to
use C variant of interfaces even when compiled in C++. That's all fine
AFAIK in both mingw-w64 and mingw.org and the proposed patch doesn't
touch that part.

What the patch touches is REFIID type. It's a tricky type. That's a
macro invented to allow using C++ references and being still binary
compatible with C. REFIID is defined as |const IID| for C++ and |const
IID*| for C. Since C++ references are just pointers under the hood, it
all works together just fine after compilation. My point is that
REFIID's form *should not* depend on CINTERFACE. It's language-specific
and that's the way MS designed it.

Yet mingw.org has it depended on CINTERFACE and cygwin followed that
bug. I do not think we want to propagate this bug even further to
mingw-w64. Still, we need a solution. I can see two solutions:

- cygwin fixes it on their side
Sadly, that will require some preprocessor tricks detecting which
variant of mingw is used.

- mingw-w64 would introduce bug-compatibility macro
Say we'd define REFIID to C form in C++ if __CRT_C_REFS is defined.
Cygwin could just define this macron on command line and not change the
code. The difference between this solution and proposed patch is that
app would have to explicitly request this behaviour, so MSVC-compatible
apps would be still fine.

 http://social.msdn.microsoft.com/forums/en/vcgeneral/thread/80485378-3978-472b-ac76-a6a193cb9e47
 http://social.msdn.microsoft.com/Forums/en/vclanguage/thread/9e520505-5d05-4aad-83d9-a1b73042c531
 http://social.msdn.microsoft.com/Forums/en/vclanguage/thread/9b1b2189-c518-4cd8-80cc-2656b9c0d37f
 I didn't bother looking at social.msdn because it might influence me
 with code I don't want to see.

 If there is any source of informations more misleading than MSDN, that's
 MSDN forums:) Why do you need that change? That's not what mingw.org
 does nor MSVC, so why is it needed for your code? Can you please point
 me to the code that doesn't compile without this change?
 I double checked and mingw.org apparently has this bug. Anyway, that's
 still a bug on their side that I don't think we want to duplicate.
 We (mingw.org) doesn't support COM and never has.  A GCC supported IDL
 compiler would be great but whose going to pick up the support on
 that?

Well, mingw-w64 has already limited support for widl (Wine IDL compiler)
and I slowly improve it as a background project. It's sad that the way
current relationship between project look like, mingw.org would have to
duplicate those efforts. (Disclaimer: my primary project it Wine and I'm
mostly out of the loop about what's going on with mingw.org/mingw-w64,
so sorry if my impression is wrong  and don't take it as a voice of
mingw-w64 project). I have to ask about this: I've heard that mingw.org,
after RedHat's legal approval for mingw-w64, has no objections to use
mingw-w64's source. Why not to go one step further and simple use
mingw-w64 *instead* of w32api in mingw.org? That way even widl would
just work as good on mingw.org as it does on mingw-w64. That's just one
of many possible benefits. No efforts duplication, mingw.org wins a lot
of improvements, mingw-w64 wins more contributors. Has this been discussed?

Cheers,
Jacek

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fwd: [PATCH v1] setup: allow building with i686-w64-mingw32

2012-06-11 Thread Kai Tietz 
Yaakov, ping.

Not sure if you still have interest to get your patch into our
repository.  The part about hiding dllimport needs a change in your
patch.  Also your changes about MIDL part (see Jacek's comment for
this) need adjustment. I am still waiting for a revised version or it.
As soon as this patch will be approved and applied to our repository,
it will get into Fedora, too.

Regards,
Kai

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fwd: [PATCH v1] setup: allow building with i686-w64-mingw32

2012-06-06 Thread JonY 
On 6/4/2012 18:00, JonY wrote:
 On 6/4/2012 17:04, Jacek Caban wrote:
 On 06/03/12 17:45, JonY wrote:
 Forwarding to mingw-w64 list.

 Some of the headers modified is generated from WINE widl, so the
 preprocessor should be changed instead, jacek?


 Where? I don't see any. There is one change to propkeydef.h, but and I
 believe incorrect. Generally, this patch makes REFIID and similar
 typedefs depend on CINTERFACE, which is not present in MSVC. Changing it
 is a serious danger for compatibility. Why is it needed?

 Jacek

 
 To clear things up, CINTERFACE is used for the style interface
 declaration, nothing to do with REFIID.
 
 In C++, it seems to be typical to use references rather than pointers to
 refer to IIDs, so hopefully Cygwin can fix the usage on their side.
 

Ping, Yaakov.



signature.asc
Description: OpenPGP digital signature
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fwd: [PATCH v1] setup: allow building with i686-w64-mingw32

2012-06-04 Thread Kai Tietz 
Hello,

here is my review about Yaakov's patch.

The change in crt/wchar.h about __mingw_ovr macro looks wrong to me,
or at least inconsistent.  As stdio.h has same macro.  At least a
libstdc++ bootstrap test is required for this change.

The hunks about guiddef.h are ok.
The hunk about ntdef.h is ok.  Also the changes for propkeydef.h header, too.

The hunk in winnt.h:
@@ -88,7 +88,7 @@ extern C {

 #include basetsd.h

-#if defined(_X86_) || defined(__ia64__) || defined(__x86_64)
+#if defined(__W32API_USE_DLLIMPORT__)  (defined(_X86_) ||
defined(__ia64__) || defined(__x86_64))
 #define DECLSPEC_IMPORT __declspec(dllimport)
 #else
 #define DECLSPEC_IMPORT

I would like to see here a different macro-name and the logic needs to
be inverted.  Our default scenario uses dllimport and just in cygwin's
setup-case we don't want it.
So I would like to see here instead: !defined (__NO_USE_DLLIMPORT)

Rest of the hunks for winnt.h are ok.

The hunks about winternl.header are ok, beside one nit.  The change in
FILE_RENAME_INFORMATION about RootDir from HANDLE to ULONG type I am
not sure.  If it should be a integer-scalar instead of a pointer, is
it sure that it is for 64-bit also just 32-bit wide?  I would think we
should use here DWORD_PTR instead.


Regards,
Kai

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fwd: [PATCH v1] setup: allow building with i686-w64-mingw32

2012-06-04 Thread Ozkan Sezer 
On Mon, Jun 4, 2012 at 10:10 AM, Kai Tietz ktiet...@googlemail.com wrote:
 Hello,

 here is my review about Yaakov's patch.

 The change in crt/wchar.h about __mingw_ovr macro looks wrong to me,
 or at least inconsistent.  As stdio.h has same macro.  At least a
 libstdc++ bootstrap test is required for this change.

 The hunks about guiddef.h are ok.
 The hunk about ntdef.h is ok.  Also the changes for propkeydef.h header, too.

 The hunk in winnt.h:
 @@ -88,7 +88,7 @@ extern C {

  #include basetsd.h

 -#if defined(_X86_) || defined(__ia64__) || defined(__x86_64)
 +#if defined(__W32API_USE_DLLIMPORT__)  (defined(_X86_) ||
 defined(__ia64__) || defined(__x86_64))
  #define DECLSPEC_IMPORT __declspec(dllimport)
  #else
  #define DECLSPEC_IMPORT

 I would like to see here a different macro-name and the logic needs to
 be inverted.  Our default scenario uses dllimport and just in cygwin's
 setup-case we don't want it.
 So I would like to see here instead: !defined (__NO_USE_DLLIMPORT)

 Rest of the hunks for winnt.h are ok.

 The hunks about winternl.header are ok, beside one nit.  The change in
 FILE_RENAME_INFORMATION about RootDir from HANDLE to ULONG type I am
 not sure.  If it should be a integer-scalar instead of a pointer, is
 it sure that it is for 64-bit also just 32-bit wide?  I would think we
 should use here DWORD_PTR instead.


There is no such change in the patch but only member name changes
in the mentioned structure??  (fwiw, the member name changes seemed
correct to me, as well as the the len parameter type change from LONG to ULONG
for NtQueryInformationFile and the newly added FILE_LINK_INFORMATION.)


 Regards,
 Kai

--
O.S.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fwd: [PATCH v1] setup: allow building with i686-w64-mingw32

2012-06-04 Thread Jacek Caban 
On 06/03/12 17:45, JonY wrote:
 Forwarding to mingw-w64 list.

 Some of the headers modified is generated from WINE widl, so the
 preprocessor should be changed instead, jacek?


Where? I don't see any. There is one change to propkeydef.h, but and I
believe incorrect. Generally, this patch makes REFIID and similar
typedefs depend on CINTERFACE, which is not present in MSVC. Changing it
is a serious danger for compatibility. Why is it needed?

Jacek

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fwd: [PATCH v1] setup: allow building with i686-w64-mingw32

2012-06-03 Thread JonY 
On 6/3/2012 23:45, JonY wrote:

Resending because of Cygwin-apps block, accidentally left an email
address in.

 
 Forwarding to mingw-w64 list.
 
 Some of the headers modified is generated from WINE widl, so the
 preprocessor should be changed instead, jacek?
 
 Kai, Ozkan, what do you make of these changes (mingw64-headers.patch)?
 
  Original Message 
 Subject: [PATCH v1] setup: allow building with i686-w64-mingw32
 Date: Sun, 03 Jun 2012 09:19:29 -0500
 From: Yaakov (Cygwin/X)
 To: cygwin-apps
 
 On 2012-06-01 02:45, Yaakov (Cygwin/X) wrote:
 Fedora has switched from the i686-pc-mingw32 toolchain to the
 {i686,x86_64}-w64-mingw32 toolchains in F17. This means that setup
 cannot currently be built on F17.
 
 The attached draft patches for setup and mingw64-headers (r4913) allow
 setup to be built cleanly and work correctly (AFAICS) with both i686
 toolchains.
 
 The code also compiles cleanly on x86_64-w64-mingw32 but needs some
 additional LIBS as I circumvented autoload.c, which is clearly 32-bit
 specific and should be unnecessary on 64-bit Windows (being new enough
 to have all these functions).  This probably needs further functional
 changes and probably isn't useful until we have a 64-bit Cygwin, but it
 did expose some type incompatibilities.
 
 These are NOT ready to commit right now; they are being posted to help
 collaboration with mingw-w64 to make this work.
 
 
 Yaakov
 




signature.asc
Description: OpenPGP digital signature
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public