Re: [Mingw-w64-public] direct2d functions work with C++ API, but not with C API
Hello.
I was dealing with this exact problem some time ago.
Note the problem is wider. At certain point in time, Microsoft stopped to
care about C compatibility of (some of) their SDK headers. This includes
GDI+ and Direct2D APIs for example.
I.e. even if you somehow make it work with mingw-w64 headers, it would still
not be buildable with MSVC. If you need that, your options are even more
limited and Wine headers won't help you much as I think their headers are
not compatible with Microsoft SDK.
For my projects, I've eventually ended with creating C-compatible headers
for D2D and GDI+. You can find them here:
https://github.com/mity/c-win32
However note they are not a drop-in replacement for two reasons:
(1) They are designed to live alongside standard SDK headers: The cost of
this decision is that all their top-level identifiers differ ("c_" prefix).
(2) They provide only stuff I needed so they're incomplete in many ways.
That said however adding more stuff should be quite a straight-forward
exercise.
So whether this is the right path forward for you, I don't know. Depends
on your trade-off considerations and requirements.
Regards,
Martin
Dne 14. 1. 2022 v 18:16 Vincent Torri napsal(a):
> Hello
>
> first, I'm on Win10
>
> After initializing Direct2D, when I call
>
> ID2D1HwndRenderTarget_GetPixelSize
>
> with a HwndRenderTarget, i get a seg fault.
>
> But when I use the C++ API, no problem.
>
> there is the same behavior with GetPixelFormat()
>
> on the contrary, CreateBitmap(), DrawBitmap(), BeginDraw(), EndDraw()
> or SetTransform() are working with the C API.
>
> Does someone have an idea of the problem. I have a test program if you want
>
> thank you
>
> Vincent Torri
>
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] snprintf() vs. _snprintf()
Dne 22. 2. 2020 v 19:22 Dan Raymond napsal(a): > I don't think there is any doubt that something needs to be done to fix this. > +1 Although I hope that any solution would still allow apps to explicly choose the MSVCRTL.DLL if the app knows what it does. It may be written with that runtime in mind. > Pali submitted a patch that continues to use _snprintf but checks the result > and writes the necessary NUL terminator when truncation occurs. That fixes > the security hole. There are also other incompatibilities: - "%I64" (MSVCRT.DLL) versus "%lld" (standardized in C99; possibly supported in newer MSVCRT.DLL versions but AFAIK not in the old ones). - Or "%S" (MSVCRT.DLL) versus "%ws" (standard) (https://devblogs.microsoft.com/oldnewthing/20190830-00/?p=102823) (And possibly more.) I can imagine that use of those might also possibly have security implications. Consider what happens when _snprintf() skips what it sees as an invalid specifier. That may cause a shift in interpretation of the arguments and e.g. cause dereferencing an argument which is actually not a pointer. Also note this hits all the functions from the printf family. BR, Martin Mitas ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] Add some missing macros into winhttp.h
Hello, the subject says it all. The patch is in the attachment. BR, Martin Mitas diff --git a/mingw-w64-headers/include/winhttp.h b/mingw-w64-headers/include/winhttp.h index 1577c76c..1713f5b5 100644 --- a/mingw-w64-headers/include/winhttp.h +++ b/mingw-w64-headers/include/winhttp.h @@ -45,7 +45,9 @@ typedef INTERNET_PORT *LPINTERNET_PORT; #define INTERNET_SCHEME_SOCKS 4 typedef int INTERNET_SCHEME, *LPINTERNET_SCHEME; -#define ICU_ESCAPE 0x8000 +#define ICU_ESCAPE 0x8000 +#define ICU_ESCAPE_AUTHORITY0x2000 +#define ICU_REJECT_USERPWD 0x4000 /* flags for WinHttpOpen */ #define WINHTTP_FLAG_ASYNC 0x1000 @@ -62,6 +64,7 @@ typedef int INTERNET_SCHEME, *LPINTERNET_SCHEME; #define WINHTTP_ACCESS_TYPE_DEFAULT_PROXY 0 #define WINHTTP_ACCESS_TYPE_NO_PROXY1 #define WINHTTP_ACCESS_TYPE_NAMED_PROXY 3 +#define WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY 4 #define WINHTTP_NO_PROXY_NAME NULL #define WINHTTP_NO_PROXY_BYPASS NULL ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Project News|New Builds]
I recommend uploading those files to virustotal.com. It scans with plethora of antivirus engines and it can give you quite good idea whether it is really a false positive or not. AFAIK there is also good data exchange between virustotal.com and many AV vendors so this is often an indirect way how to make the AV vendor notice an issue :-) Of course, try also talking with people from sf.net what AV they are using and propagating the files to the AV vendor directly for further analysis. Usually AV vendors are quite responsive to such kind of reports. It is in any AV vendor's interest to fix false positives asap, especially of such popular SW. Often, the false positives are caused by too weakly defined pattern sample in their virus database which then can often be responsible for more false positives. Martin Dne 22. 8. 2017 v 15:24 niXman napsal(a): > Carl Kleffner 2017-08-22 15:57: >> Hi niXman, >> >> all 32bit builds are blocked by sf: >> >> "This file may contain malware and the automatic download has been >> disabled." > > Hi, > > Hmm... this is very strange... > > I think this is a false positives, because the build environment is the same > as I've been using for more than a year... > > All 7.2 builds removed until the cause is clarified. > > Thank you for report! > > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] DLL symbol decorations & gendef tool not distributed anymore
Well, given the purpose of mCtrl project, it's often seen as an extension of USER32.DLL and COMCTL32.DLL and as such it is better to follow their conventions. That includes stdcall and no decorations. Furthermore, in the past I was told from several sides that DLL can be used from some other languages on Windows iff the exported functions are stdcall. As far as I can remember, that included Delphi, VisualBasic and some other languages (often those made by MS). And, last but not least, such change at this point would mean quite nasty break of DLL's binary compatibility. M. Dne 17. 7. 2017 v 15:50 LRN napsal(a): > On 7/17/2017 1:21 PM, Martin Mitáš wrote: >> The aim is to have >> the DLL without the typical symbol suffix decorations (@num). >> >> Is there better way, how to achieve the goal without manual >> maintaining of two .def files? > > Um...don't use stdcall? IIRC, the @X decorations only apply to stdcall > functions. > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] DLL symbol decorations & gendef tool not distributed anymore
Hello. In the mCtrl project [1], we build a DLL. The aim is to have the DLL without the typical symbol suffix decorations (@num). This is to allow easy use of those symbols with LoadLibrary(). With mingw-w64, when linking against such DLL, the import lib still needs to provide the decorations as ld tries to find only decorated symbols. Unfortunately, AFAIK, the GNU linker has only the option -Wl,--kill-at. When not used, both the DLL and the generated import lib have those decorations, making the DLL unfriendly to LoadLibrary(). When used, none of those have those decorations, making the import lib unusable with the linker which has created it. That raises question whether it is really the intended behavior or bug of that option. With mingw-w64, I worked around by regenerating the import lib with gendef and dlltool [2]. But with recent mingw-w64 builds, the gendef is no longer distributed, making it an etxra pain for e.g. new people. Is there better way, how to achieve the goal without manual maintaining of two .def files? (The decorations differ in 32 and 64 bit builds.) Or can gendef be re-added into future mingw-build releases? [1]: https://gitgub.com/mity/mctrl [2]: https://github.com/mity/mctrl/blob/master/mctrl/CMakeLists.txt#L69 Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 detected by Windows Defender on Win 10
It likely really was false positive. Furthermore it's not detected anymore with definition update MS has released today. Martin Dne 27. 1. 2017 v 16:47 Kai Tietz napsal(a): > Well, not sure what your problem is. I don't encounter this problem > with windows defender. So I guess that you might have a virus on your > local system, or the heuristic of your defender has wrong positive. > As the Windows defender guys in doubt. > > Regards, > Kai > > > 2017-01-27 2:09 GMT+01:00 Martin Mitáš <m...@morous.org>: >> >> Hi, >> >> FYI, Windows Defender on Windows 10 with current definitions >> just started to (mis)detect some .exe files inside mingw-builds >> packages. >> >> I tried both rev0 and rev1 downloaded from here: >> https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/6.3.0/threads-win32/sjlj/ >> >> The following files are detected as "Trojan:Win32/Kandelo.B!d": >> >> file:C:\mingw32\bin\addr2line.exe >> file:C:\mingw32\bin\ld.bfd.exe >> file:C:\mingw32\bin\ld.exe >> file:C:\mingw32\bin\strings.exe >> file:C:\mingw32\i686-w64-mingw32\bin\ld.bfd.exe >> file:C:\mingw32\i686-w64-mingw32\bin\ld.exe >> file:C:\mingw32\libexec\gcc\i686-w64-mingw32\6.3.0\collect2.exe >> file:C:\mingw32\libexec\gcc\i686-w64-mingw32\6.3.0\lto-wrapper.exe >> file:C:\mingw32\libexec\gcc\i686-w64-mingw32\6.3.0\lto1.exe >> >> >> According to virustotal.com, no other Vendor detects it: >> https://virustotal.com/en/file/370f9b6d95ae2ad551e9db431e5696883b6a05203ba462fbd79b41f882de7ea7/analysis/ >> >> Hence I beliebe it's just a false positive in most recent definitions >> update. >> >> The workaround is to turn Windows Defender off (at least its runtime >> scanning), otherwise it blocks running those .exe and makes mingw-w64 >> installation unusable. >> >> Hopefully it's not their punishment for preferring mingw-w64 over >> VisualStudio :-) >> >> I reported to Microsoft through >> https://www.microsoft.com/en-us/security/portal/submission/submit.aspx >> >> Best regards, >> Martin >> >> -- >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> ___ >> Mingw-w64-public mailing list >> Mingw-w64-public@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] mingw-w64 detected by Windows Defender on Win 10
Hi, FYI, Windows Defender on Windows 10 with current definitions just started to (mis)detect some .exe files inside mingw-builds packages. I tried both rev0 and rev1 downloaded from here: https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/6.3.0/threads-win32/sjlj/ The following files are detected as "Trojan:Win32/Kandelo.B!d": file:C:\mingw32\bin\addr2line.exe file:C:\mingw32\bin\ld.bfd.exe file:C:\mingw32\bin\ld.exe file:C:\mingw32\bin\strings.exe file:C:\mingw32\i686-w64-mingw32\bin\ld.bfd.exe file:C:\mingw32\i686-w64-mingw32\bin\ld.exe file:C:\mingw32\libexec\gcc\i686-w64-mingw32\6.3.0\collect2.exe file:C:\mingw32\libexec\gcc\i686-w64-mingw32\6.3.0\lto-wrapper.exe file:C:\mingw32\libexec\gcc\i686-w64-mingw32\6.3.0\lto1.exe According to virustotal.com, no other Vendor detects it: https://virustotal.com/en/file/370f9b6d95ae2ad551e9db431e5696883b6a05203ba462fbd79b41f882de7ea7/analysis/ Hence I beliebe it's just a false positive in most recent definitions update. The workaround is to turn Windows Defender off (at least its runtime scanning), otherwise it blocks running those .exe and makes mingw-w64 installation unusable. Hopefully it's not their punishment for preferring mingw-w64 over VisualStudio :-) I reported to Microsoft through https://www.microsoft.com/en-us/security/portal/submission/submit.aspx Best regards, Martin -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Adding a new thread model to GCC
Dne 14. 4. 2016 v 5:02 Dongsheng Song napsal(a):
> Currently, --enable-threads=win32 map to gthr-win32.{h|c}, could we map
>
> --enable-threads=win32-vista
> --enable-threads=win32-win7 // Windows 7 and Windows Server 2008 R2
> --enable-threads=win32-win8 // Windows 8 and Windows Server 2012
> --enable-threads=win32-win8.1 // Windows 8.1 and Windows Server 2012 R2
> --enable-threads=win32-win10 // Windows 10 and Windows Server 2016
>
> to gthr-windows.{h|c} with the corresponding _WIN32_WINNT macros ?
Please don't.
Consider that something like -D_WIN32_WINNT=xy -DWINVER=_WIN32_WINNT
is often used by projects to see newer Win32API structures and #defines,
but the project often still supports older windows in run time. A lot
of code out there plays with GetProcAddress() but doesn't want to redefine
all the new types and constants.
Best regards,
Martin
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] windres option for -march?
Yes, if the _whole_ tool-chain is really multi-arch enabled. I already saw some gcc-based toolchain builds targeting Windows where actually only some of the tools were. And, unfortunately, the command line parameters are inconsistent among the tools. I use: * "-m32" or "-m64" for gcc (which is likely just a shortcut for some -march=XXX), * "--target=pe-x86-64" or "--target=pe-i386" for windres * "-m;i386:x86-64;-f;--64" or "-m;i386;-f;--32" for dlltool Hope this helps, Martin Dne 12. 4. 2016 v 20:58 Julien Darthenay napsal(a): > Hello, > > I try to build either a 64-bit program or a 32-bit with the same compiler. > It seems with "gcc" correct options could be, respectively, > "-march=x86-64" and "-march=athlon-xp". But I am unable to find the > options to use with "windres" to build the resource object file. Are > there any "windres" option to use to target 64-bit and 32-bit ? > > Regards, > > Julien Darthenay > > -- > Find and fix application performance issues faster with Applications Manager > Applications Manager provides deep performance insights into multiple tiers of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] winpthread and "leak"
Hello, after a glimpse into its sources I can see that there is InitializeCriticalSection() called in pthread_cond_init(). InitializeCriticalSection() is known to "leak" since Windows Vista: It allocates some kind of debug block which is then never released. If it is not desired behavior, InitializeCriticalSectionEx(CRITICAL_SECTION_NO_DEBUG_INFO) should be used instead. However InitializeCriticalSectionEx() is only available on Vista and newer as well, so for compatibility with Windows XP, it would have to use soma magic with GetProcAddress() to use one or the other. So if you are using pthread_cond_init() this could explain it. Martin Dne 30. 12. 2015 v 11:58 Vincent Torri napsal(a): > Hello > > With my little mem checker, i detect that winpthread does not free all > the resources it allocates. Is it normal ? > > thank you > > Vincent Torri > > -- > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [patch] d2d1.h: Fix macros ID2D1[.*]RenderTarget_CreateCompatible[.*]RenderTarget()
Macro ID2D1RenderTarget_CreateCompatibleRenderTarget() defined #if
D2D_USE_C_DEFINITIONS
in has wrong number of parameters. Ditto for all interfaces inherited
from
ID2D1RenderTarget.
Path is attached. BTW, are inline or attached patches preferred on this list?
Regards,
Martin
mingw-w64-headers/include/d2d1.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mingw-w64-headers/include/d2d1.h b/mingw-w64-headers/include/d2d1.h
index adfbc64..bc45785 100644
--- a/mingw-w64-headers/include/d2d1.h
+++ b/mingw-w64-headers/include/d2d1.h
@@ -1035,7 +1035,7 @@ interface ID2D1RenderTarget {
#define ID2D1RenderTarget_CreateBitmap(this,A,B,C,D,E)
(this)->lpVtbl->CreateBitmap(this,A,B,C,D,E)
#define ID2D1RenderTarget_CreateBitmapBrush(this,A,B)
(this)->lpVtbl->CreateBitmapBrush(this,A,B)
#define ID2D1RenderTarget_CreateBitmapFromWicBitmap(this,A,B,C)
(this)->lpVtbl->CreateBitmapFromWicBitmap(this,A,B,C)
-#define ID2D1RenderTarget_CreateCompatibleRenderTarget(this,A)
(this)->lpVtbl->CreateCompatibleRenderTarget(this,A)
+#define ID2D1RenderTarget_CreateCompatibleRenderTarget(this,A,B,C,D,E)
(this)->lpVtbl->CreateCompatibleRenderTarget(this,A,B,C,D,E)
#define ID2D1RenderTarget_CreateGradientStopCollection(this,A,B,C)
(this)->lpVtbl->CreateGradientStopCollection(this,A,B,C)
#define ID2D1RenderTarget_CreateLayer(this,A,B)
(this)->lpVtbl->CreateLayer(this,A,B)
#define ID2D1RenderTarget_CreateLinearGradientBrush(this,A,B,C,D)
(this)->lpVtbl->CreateLinearGradientBrush(this,A,B,C,D)
@@ -1327,7 +1327,7 @@ interface ID2D1BitmapRenderTarget {
#define ID2D1BitmapRenderTarget_CreateBitmap(this,A,B,C,D,E)
(this)->lpVtbl->Base.CreateBitmap((ID2D1RenderTarget*)(this),A,B,C,D,E)
#define ID2D1BitmapRenderTarget_CreateBitmapBrush(this,A,B)
(this)->lpVtbl->Base.CreateBitmapBrush((ID2D1RenderTarget*)(this),A,B)
#define ID2D1BitmapRenderTarget_CreateBitmapFromWicBitmap(this,A,B,C)
(this)->lpVtbl->Base.CreateBitmapFromWicBitmap((ID2D1RenderTarget*)(this),A,B,C)
-#define ID2D1BitmapRenderTarget_CreateCompatibleBitmapRenderTarget(this,A)
(this)->lpVtbl->Base.CreateCompatibleBitmapRenderTarget((ID2D1RenderTarget*)(this),A)
+#define
ID2D1BitmapRenderTarget_CreateCompatibleBitmapRenderTarget(this,A,B,C,D,E)
(this)->lpVtbl->Base.CreateCompatibleBitmapRenderTarget((ID2D1RenderTarget*)(this),A,B,C,D,E)
#define ID2D1BitmapRenderTarget_CreateGradientStopCollection(this,A,B,C)
(this)->lpVtbl->Base.CreateGradientStopCollection((ID2D1RenderTarget*)(this),A,B,C)
#define ID2D1BitmapRenderTarget_CreateLayer(this,A,B)
(this)->lpVtbl->Base.CreateLayer((ID2D1RenderTarget*)(this),A,B)
#define ID2D1BitmapRenderTarget_CreateLinearGradientBrush(this,A,B,C,D)
(this)->lpVtbl->Base.CreateLinearGradientBrush((ID2D1RenderTarget*)(this),A,B,C,D)
@@ -1409,7 +1409,7 @@ interface ID2D1DCRenderTarget
#define ID2D1DCRenderTarget_CreateBitmap(this,A,B,C,D,E)
(this)->lpVtbl->Base.CreateBitmap((ID2D1RenderTarget*)(this),A,B,C,D,E)
#define ID2D1DCRenderTarget_CreateBitmapBrush(this,A,B)
(this)->lpVtbl->Base.CreateBitmapBrush((ID2D1RenderTarget*)(this),A,B)
#define ID2D1DCRenderTarget_CreateBitmapFromWicBitmap(this,A,B,C)
(this)->lpVtbl->Base.CreateBitmapFromWicBitmap((ID2D1RenderTarget*)(this),A,B,C)
-#define ID2D1DCRenderTarget_CreateCompatibleRenderTarget(this,A)
(this)->lpVtbl->Base.CreateCompatibleRenderTarget((ID2D1RenderTarget*)(this),A)
+#define ID2D1DCRenderTarget_CreateCompatibleRenderTarget(this,A,B,C,D,E)
(this)->lpVtbl->Base.CreateCompatibleRenderTarget((ID2D1RenderTarget*)(this),A,B,C,D,E)
#define ID2D1DCRenderTarget_CreateGradientStopCollection(this,A,B,C)
(this)->lpVtbl->Base.CreateGradientStopCollection((ID2D1RenderTarget*)(this),A,B,C)
#define ID2D1DCRenderTarget_CreateLayer(this,A,B)
(this)->lpVtbl->Base.CreateLayer((ID2D1RenderTarget*)(this),A,B)
#define ID2D1DCRenderTarget_CreateLinearGradientBrush(this,A,B,C,D)
(this)->lpVtbl->Base.CreateLinearGradientBrush((ID2D1RenderTarget*)(this),A,B,C,D)
@@ -1903,7 +1903,7 @@ interface ID2D1HwndRenderTarget {
#define ID2D1HwndRenderTarget_CreateBitmap(this,A,B,C,D,E)
(this)->lpVtbl->Base.CreateBitmap((ID2D1RenderTarget*)(this),A,B,C,D,E)
#define ID2D1HwndRenderTarget_CreateBitmapBrush(this,A,B)
(this)->lpVtbl->Base.CreateBitmapBrush((ID2D1RenderTarget*)(this),A,B)
#define ID2D1HwndRenderTarget_CreateBitmapFromWicBitmap(this,A,B,C)
(this)->lpVtbl->Base.CreateBitmapFromWicBitmap((ID2D1RenderTarget*)(this),A,B,C)
-#define ID2D1HwndRenderTarget_CreateCompatibleRenderTarget(this,A)
(this)->lpVtbl->Base.CreateCompatibleRenderTarget((ID2D1RenderTarget*)(this),A)
+#define ID2D1HwndRenderTarget_CreateCompatibleRenderTarget(this,A,B,C,D,E)
(this)->lpVtbl->Base.CreateCompatibleRenderTarget((ID2D1RenderTarget*)(this),A,B,C,D,E)
#define ID2D1HwndRenderTarget_CreateGradientStopCollection(this,A,B,C)
(this)->lpVtbl->Base.CreateGradientStopCollection((ID2D1RenderTarget*)(this),A,B,C)
#define ID2D1HwndRenderTarget_CreateLayer(this,A,B)
Re: [Mingw-w64-public] Request for mingw-w64 website update
Dne 2. 9. 2015 v 11:15 Adrien Nader napsal(a): > Hi, > > On Wed, Sep 02, 2015, Martin Mitáš wrote: >> >> Hello, >> >> A few days ago, I tried to register on the http://mingw-w64.org in order >> to edit link to mCtrl project as it has been migrated from [old] to [new]. >> (mCtrl is listed on the homepage as one of projects using mingw-w64.) >> >> Unfortunately, it seems the registration process is broken. It doesn't >> ask for a password and it either doesn't send any generated password by >> e-mail or whatever. >> >> (Who knows how it is supposed to work? The registration wizard does not >> tell anything useful in this regard.) > > It's actually supposed to work in the obvious way: if you don't enter a > password, you get a mail giving you a generated one which you can > change afterwards. > > I've had one previous report of a registration issue but the cause was > not obvious unfortunately (mail stuff is *fun*, not). > > Did you try to register with the same mail address as the one you've > used to send this e-mail? I believe so. > >> So could someone with write access update the link for me, please? >> >> Links: >> [old] http://mctrl.sf.net >> [new] http://mctrl.org > > I've updated it. It's worth noting that the main page has specific > edition restrictions (no other page has that). Currently, Jonathan and I > can change it (the list isn't set in stone at all but it's meant to be > at least a bit restrictive). Thanks. Martin -- Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] About the recent sourceforge events
Umm, it is much more complicated then that. There are many mingw-w64 repos on github: (1) mirror/mingw-w64, which is likely a mirror repo on sf.net [1], (2) as of now, 7 forks of the above [2] (AndreRH's repo is one of these), (3) mingw-w64/mingw-w64 [3], where 1st mingw-w64 stands for an organization account [4] (i.e. not a personal account). However there are no public members, i.e. only those within the organization can see user accounts which are members of the organization so I have no idea who is behind that. If it is no one from mingw-w64 of project's core developer, perhaps you could try to contact github's support to get some contact to them. [1] https://github.com/mirror/mingw-w64 [2] https://github.com/mirror/mingw-w64/network/members [3] https://github.com/mingw-w64/mingw-w64 [4] https://github.com/blog/674-introducing-organizations Regards, Martin Dne 11. 6. 2015 v 22:50 Vincent Torri napsal(a): On Thu, Jun 11, 2015 at 9:54 PM, Adrien Nader adr...@notk.org wrote: On github there's already https://github.com/mingw-w64 but I have no idea who is behind that. https://github.com/AndreRH it seems that he's a Wine guy, according to his website Vincent -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] how to use ld.gold as the linker?
AFAIK, ld.gold is designed to output only ELF [1] binaries (and the
specialization is what makes it superior to GNU ld when outputting ELF),
while Windows use PE [2] binaries.
So you cannot.
[1] https://en.wikipedia.org/wiki/Executable_and_Linkable_Format
[2] https://en.wikipedia.org/wiki/Portable_Executable
Martin
Dne 15. 5. 2015 v 6:41 zhangxinghai napsal(a):
Hi,all
My OS is xp sp3
I used the i686-4.9.2-release-posix-dwarf-rt_v4-rev2.7z build from site
http://sourceforge.net/projects/mingw-w64
I write a helloworld.cpp program
#includestdio.h
#includeiostream
int main()
{
int i1=1,i2=2;
int sum = i1 + i2;
printf(%d\n,sum);
return 0;
}
when I use g++ -o hello.exe hello.cpp,It works well.Now I want it to be
linked with ld.gold,I use g++ -o hello.exe hello.cpp -fuse-ld=gold -v,I get
following error,what is the problem and how to resolve it.
Great thanks
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=D:/mingw32-gcc-4.9.2/mingw32/bin/../libexec/gcc/i686-w64-mingw32/4.9.2/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../../../src/gcc-4.9.2/configure --host=i686-w64-mingw32
--build=i686-w64-mingw32 --target=i686-w64-mingw32 --prefix=/mingw32
--with-sysroot=/c/mingw492/i686-492-posix-dwarf-rt_v4-rev2/mingw32
--with-gxx-include-dir=/mingw32/i686-w64-mingw32/include/c++ --enable-shared
--enable-static --disable-multilib
--enable-languages=ada,c,c++,fortran,objc,obj-c++,lto
--enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp
--enable-libatomic --enable-lto --enable-graphite --enable-checking=release
--enable-fully-dynamic-string --enable-version-specific-runtime-libs
--disable-sjlj-exceptions --with-dwarf2 --disable-isl-version-check
--disable-cloog-version-check --disable-libstdcxx-pch
--disable-libstdcxx-debug --enable-bootstrap --disable-rpath
--disable-win32-registry --disable-nls --disable-werror --disable-symvers
--with-gnu-as --with-gnu-ld --with-arch=i686 --with-tune=generic
--with-libiconv --with-system-zlib
--with-gmp=/c/mingw492/prerequisites/i686-w64-mingw32-static
--with-mpfr=/c/mingw492/prerequisites/i686-w64-mingw32-static
--with-mpc=/c/mingw492/prerequisites/i686-w64-mingw32-static
--with-isl=/c/mingw492/prerequisites/i686-w64-mingw32-static
--with-cloog=/c/mingw492/prerequisites/i686-w64-mingw32-static
--enable-cloog-backend=isl --with-pkgversion='i686-posix-dwarf-rev2, Built by
MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64
CFLAGS='-O2 -pipe
-I/c/mingw492/i686-492-posix-dwarf-rt_v4-rev2/mingw32/opt/include
-I/c/mingw492/prerequisites/i686-zlib-static/include
-I/c/mingw492/prerequisites/i686-w64-mingw32-static/include' CXXFLAGS='-O2
-pipe -I/c/mingw492/i686-492-posix-dwarf-rt_v4-rev2/mingw32/opt/include
-I/c/mingw492/prerequisites/i686-zlib-static/include
-I/c/mingw492/prerequisites/i686-w64-mingw32-static/include' CPPFLAGS=
LDFLAGS='-pipe -L/c/mingw492/i686-492-posix-dwarf-rt_v4-rev2/mingw32/opt/lib
-L/c/mingw492/prerequisites/i686-zlib-static/lib
-L/c/mingw492/prerequisites/i686-w64-mingw32-static/lib
-Wl,--large-address-aware'
Thread model: posix
gcc version 4.9.2 (i686-posix-dwarf-rev2, Built by MinGW-W64 project)
COLLECT_GCC_OPTIONS='-o' 'hello.exe' '-fuse-ld=gold' '-v' '-shared-libgcc'
'-mtune=generic' '-march=i686'
D:/mingw32-gcc-4.9.2/mingw32/bin/../libexec/gcc/i686-w64-mingw32/4.9.2/cc1plus.exe
-quiet -v -iprefix
D:/mingw32-gcc-4.9.2/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.9.2/
-D_REENTRANT hello.cpp -quiet -dumpbase hello.cpp -mtune=generic -march=i686
-auxbase hello -version -fuse-ld=gold -o d:\tmp\ccEEmv6M.s
GNU C++ (i686-posix-dwarf-rev2, Built by MinGW-W64 project) version 4.9.2
(i686-w64-mingw32)
compiled by GNU C version 4.9.2, GMP version 6.0.0, MPFR version 3.1.2-p9,
MPC version 1.0.2
warning: MPFR header version 3.1.2-p9 differs from library version 3.1.2-p10.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory
D:/mingw32-gcc-4.9.2/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/4.9.2/include
ignoring nonexistent directory
C:/mingw492/i686-492-posix-dwarf-rt_v4-rev2/mingw32C:/msys64/mingw32/lib/gcc/i686-w64-mingw32/4.9.2/../../../../include
ignoring duplicate directory
D:/mingw32-gcc-4.9.2/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/4.9.2/include-fixed
ignoring duplicate directory
D:/mingw32-gcc-4.9.2/mingw32/lib/gcc/../../lib/gcc/i686-w64-mingw32/4.9.2/../../../../i686-w64-mingw32/include
ignoring nonexistent directory
C:/mingw492/i686-492-posix-dwarf-rt_v4-rev2/mingw32/mingw/include
#include ... search starts here:
#include ... search starts here:
D:/mingw32-gcc-4.9.2/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.9.2/include
D:/mingw32-gcc-4.9.2/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.9.2/include-fixed
Re: [Mingw-w64-public] printf speedup [PATCH]
Dne 1. 4. 2015 v 10:13 Mattias Engdegård napsal(a): 1 apr 2015 kl. 05.35 skrev Dongsheng Song dongsheng.s...@gmail.com: In my testing, getenv() is very fast. *) unset PRINTF_EXPONENT_DIGITS preheat 1 times, then perform 100 times (use 4.6 seconds) getenv cost: 4.6 us *) set PRINTF_EXPONENT_DIGITS=3 preheat 1 times, then perform 100 times (use 3.41991 seconds) getenv: 3.41991 us 4 µs is a lot on a modern CPU, and an unacceptable overhead for a basic library function such as sprintf. If I assume getenv() iterates over complete environment in most cases (when PRINTF_EXPONENT_DIGITS is not set), then there is probably much worse overhead in a real world programs which is not likely covered in a trivial test program. The function getenv() shall replace data in CPU cache, which are likely useful for the ongoing program computation, with a lot of junk (the complete process environment). Morous -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Direct2D sample runs with Studio Express but not with mingw-w64
Fixed the DemoApp.cpp by rewriting the line 216 as follows:
// D2D1_SIZE_F rtSize = m_pRenderTarget-GetSize();
D2D1_SIZE_F rtSize = { 640, 480 };
Seems that calling ID2D1RenderTarget::GetSize() is broken when
called from gcc-compiled object.
This particular method is a bit uncommon in that it returns
a structure (with two float members) instead of a scalar type
such as HRESULT or void.
Perhaps there is some bug/incompatibility between MS ABI and gcc
in such case?
Martin
Dne 23. 12. 2014 v 7:28 Jack Andrews napsal(a):
Hi,
The sample on msdn (and the SDK) Draw Rectangle Example
http://msdn.microsoft.com/en-us/library/windows/desktop/dd371016(v=vs.85).aspx
...runs when built in Visual Studio Express 2010 (32 bit compiled) but fails
when built on mingw-64 (also 32bit).
I've appended the source for convenience. Many thanks in advance.
Jack.
$ g++ -m32 -mwindows -g DemoApp.cpp -o d -L/mingw/lib -lole32 -loleaut32
-ld2d1
jack@tp ~/g
$ gdb ./d
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as i686-w64-mingw32.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from c:\Users\jack\g\d.exe...done.
(gdb) r
Starting program: c:\Users\jack\g/./d.exe
[New Thread 73872.0x3294]
[New Thread 73872.0x12bd0]
Program received signal SIGSEGV, Segmentation fault.
0x77226c41 in d2d1!D2D1InvertMatrix () from C:\Windows\SysWOW64\d2d1.dll
(gdb) where
#0 0x77226c41 in d2d1!D2D1InvertMatrix () from C:\Windows\SysWOW64\d2d1.dll
#1 0x7721ef62 in d2d1!D2D1InvertMatrix () from C:\Windows\SysWOW64\d2d1.dll
#2 0x0040220b in DemoApp::OnRender (this=0x28fe6c) at DemoApp.cpp:222
#3 0x0040292a in DemoApp::WndProc (hwnd=0x6e129c, message=15, wParam=0,
lParam=0) at DemoApp.cpp:348
#4 0x748d62fa in gapfnScSendMessage () from C:\Windows\syswow64\user32.dll
#5 0x006e129c in ?? ()
#6 0x748d6d3a in USER32!GetThreadDesktop ()
from C:\Windows\syswow64\user32.dll
#7 0x00402818 in DemoApp::OnResize(unsigned int, unsigned int) ()
at DemoApp.cpp:294
#8 0x748d6de8 in USER32!GetThreadDesktop ()
from C:\Windows\syswow64\user32.dll
#9 0x in ?? ()
(gdb)
jack@tp ~/g
$ g++ -v
Reading specs from c:/mingw/bin/../lib/gcc/i686-w64-mingw32/4.8.2/specs
COLLECT_GCC=c:\mingw\bin\g++.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/i686-w64-mingw32/4.8.2/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../gcc-4.8.2/configure --prefix=/opt/windows_32
--with-sysroot=/opt/windows_32 --libdir=/opt/windows_32/lib
--mandir=/opt/windows_32/man --infodir=/opt/windows_32/info --enable-shared
--disable-bootstrap --disable-multilib --with-arch=pentium3
--enable-threads=posix --enable-languages=c,c++ --enable-checking=release
--with-system-zlib --with-python-dir=/lib/python2.7/site-packages
--disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp
--with-gnu-ld --verbose --enable-java-home
--with-java-home=/opt/windows_32/lib/jvm/jre
--with-jvm-root-dir=/opt/windows_32/lib/jvm
--with-jvm-jar-dir=/opt/windows_32/lib/jvm/jvm-exports
--with-arch-directory=amd64
--with-antlr-jar='/home/adrien/projects/win-builds-1.4/slackware64-current/d/gcc/antlr-*.jar'
--disable-java-awt --disable-gtktest --build=x86_64-slackware-linux
--host=i686-w64-mingw32 --target=i686-w64-mingw32
Thread model: posix
gcc version 4.8.2 (GCC)
$ cat DemoApp.cpp
// THIS CODE AND INFORMATION IS PROVIDED AS IS WITHOUT WARRANTY OF
// ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO
// THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A
// PARTICULAR PURPOSE.
//
// Copyright (c) Microsoft Corporation. All rights reserved
#include DemoApp.h
// Provides the application entry point.
int WINAPI WinMain(
HINSTANCE /* hInstance */,
HINSTANCE /* hPrevInstance */,
LPSTR /* lpCmdLine */,
int /* nCmdShow */
)
{
// Use HeapSetInformation to specify that the process should
// terminate if the heap manager detects an error in any heap used
// by the process.
// The return value is ignored, because we want to continue running in the
// unlikely event that HeapSetInformation fails.
HeapSetInformation(NULL, HeapEnableTerminationOnCorruption, NULL, 0);
if (SUCCEEDED(CoInitialize(NULL)))
{
{
DemoApp app;
if (SUCCEEDED(app.Initialize()))
{
app.RunMessageLoop();
}
}
CoUninitialize();
}
return 0;
}
// DemoApp constructor
DemoApp::DemoApp() :
m_hwnd(NULL),
m_pDirect2dFactory(NULL),
Re: [Mingw-w64-public] Direct2D sample runs with Studio Express but not with mingw-w64
A comment in the pointed wine patch explains the situation quite well:
MS ABI handles returning of structure so that the function gets an implicit
extra parameter: address of the memory block to be filled by the function
iplementation.
I verified with the following hack:
(1) In d2d1.h, changed the method signature to this:
STDMETHOD_(void, GetSize)(D2D1_SIZE_F*) const PURE;
(2) Changed the call in the demo app to this:
D2D1_SIZE_F rtSize;
m_pRenderTarget-GetSize(rtSize);
And voila.
This imho confirms it is an issue with ABI and it should be fixed
in gcc: When stdcall calling convention is specified, it should
implement returning of structures via extra implicit parameter
but it does not. gcc probably treats returning of a small structure
as returning a scalar type of the same size.
I entered a bug in gcc bugzilla about this:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64384
Regards,
Martin
Dne 23. 12. 2014 v 12:14 Jacek Caban napsal(a):
Hi Martin,
It's very likely that it's a problem with ABI. Wine had a problem with
this function due to incompatibility of stdcall already:
https://www.winehq.org/pipermail/wine-patches/2014-September/134351.html
Unless stdcall is handled differently for mingw target, we need to fix
it in mingw as well. Kai may know more about this.
Jacek
On 12/23/14 11:55, Martin Mitáš wrote:
Fixed the DemoApp.cpp by rewriting the line 216 as follows:
// D2D1_SIZE_F rtSize = m_pRenderTarget-GetSize();
D2D1_SIZE_F rtSize = { 640, 480 };
Seems that calling ID2D1RenderTarget::GetSize() is broken when
called from gcc-compiled object.
This particular method is a bit uncommon in that it returns
a structure (with two float members) instead of a scalar type
such as HRESULT or void.
Perhaps there is some bug/incompatibility between MS ABI and gcc
in such case?
Martin
Dne 23. 12. 2014 v 7:28 Jack Andrews napsal(a):
Hi,
The sample on msdn (and the SDK) Draw Rectangle Example
http://msdn.microsoft.com/en-us/library/windows/desktop/dd371016(v=vs.85).aspx
...runs when built in Visual Studio Express 2010 (32 bit compiled) but
fails when built on mingw-64 (also 32bit).
I've appended the source for convenience. Many thanks in advance.
Jack.
$ g++ -m32 -mwindows -g DemoApp.cpp -o d -L/mingw/lib -lole32 -loleaut32
-ld2d1
jack@tp ~/g
$ gdb ./d
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as i686-w64-mingw32.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from c:\Users\jack\g\d.exe...done.
(gdb) r
Starting program: c:\Users\jack\g/./d.exe
[New Thread 73872.0x3294]
[New Thread 73872.0x12bd0]
Program received signal SIGSEGV, Segmentation fault.
0x77226c41 in d2d1!D2D1InvertMatrix () from C:\Windows\SysWOW64\d2d1.dll
(gdb) where
#0 0x77226c41 in d2d1!D2D1InvertMatrix () from C:\Windows\SysWOW64\d2d1.dll
#1 0x7721ef62 in d2d1!D2D1InvertMatrix () from C:\Windows\SysWOW64\d2d1.dll
#2 0x0040220b in DemoApp::OnRender (this=0x28fe6c) at DemoApp.cpp:222
#3 0x0040292a in DemoApp::WndProc (hwnd=0x6e129c, message=15, wParam=0,
lParam=0) at DemoApp.cpp:348
#4 0x748d62fa in gapfnScSendMessage () from C:\Windows\syswow64\user32.dll
#5 0x006e129c in ?? ()
#6 0x748d6d3a in USER32!GetThreadDesktop ()
from C:\Windows\syswow64\user32.dll
#7 0x00402818 in DemoApp::OnResize(unsigned int, unsigned int) ()
at DemoApp.cpp:294
#8 0x748d6de8 in USER32!GetThreadDesktop ()
from C:\Windows\syswow64\user32.dll
#9 0x in ?? ()
(gdb)
jack@tp ~/g
$ g++ -v
Reading specs from c:/mingw/bin/../lib/gcc/i686-w64-mingw32/4.8.2/specs
COLLECT_GCC=c:\mingw\bin\g++.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/i686-w64-mingw32/4.8.2/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../gcc-4.8.2/configure --prefix=/opt/windows_32
--with-sysroot=/opt/windows_32 --libdir=/opt/windows_32/lib
--mandir=/opt/windows_32/man --infodir=/opt/windows_32/info --enable-shared
--disable-bootstrap --disable-multilib --with-arch=pentium3
--enable-threads=posix --enable-languages=c,c++ --enable-checking=release
--with-system-zlib --with-python-dir=/lib/python2.7/site-packages
--disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp
--with-gnu-ld --verbose --enable-java-home
--with-java-home=/opt/windows_32/lib/jvm/jre
--with-jvm-root-dir=/opt/windows_32/lib/jvm
--with-jvm-jar-dir=/opt/windows_32/lib/jvm/jvm-exports
--with-arch-directory=amd64
--with-antlr-jar='/home/adrien/projects/win-builds-1.4/slackware64-current/d/gcc/antlr-*.jar'
--disable-java-awt --disable-gtktest --build=x86_64
Re: [Mingw-w64-public] Direct2D sample runs with Studio Express but not with mingw-w64
Kai,
I'm somewhat confused now. I always thought that stdcall is a calling convention
specified in a context of MS ABI, so that stdcall implies MS ABI at least
for
the purpose of calling of the particular function with the __stdcall specifier.
It's not an area of my expertise, so I may be wrong.
But regardless of the above... If I understand you correctly, it should work if
the ms_abi is in effect and, AFAIK, this should be default if target is
Windows.
Anyway, to be really sure I now tried to build the demo with -mabi=ms specified
explicitly. Yet, it just does not work.
Or do you try to say that current gcc's implementation of ms_abi is actually
a hybrid between MS ABI standard ans sysv standard due wine?
Martin
Dne 23. 12. 2014 v 15:39 Kai Tietz napsal(a):
Hi,
to report that as bug was a bit over-eager. stdcall has nothing to do
with aggregate-return-behavior.
gcc implements this already, and it is part of calling-convention.
The major issue here is that Wine uses gcc in linux-default-mode
(means sysv ABI), but of course MS-stuff expects MS-ABI here. The
attribute callee_pop_aggregate_return might be helpful here. And of
course it is required on Linux-side of world.
Regards,
Kai
2014-12-23 14:39 GMT+01:00 Martin Mitáš m...@morous.org:
A comment in the pointed wine patch explains the situation quite well:
MS ABI handles returning of structure so that the function gets an implicit
extra parameter: address of the memory block to be filled by the function
iplementation.
I verified with the following hack:
(1) In d2d1.h, changed the method signature to this:
STDMETHOD_(void, GetSize)(D2D1_SIZE_F*) const PURE;
(2) Changed the call in the demo app to this:
D2D1_SIZE_F rtSize;
m_pRenderTarget-GetSize(rtSize);
And voila.
This imho confirms it is an issue with ABI and it should be fixed
in gcc: When stdcall calling convention is specified, it should
implement returning of structures via extra implicit parameter
but it does not. gcc probably treats returning of a small structure
as returning a scalar type of the same size.
I entered a bug in gcc bugzilla about this:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64384
Regards,
Martin
Dne 23. 12. 2014 v 12:14 Jacek Caban napsal(a):
Hi Martin,
It's very likely that it's a problem with ABI. Wine had a problem with
this function due to incompatibility of stdcall already:
https://www.winehq.org/pipermail/wine-patches/2014-September/134351.html
Unless stdcall is handled differently for mingw target, we need to fix
it in mingw as well. Kai may know more about this.
Jacek
On 12/23/14 11:55, Martin Mitáš wrote:
Fixed the DemoApp.cpp by rewriting the line 216 as follows:
// D2D1_SIZE_F rtSize = m_pRenderTarget-GetSize();
D2D1_SIZE_F rtSize = { 640, 480 };
Seems that calling ID2D1RenderTarget::GetSize() is broken when
called from gcc-compiled object.
This particular method is a bit uncommon in that it returns
a structure (with two float members) instead of a scalar type
such as HRESULT or void.
Perhaps there is some bug/incompatibility between MS ABI and gcc
in such case?
Martin
Dne 23. 12. 2014 v 7:28 Jack Andrews napsal(a):
Hi,
The sample on msdn (and the SDK) Draw Rectangle Example
http://msdn.microsoft.com/en-us/library/windows/desktop/dd371016(v=vs.85).aspx
...runs when built in Visual Studio Express 2010 (32 bit compiled) but
fails when built on mingw-64 (also 32bit).
I've appended the source for convenience. Many thanks in advance.
Jack.
$ g++ -m32 -mwindows -g DemoApp.cpp -o d -L/mingw/lib -lole32 -loleaut32
-ld2d1
jack@tp ~/g
$ gdb ./d
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as i686-w64-mingw32.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from c:\Users\jack\g\d.exe...done.
(gdb) r
Starting program: c:\Users\jack\g/./d.exe
[New Thread 73872.0x3294]
[New Thread 73872.0x12bd0]
Program received signal SIGSEGV, Segmentation fault.
0x77226c41 in d2d1!D2D1InvertMatrix () from C:\Windows\SysWOW64\d2d1.dll
(gdb) where
#0 0x77226c41 in d2d1!D2D1InvertMatrix () from
C:\Windows\SysWOW64\d2d1.dll
#1 0x7721ef62 in d2d1!D2D1InvertMatrix () from
C:\Windows\SysWOW64\d2d1.dll
#2 0x0040220b in DemoApp::OnRender (this=0x28fe6c) at DemoApp.cpp:222
#3 0x0040292a in DemoApp::WndProc (hwnd=0x6e129c, message=15, wParam=0,
lParam=0) at DemoApp.cpp:348
#4 0x748d62fa in gapfnScSendMessage () from
C:\Windows\syswow64\user32.dll
#5 0x006e129c in ?? ()
#6 0x748d6d3a in USER32!GetThreadDesktop ()
from C:\Windows\syswow64\user32.dll
#7
Re: [Mingw-w64-public] dwrite.h error: duplicate member 'GetFontCollection'
Dne 19. 12. 2014 v 10:20 Jack Andrews napsal(a):
Thank you for mingw-w64.
I am writing a DLL extension in C (not C++) and I came across a problem when
I write test.c as:
$cat test.c
#include dwrite.h
compiling the above causes an error.
(shortened)
In the first error, the problem seems to be that the GetFontCollection
function is overloaded and C doesn't allow the same name for two members of a
struct.
If anyone can indicate a fix for one of these errors, I will prepare a patch.
First of all, note that in Microsoft SDK, dwrite.h seems to
ignore plain C completely and it requires C++. So even when
dwrite.h in mingw-w64 gets fixed, any code using it shall
become mingw-w64 specific and incompatible with MS SDK.
So the question is whether it is better to follow MS (and possibly
remove all C-specific hacks from dwrite.h to not send false signals),
or whether there is any sense in making mingw-w64 better then original
and fix it.
In the latter case, mingw-w64 can be fixed by renaming the inherited
methods (i.e. those wrapped by __cplusplus guard) which collide with
a method defined directly in the given interface.
For C++, this does not break anything, so compatibility with MS shall
be preserved.
So, if maintainers want to go that way, you may e.g. rename
GetFontCollection() on the line 1937 to something like
IDWriteTextFormat_GetFontCollection() and ditto for all the other
collisions. Such fix is quite trivial.
It may look ugly, but consider that in C++, non-virtual method
of the same name shadows the one inherited from the base class, so
calling it is also less straightforward:
class A {
public:
void foo(void) {}
};
class B {
public:
void foo(int x) {}
};
int
main(int argc, char** argv)
{
B b;
b.foo(); // compile time error (the only considered candidate is
B::foo() but that one requires int argument).
b.A::foo(); // ok
return 0;
}
Martin
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Project News | New Builds]
I know this is feature in at least one quite wide-spread antivirus. It implements something called file reputation service (in a cloud) and it simply sees any (executable) file which it does not know as potentially dangerous. The logic is that if it sees the file more often and for some time (and it still has not find a path to a virus database), it is likely safe and legitmate file. Some shields (e.g. web shield) may ask the cloud about the file reputation when you download it and it then may present the warning in the browser via browser extension. So as soon as it will see the file more often (and assuming there is no malware), the warning shall cease to appear. If you are using this particular antivirus, then mingw-w64 team cannot do anything with that: Any newly built executable file with unique hash shall trigger the same warning until it becomes more wide-spread. Other AV vendors may implement something similar too. Martin Dne 1. 11. 2014 v 8:12 Rashad M napsal(a): Hi , Download installer on chrome (Windows 7 32bit) gives weird warning. Screenshot attached. I understand this is not a issue as I am sure the installer is not dangerous. But this may scare people who are using an antivirus as that will report it dangerous or maybe delete the file! On Sat, Nov 1, 2014 at 12:01 PM, niXman i.nix...@autistici.org mailto:i.nix...@autistici.org wrote: Hi, Builds of MinGW-W64 based on GCC-4.9.1 is updated. MinGW-w64 is updated to c6f0d3d981c70ad31bb1c2bfc2850b827281e189 GDB is updated to 7.8.1 Links: 32-bit: posix-sjlj: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.1/threads-posix/sjlj/i686-4.9.1-release-posix-sjlj-rt_v3-rev3.7z posix-dwarf: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.1/threads-posix/dwarf/i686-4.9.1-release-posix-dwarf-rt_v3-rev3.7z win32-sjlj: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.1/threads-win32/sjlj/i686-4.9.1-release-win32-sjlj-rt_v3-rev3.7z win32-dwarf: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.1/threads-win32/dwarf/i686-4.9.1-release-win32-dwarf-rt_v3-rev3.7z 64-bit: posix-sjlj: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.1/threads-posix/sjlj/x86_64-4.9.1-release-posix-sjlj-rt_v3-rev3.7z posix-seh: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.1/threads-posix/seh/x86_64-4.9.1-release-posix-seh-rt_v3-rev3.7z win32-sjlj: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.1/threads-win32/sjlj/x86_64-4.9.1-release-win32-sjlj-rt_v3-rev3.7z win32-seh: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.1/threads-win32/seh/x86_64-4.9.1-release-win32-seh-rt_v3-rev3.7z The online installer is also available: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/installer/mingw-w64-install.exe Builds based on GCC-4.9.2 will be uploaded soon. -- Regards, niXman ___ Dual-target(32 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows: http://sourceforge.net/projects/mingw-w64/ ___ Another online IDE: http://liveworkspace.org/ -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net mailto:Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Regards, Rashad -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] -shared vs. -mdll
Hi list, with mingw-w64, I'm used to build DLLs with gcc linker option -mdll. I am currently playing with CMake as I consider to leave manually maintained Makefiles behind me. It seems CMake prefers -shared over -mdll. I cannot find any docs how the two options differ. So, which one is the right one for normal DLL? Should I convince CMake that -mdll is better? And one bonus question (a bit off-topic for this list): If I should to convince it, do you know how? When I tried to use set(CMAKE_SHARED_LINKER_FLAGS -mwindows -mdll) then I've got an error: gcc.exe: error: shared and mdll are not compatible I also tried cmake -LAH to see where -shared comes from but it does not uncover that. Thanks for any info or pointers, Martin -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Coverity
Hello,
On 11.11.2013 22:22, Kai Tietz wrote:
Hello Mity,
2013/11/11 m...@morous.org:
Hi.
I'm using the Coverity scan [1] for static source analyzes for mCtrl
project [2] on a regular basis before each release. I've recently got some
false positives resulting from each usage of the macro InlineIsEqualGUID
from mingw-w64 system headers.
It actually results in reports similar to this:
CID 1127326 (#1 of 1): Out-of-bounds access (ARRAY_VS_SINGLETON)3.
ptr_arith: Using IID_IUnknown.Data1 as an array. This might corrupt or
misinterpret adjacent memory locations.
Obviously it is the result of the ugly casting the macro uses; it compares
two GUIDs as arrays of four DWORDs).
Are you interested to get patches improving such kinds of problems even if
they complicate the headers? (Well, I didn't yet think how to redefine the
macro to get rid of the issue, but I guess such redefinitions would be
more complex in general.)
Thanks,
Martin
Sure, we are interested in such patches
The patch is attached.
I've changed the definition of the macro InlineIsEqualGUID when
__cplusplus is not defined as well as the C++ inline function. I've
tested the former and it indeed removes the Coverity scan complains
(It resolves 17 of 19 issues the scan finds within mCtrl build ;-).
Please note it now uses __LONG32 which is correct only if __WIDL__ is
not #defined, according to the GUID struct definition at the beginning
of guiddef.h. However the macro/inline function were already guarded
by such condition so I took liberty to rely on it.
Best regards,
Martin
Index: mingw-w64-headers/include/guiddef.h
===
--- mingw-w64-headers/include/guiddef.h (revision 6368)
+++ mingw-w64-headers/include/guiddef.h (working copy)
@@ -149,7 +149,7 @@
#ifdef __cplusplus
__inline int InlineIsEqualGUID (REFGUID rguid1, REFGUID rguid2) {
- return ((rguid1.Data1)[0] == (rguid2.Data1)[0] (rguid1.Data1)[1] ==
(rguid2.Data1)[1] (rguid1.Data1)[2] == (rguid2.Data1)[2]
(rguid1.Data1)[3] == (rguid2.Data1)[3]);
+ return (((__LONG32*)(rguid1))[0] == ((__LONG32*)(rguid2))[0]
((__LONG32*)(rguid1))[1] == ((__LONG32*)(rguid2))[1]
((__LONG32*)(rguid1))[2] == ((__LONG32*)(rguid2))[2]
((__LONG32*)(rguid1))[3] == ((__LONG32*)(rguid2))[3]);
}
__inline int IsEqualGUID (REFGUID rguid1, REFGUID rguid2) {
@@ -156,7 +156,7 @@
return !memcmp (rguid1,rguid2, sizeof (GUID));
}
#else
-#define InlineIsEqualGUID(rguid1, rguid2) (((rguid1)-Data1)[0] ==
((rguid2)-Data1)[0] ((rguid1)-Data1)[1] == ((rguid2)-Data1)[1]
((rguid1)-Data1)[2] == ((rguid2)-Data1)[2] ((rguid1)-Data1)[3] ==
((rguid2)-Data1)[3])
+#define InlineIsEqualGUID(rguid1, rguid2) (((__LONG32*)(rguid1))[0] ==
((__LONG32*)(rguid2))[0] ((__LONG32*)(rguid1))[1] ==
((__LONG32*)(rguid2))[1] ((__LONG32*)(rguid1))[2] ==
((__LONG32*)(rguid2))[2] ((__LONG32*)(rguid1))[3] ==
((__LONG32*)(rguid2))[3])
#define IsEqualGUID(rguid1, rguid2) (!memcmp (rguid1, rguid2, sizeof (GUID)))
#endif
--
DreamFactory - Open Source REST JSON Services for HTML5 Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] windres vs. rc.exe: Different resource alignment
Hi all, I've been resolving some strange issues with resources ([1]). Although I did not succeed so far, I've spent some time in hex editor and reading objdump -s output (not much fun). My analyzes has exhibited some differences in how windres and Microsoft's rc.exe layout the .rsrc section. In particular I noticed the rc.exe places data of the resources to 64-bit aligned offsets, even in 32-bit builds. That guarantees the FindResource() + LoadResource() + LockResource() gets a pointer to data with such alignment. In contrast, windres aligns the resources only to 32-bits, even if target is x86_64. It does work but still it is IMHO suboptimal. I've tried to cook a patch to binutils ([2], [3]) but I've got no feedback. I do realize Windows is probably lower priority for most binutils developers, and it is my 1st patch for binutils so perhaps I've did something wrong but still... I hope some people on this ML probably may have more experience how to to push patches for binutils, or get some feedback if the patch is not satisfactory for binutils standards?? [1] https://github.com/mity/mctrl/issues/13 [2] https://sourceware.org/ml/binutils/2013-10/msg00305.html [3] https://sourceware.org/bugzilla/show_bug.cgi?id=16065 Thx, Martin -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Usability improvement: add debug breaks to abort() calls
The difference between using abort() and using a debug break is that debug break, if it goes unhandled, won't print the usual requrested to terminate blahblahblah stuff, and the exception code that WER shows will change from 0x4015 to 0x8003. That would mean that when not under debugger, user would have no idea what has happened and why his process just disappeared. I recommend to use __debugbreak()/DebugBreak() only when being debugged. Fortunately, Win32API has a function for detecting that: if(IsDebuggerPresent()) __debugbreak(); else abort(); (I use similar construction in my assert-like macros for my projects and I can confirm it really makes my debugging experience much easier.) Morous -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ 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: [Mingwbuilds-users] Is Win 2000 supported?
On 22.7.2013 21:56, niXman wrote: 2013/7/22 Martin Mitáš So here is result of the test: The binaries built with rev0 and rev1 do work on Windows 2000, but the latest rev2 does not, i.e. the regression is something relatively recent. Please try any of 4.8.2-prerelease: http://sourceforge.net/projects/mingwbuilds/files/host-windows/testing/4.8.2/ Broken on Win2000 the same way as 4.8.1rev2. M. -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] End of rubenvb builds
On 10.7.2013 8:58, Koehne Kai wrote: While the question about what current users are using is already hard to answer, there's IMO a bigger one: What _potential_ users are there that aren't already using mingw-w64 :) I started looking into mingw-w64 maybe a year ago, only to find out that - there's no 'official' installer/ toolchain - there are a whole bunch of 'personal' builds mingw-w64 derived projects - different projects provide a myriad of different gcc versions x architecture x exception handling mechanism x threading library combinations (and again, little hints on what is the 'recommended' configuration for most users). (Disclaimer: Written not in an attempt to put you down, but in a hope such feedback is valuable for you.) A bit off-topic but I can sign that too. I was using mingw for a long time and when I felt the need to also build my projects for x64, it took me about _two_long_years_ until I finally switched from mingw (i.e., I was already quite close and the transition should be sooo easy), and when I finally did, it was only for x64 builds for another months. The reason for the long consideration was I was waiting for some official build/toolchain, thinking at that time you yourself (as a mingw-w64 team) do not consider it ready for general use until you have one... It is simply the matter of fact that newcomer does not know where to click to get basic info what he should download to get something standard when he has no special requirements. Instead you place him in front of too many (potentially difficult) questions like What is that exception type thing and what is the right for me? or What the hell is cross-compiling? and (arguably worse) Which developer of this project makes the best work in making the package? or (probably the worst) They cannot agree with one another so each of them need their own build? How can they work as a team? I do not say that not offering any option is the right way. But there should be something what is default. And the default should be offered as that. It should be much more visible, and available in a click or two from the homepage. And last but not least, the default should not be tagged as a personal build. You should minimize the number of question he needs to answer to get just some compiler to build my program with. To summarize, IMO, mingw-w64, although technically as good as it is, emits bad signals to newcomers. Unfortunately, it has always been repelling for new users and, I believe, it is also the reason why mingw-builds (although also not ideal for sure) succeeded so easily. It simply filled the gap in the demand, which you never attempted to fill. Best regards, Martin -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] MSYS2
Hi Alexey,
I have just tried the 64-bit package on Win 7. I unpacked it it into
C:\msys as a replacement of my old MSYS package (not sure where it came
from). It could be an old MSYS package from the mingw project). I am
using console2 [1], which is set to use the following command as my shell:
c:\msys\bin\bash.exe --login -i
I have some issues with it:
* With your package, my $HOME/.profile is completely ignored.
* Command which is missing. My old MSYS package was having it
implemented as a script (attached).
* Many commands (e.g. ls, basename, ...) start with writing the
following error message to stderr:
0 [main] basename 3784 stdio_init: couldn't make stderr distinct
from stdout
It is funny because ls 2/dev/null suppresses it so it seems the two
are distinct after all...
* The package contains some remnants from your machine which should be
probably cleaned before releasing:
-- home/alexey
-- shortcuts mintty.exe-.lnk or MSys2.lnk, both pointing
somewhere into C:\test
But other then that, I was able to use it to build my projects after
some twiddling with $PATH to override the gcc toolchain used in the
package. Perhaps it would be better to not include gcc.exe and related
without the platform triplet in the package as (arguably) most people
would prefer use these from their mingw-w64, mingw-builds or other gcc
toolchain package as the default one.
[1] https://sourceforge.net/projects/console
Regards,
Morous
On 6.6.2013 22:17, Алексей Павлов wrote:
Hi, everybody!
I have work on creating MSYS2 based on latest Cygwin sources and now
create archives with alpha version.
Links:
32-bit: x32-msys2-alpha-20130607.7z
http://sourceforge.net/projects/msys2/files/Alpha-versions/32-bit/x32-msys2-alpha-20130607.7z/download
64-bit: x64-msys2-alpha-20130607.7z
http://sourceforge.net/projects/msys2/files/Alpha-versions/64-bit/x64-msys2-alpha-20130607.7z/download
MSYS2 is still using Cygwin like posix paths with /cygdrive prefix.
I would be happy if it can be tested by users who uses MSYS environment.
Information about issues you can send to alex...@gmail.com
mailto:alex...@gmail.com or in this thread.
Regards,
Alexey.
--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
#!/bin/sh
# Original copyright (C) 2002, Earnie Boyd
# mailto:ear...@users.sf.net
# This implementation copyright (C) 2006, 2008, Keith Marshall
# mailto:keithmarsh...@users.sf.net
#
# This file is part of MSYS
# http://www.mingw.org/msys.shtml
#
# File: which
# $Id: which,v 1.4 2009/03/14 14:13:32 keithmarshall Exp $
CMD=`IFS='\\/:'; set CMD $0; eval echo \$\{$#\}`
if test $# -lt 1
then
echo 2 $CMD: syntax error: missing argument
echo 2 Usage: $CMD [ -a | --all ] cmd ...
exit 1
fi
# To accomodate Woe32's typically asinine $PATH, which frequently
# includes directory names with embedded spaces, we need to set up
# $IFS to consider only a newline as a field separator.
IFS=$'\n'
break=break
for PROG
do
if test x$PROG = x-a || test x$PROG = x--all
then
break=
else
WHICH=
# need `type -ap -- $PROG || type -p -- $PROG'
# because `type -ap foo' reports nothing, if both `foo' and `foo.exe'
# are present, and are distinct.
for LIST in `type -ap -- $PROG || type -p -- $PROG`
do
if test -f $LIST
then
# preserve `.exe' extension
WHICH=$LIST`test -f $LIST.exe echo '.exe'`
if test $LIST != $WHICH
then
# detect distinct `foo' and `foo.exe'
# (this needs IFS=space, to get the INODE numbers)
IFS= INODE1=`ls -id $LIST` INODE2=`ls -id $WHICH`
if test `set ref $INODE1; echo $2` != `set ref $INODE2; echo $2`
then
# `foo' matches first, followed by `foo.exe'
test -z $break echo $LIST || WHICH=$LIST
fi
# reset IFS=newline, to get any further PROG names
IFS=$'\n'
fi
echo $WHICH
$break
fi
done
test x$WHICH = x echo 2 $CMD: $PROG: ${ERROR=unknown command}
fi
done
test ${ERROR+set} exit 1
exit 0
# $RCSfile: which,v $: end of file
--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
Re: [Mingw-w64-public] MSYS2
* Many commands (e.g. ls, basename, ...) start with writing the following error message to stderr: 0 [main] basename 3784 stdio_init: couldn't make stderr distinct from stdout It is funny because ls 2/dev/null suppresses it so it seems the two are distinct after all... Maybe: http://stackoverflow.com/questions/11868017/couldnt-make-stderr-distinct-from-stdout-when-running-cygwin-commands MSYS2 make builded with dos paths support. But I can't see your errors on my machine. Also try to execute under bash sh /etc/postinstall/000-msys-post-install.sh Yep, running the postinstall script did help. However it may be the 1st step on a dangerous road. I believe people who prefer MSYS instead of cygwin are those appreciating its simplicity, including the install process: Just unpack it and use it. Be careful to not create something what provides less features then cygwin, while being as complex as cygwin to install and use. * The package contains some remnants from your machine which should be probably cleaned before releasing: -- home/alexey -- shortcuts mintty.exe-.lnk or MSys2.lnk, both pointing somewhere into C:\test This is shortcuts is for minty.exe (in bin directory) and for console2 (in lib/Console2). You can fix them and start MSYS2 from this shortcuts. Consider that every potential user probably knows how to create a shortcut, creating it is about the same amount of work as fixing it, and if he wants it, he may have different idea where to place it (e.g. desktop). And it seems strange to distribute broken shortcuts on the first place. If you really want them, then at least they should point to some directory which can be considered default for MSYS installation (e.g. C:\msys instead of C:\test). Regards, Morous -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] New rubenvb Personal build: std::thread-enabled GCC 4.7 with MinGW-w64 trunk: gcc-4.7-1-stdthread
Dne 26.12.2012 22:01, Ruben Van Boxem napsal(a): Is it just for some transitional phase, or the new way from now forever (or until you decide to add yet another DLL depenencies)? Perhaps I might have forgotten to mention this is an *experimental* build. It allows you to use libstdc++'s multithreading capabilities. The plan is to add winpthreads to the MinGW-w64 crt, if it will be in dll form or not is unknown right now. It is not compulsory to use the posix GCC, and won't be in any near future I see. You haven't forgotten to mention the build is experimental but it hasn't been clear if it is a property of the experimental build only or the general direction where you go, so thanks for clarification. If you're building with GCC you already depend on the libgcc dll, unless you link statically, in which case the winpthreads library will also be linked statically. I use only link options -mwindows -municode -mdll, but there is no dependency on libgcc.dll in my binaries. I always thought the static linking to libgcc is the default one. I might of course add -static-libgcc explicitly, that's no issue for me. I do not understand why every C application should depend on it even though it does not use posix threads at all (including the C++ thread machinery). I strictly play within Win32API boundaries. The reason lies deep within GCC's internals: the compiler produces code which calls internal functions which are implemented in libgcc. If GCC is built with posix threads on Windows, libgcc might (there was a report that this was true, I don't remember all the details at this time, and you could easily check this yourself in the specific case of your library) depend on winpthreads. I know gcc team was working on something like that but I always assumed that it is for the C++11's thread, __thead keyword for thread local storage, all the automagical parallelism language extensions like AutoMP, (experimental?) optimization passes doing the same and similar stuff, and that when I stick with pure old C, compiler should not generate anything what needs to link against it. Anyway, the eventual dependency is part of the toolchain, so anyone who uses your library should have access to the same compiler anyways. No. mCtrl is buildable by mingw-w64, mingw-builds as well as MSVC, and making it buldable in any other toolchain supporting Win32API should be possible quite fast, probably by just rewriting the MAKEFILE or MSVC project file. The product (MCTRL.DLL) should be binary compatible whether you build it in MSVC or by mingw-w64, and I cross-test the examples from time to time. The API of MCTRL.DLL is strictly Win32API-like. It does not depend on any toolchain-specific types like FILE etc. It is intended to be used by any compiler which can call STDCALL functions. This includes MSVC, Embarcadero C++ builder (successor of Borland), mingw(-w64) and its derivatives, but also other languages (!) like VisualBasic, Python etc. I know it's not a win-win. I can't change the reality of things, especially the Unix-centricity of the GCC implementation (or that of any major open source project). Unfortunately, a decent C++11 multithreading implementation will require Windows Vista, and the Windows GCC developers have not decided to drop XP compatibility. I do not accuse you for anything. I just search some info to see what troubles and risks are awaiting me and the project in the future, and (if they do) what options for solving them are available. Martin -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] 4.7.1-1-release by rubenvb
Dne 10.8.2012 15:50, Ruben Van Boxem napsal(a): 2012/8/10 m...@morous.org mailto:m...@morous.org Hi Ruben, thanks for the work. Just one point annoys me a bit: The Windows packages targeting win32 and win64 respectively differ in prefixes of binutils, e.g.: mingw32/bin/windres.exe vs. mingw64/bin/x86_64-w64-mingw32-windres.exe. This complicates things for those who (like me) need/want to use multiple mingw-w64 packages side by side. It would be cool if the packages would be consistent. I understand, but GCC/binutils classifies a i686-hosted x86_64-targetting compiler as a cross-compiler, so it puts the prefix there automatically. I'm not going to remove it, because this is handy for configure scripts (just pass --host=x86_64-w64-mingw32 and everything should work automagically). If you want a 64-bit targetting compiler without prefixes, download the x86_64...-win64 package, which is a native 64-bit to 64-bit compiler. It is best to use the full native compiler for everything, unless you have special requirements (like compiling 64-bit code on 32-bit Windows, or you need a 64-bit linker executable). Well, actually I would like the opposite: to have the 32bit targetting package also have the prefixes. Either way, currently the package has some binaries prefixed (gcc) and some not (binutils), which is IMO the worst possible situation. Morous -- 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] experimental 4.7 std::thread enabled build by rubenvb
You might have also noticed I rearranged the release part of thee rubenvb section of the Personal Builds, going in against my previous promise. At the time of this writing, there are the following directories: gcc-4.5-release gcc-4.6-release gcc-4.7-release gcc-4.7-experimental-stdthread clang-3.1-release gcc-dw2-4.6-release I have some problems with the clang package (i686-w64-mingw32-clang-3.1-release-win32_rubenvb.7z). This is my 1st try of clang/LLVM, so sorry if I these are known issues: (1) Any attempt to run clang (tried also few other things) from mingw32-dw2/bin results in a system complaining libgcc_s_dw2-1.dll is missing. I resolved by copying the one the gcc-based package i686-w64-mingw32-gcc-dw2-4.6.3-1-release-win32_rubenvb.7z. Shouldn't the DLL be packed in the clang package? (2) Ditto for libstdc++-6.dll. (3) How to compile resource scripts with the clang-based package? Is it possible at all? Is it possible to take object compiled with windres from gcc-based package and link with clang-created objects? Regards, Morous -- 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] experimental 4.7 std::thread enabled build by rubenvb
Clang for now uses gcc/g++ for linking, and uses its runtime libraries libgcc and libstdc++. The way I set this up is to extract the gcc-dw2 and clang-3.1 packages into the same directory. Then everything (C and C++ headers, linker) will be found. binutils etc. are still used, and I believe Clang should be able to link with windres generated objects. Sorry for not explaining clearer. I was planning on uploading a readme to the SF download pages, but I'm doing too much at once. Much better, the compilation now works smoothly. However there is still an issue with linking. When compiling a DLL (the command is below) from clang-built objects, I get linker errors for all symbols to-be-exported from the DLL. $ gcc -mwindows -municode -mdll mctrl.def $OBJECTS -o bin/mCtrl.dll -lcomctl32 -lole32 -loleaut32 -Wl,--kill-at Cannot export _DllGetVersion@4: symbol not found Cannot export _mcButton_Initialize@0: symbol not found Cannot export _mcButton_Terminate@0: symbol not found Cannot export _mcCreateDialogIndirectParamA@24: symbol not found Cannot export _mcCreateDialogIndirectParamW@24: symbol not found ... and many more alike ... I have tried specifying the export symbols in the sources via __declspec(dllexport) as well as with the .def file and both lead to the same errors. The same set of objects compiled with gcc and same options is linked correctly. Please note all the symbols-to-be-exported are __stdcall and so far I have tried 32bit build only so I guess the infamous symbol decorations probably play a role in the issue. (Well, I mostly experiment with clang to just get more warnings and code analyzes so it does not bother me right now, but you know...) Morous -- 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] bug: conversion of integers and other numbers not there
It works correctly, because sizeof(int) == 4 and 1250
is too big for 32 bits. If you take the least significant four bytes
of that value, you get (what a surprise) exactly 445948416.
The three vars are expanded from short to int and multiplicated
(still into an int), then the result is expanded to uint64_t by the
assignement, but it is already too late.
Use this instead:
uint64_t n = (uint64_t) cyl * head * sector;
Regards,
Mity
Dne 15.3.2012 0:15, Jim Michaels napsal(a):
bug: conversion of integers and other numbers not there.
#include iostream
#include tr1/stdint.h
using namespace std;
int main(void) {
unsigned short cyl=5000, head=5000, sector=5000;
uint64_t n=cyl * head * sector; //result should be
coutresult should be 1250:=nendl;
return 0;
}
/*
Wed 03/14/2012 16:10:39.73|C:\prj\test\mingw-w64\conversion|c
result should be 1250:=445948416
Wed 03/14/2012 16:10:46.90|C:\prj\test\mingw-w64\conversion|
*/
remember in engineering school they told us the compiler will convert
all shorts to ints, etc, yada yada?
well, this doesn't work in gcc.
I have tried this both with mingw, mingw-w64, and djgpp.
you can try this with 2027 auto build if you like.
-
Jim Michaels
jmich...@yahoo.com mailto:jmich...@yahoo.com
j...@jimscomputerrepairandwebdesign.com
mailto:j...@jimscomputerrepairandwebdesign.com
http://JimsComputerRepairandWebDesign.com
http://JesusnJim.com (my personal site, has software)
---
Computer memory measurements, SSD measurements, microsoft disk size
measurements (note: they will say GB or MB or KB or TB when it is not!):
[KiB] [MiB] [GiB] [TiB]
[2^10B=1,024B=1KiB]
[2^20B=1,048,576B=1MiB]
[2^30B=1,073,741,824B=1GiB]
[2^40B=1,099,511,627,776B=1TiB]
hard disk industry disk size measurements:
[KB] [MB] [GB] [TB]
[10^3B=1,000B=1KB]
[10^6B=1,000,000B=1MB]
[10^9B=1,000,000,000B=1GB]
[10^12B=1,000,000,000,000B=1TB]
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Where's make (specifically, x86_64-w64-mingw32-make.exe)?
If you need to use Unix-like shell inside of the makefile (e.g. sed, rm -rf etc.), download and install MSYS: https://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/MSYS%20%2832-bit%29/ The MSYS package contains the appropriate make. If using cmd.exe as a shell called from a Make is what you want, then AFAIK this is what you should use: https://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/make/ (Note that unlike the URL suggests the package contains both 32-bit and 64-bit binaries of the make utility). Regards Morous Dne 25.3.2011 3:32, Suresh Govindachar napsal(a): Hello, Inside mingw-w64-1.0-bin_i686-mingw_20110318.zip, I was expecting to find x86_64-w64-mingw32-make.exe but there isn't any such file. What can one use for make? Thanks, --Suresh -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Mingw-users] Conflicting libstdc++-6.dll requirements, and licensing
Hi. Perhaps this could help you: http://msdn.microsoft.com/en-us/library/ms682586%28v=vs.85%29.aspx Maybe your apps use the alternate search path, use SetDllDirectory, specify the DLL in its manifest or some other similar stuff? Also check the app you don't know anything about does not e.g. install some binaries into C:\Windows or other system directory (either in install time, or during runtime) or adds it into registry somewhere (e.g. HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs). Morous Dne 16.3.2011 23:59, Paul Leder napsal(a): On 16/03/2011 20:37, Chris Wilson wrote: In general it's not possible to mix objects compiled with different C++ compilers in the same executable. Usually this is due to the lack of ABI standardisation, resulting in each compiler using a different ABI. That may not be the case here, but the maxim still holds: Compile ALL your objects and libraries with the SAME compiler. Is there a really good reason why you can't compile your app foo with the same compiler that bar uses, i.e. the same version of mingw-w64? They're not in the same executable - they're two completely separate executables; I'm responsible for AppA, but not for AppB. I can't, in general, compile AppB. I may not even know what AppB is, although I do in this case. There's no connection at all between the two, except that they both require libstdc++. I only know about the problem because a subset of users use both executables in the same flow. 1 - AppA is in dirA, together with some version of libstdc++. 2 - AppB is in dirB, together with some other version of libstdc++. 3 - AppA does not work until the version of libstdc++ in *dirB* is removed or renamed. But appA knows *nothing* about AppB or dirB, except that dirB is in the path. 4 - AppB does not work until the version of libstdc++ in *dirA* is removed or renamed. But AppB knows *nothing* about AppA or dirA, except that dirA is in the path. Yes, it's bizarre, but it's trivially reproducible. All I have to do is rename an unrelated libstdc++ to get one or the other of AppA or AppB to work. I've written a simple test case, based on Charles Wilson's code, that does work; it shows that 2 separate trivial apps in 2 separate directories will, in a simple case, work as expected: the required dll is picked up first from the directory that the app is located in, as expected, even if there's another dll of the same name. So, in general, my problem shouldn't exist. I haven't posted this test code, because I'm still trying to work out what's going in my more complex case, in my spare time. I hope to have an answer over the next few days. -Paul -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
