Re: [RFC] setup: allow building with i686-w64-mingw32

On 6/2/2012 02:40, Yaakov (Cygwin/X) wrote:
> On 2012-06-01 12:08, JonY wrote:
>>> 2) DDK headers can't find other DDK headers which they require.  IMHO
>>> those should be changed from<>  includes to "" includes in
>>> mingw64-headers.
>>
>> You are supposed to use -I/path/to/include/ddk to use the headers, this
>> is one of the differences with mingw.org.
> 
> That shouldn't be necessary IMO if I e.g. #include <ddk/ntifs.h>.
> 

No, I meant you are actually supposed to add it to your search path,
sort of like how glib/gtk headers are used with pkg-config. Maybe it's a
good idea to use .pc files.

>>> 3) Once I circumvent those, I get a ton of redefinition and conflicting
>>> declaration errors between winnt.h and ddk/ntddk.h.  Its too long to
>>> list here, so I suggest you give it a try.
>>
>> PSDK should not be used together with the DDK, Kai suggests using
>> winternl.h in place of ntddk.h.
> 
> That gets me closer.  I'm going AFK now, but with the attached patch the
> following errors remain:
> 

Some of these errors might be related to ntdef.h use, try removing it.
Some of these declarations are from wdm.h. So:

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

On Jun  4 09:10, Kai Tietz 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:
>  <at>  <at>  -88,7 +88,7  <at>  <at>  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.

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

On Mon, Jun 4, 2012 at 10:10 AM, Kai Tietz <ktietz70@...> 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:
>  <at>  <at>  -88,7 +88,7  <at>  <at>  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.

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

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)
 <at>  <at>  -450,10 +450,10  <at>  <at> 
    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

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

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.

------------------------------------------------------------------------------
Live Security Virtual Conference

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

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/

Re: [RFC] setup: allow building with i686-w64-mingw32

On 9/3/12, JonY <jon_y@...> wrote:
> On 8/30/2012 17:57, Yaakov (Cygwin/X) wrote:
>> On Thu, 2012-08-30 at 11:06 +0300, Ozkan Sezer wrote:
>>> I applied the last winternals patch as obvious to both stable/v2.x
>>> (r5376)
>>> and to trunk (r5377.)
>>
>> Thank you.
>>
>>> PS: Your work tree seems not up-to-date: patch applied with offsets.
>>
>> Simply a matter of applying patch 3 before patch 2 (which also touches
>> winternl.h).
>>
>>
>> Yaakov
>
> I'm not so sure about the 1st patch, 2nd patch looks OK. Ozkan, any
> comments?
>

No comments from me.

--
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