Prasanna V. Loganathar | 29 May 06:39 2015

Preferred build system, installation methods and download page links.

Hi,

I had been using the builds as a part of MSYS2 for a while now, and I believe this is the most robust and easiest way to install mingw-w64. Also, due to the inherent nature of the system, it also provides the most up-to-date builds on par with the Linux builds.

The build I see on winbuilds is actually older than the one on MSYS2. I’m just wondering if it would be in the best interests of the entire community that MSYS2 be promoted as the preferred build from the website instead of winbuilds. While win-builds seem to provide a GUI and switchable toolchain, MSYS2 just feels a lot more robust with, especially pacman. Pacman integration at its crux, seems to be the most brilliant package management strategy for windows, so far.  

 

By the looks of the websites, I believe I can assume that the maintainers of winbuilds and mingw-w64 are the same or perhaps at the least linked. But I would very much like to think that it would be better to focus the efforts on one if so, and perhaps may be even implement winbuilds over msys2’s excellent convergence work. But until then, I think it may make a lot more sense to converge with MSYS2 for official sources, rather than use the winbuilds system. Windows GCC (MinGW) builds of libraries have historically been a pain, because of the numerous different possible configuration the default build could have had, and due to the nature of the various sources, and none to be so-called “official” (or at-least a de-facto standard). Having winbuilds, and MSYS2 could again promote such problems, while converging them could very easily become the de-facto standard.

 

I’d like to hear what the maintainers’ thought are on these.

 

Regards,

Prasanna V. Loganathar

------------------------------------------------------------------------------
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@...
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Etienne Sandré-Chardonnal | 28 May 18:33 2015

Re: Multiple definition issue with -flto, MinGW-w64 4.9.1

Hi,

This worked, the program compiles fine now.

It crashes with a SegFault shortly after starting a new thread (via QThread), with a message:
RTTI symbol not found for class 'SimClientPrivate'

Are there incompatibilities of flto and cases where it cannot work?


Thanks
 
FWIW, you can try moving virtual function definitions out of header files, as defining virtual functions inside headers is generally a bad idea. (The story is much longer than that. Since the RTTI data of a polymorphic class is linked/exported/whatever with one of its virtual functions, specific mechanisms that rely on RTTI - dynamic_cast, exceptions, etc - might fail if RTTI of the same class is used across dynami clibrary boundaries.)
------------------------------------------------------------------------------
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@...
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
İsmail Dönmez | 25 May 18:47 2015

[PATCH] Add some missing IMAGE_DLLCHARACTERISTICS_* constants

Hi,
 .
Noticed while trying to compile the application from
http://blogs.msdn.com/b/oldnewthing/archive/2015/05/18/10615339.aspx .

Patch attached.

Thanks,
ismail
Attachment (dll_character.patch): application/octet-stream, 2873 bytes
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@...
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Pavel Fedin | 24 May 14:19 2015

Contributing a package

 Hello!

 I am currently building libvirt (http://libvirt.org/) for 64-bit Windows. The ultimate
goal is to get virt-manager (https://virt-manager.org/) running.
 Building libvirt requires Sun (now ONC) RPC headers and RPC code generator. Since MinGW
doesn't have them i decided to use portablexdr
(http://people.redhat.com/~rjones/portablexdr/). Actually this is what Redhat does, they
cross-build Windows version of libvirt on Linux machine.
 portablexdr package as it is currently have some bugs, i had to fix them in order to be
able to use it. I tried to post them back to Redhat, but Richard replied that support for
portablexdr was stopped because Oracle relicensed original RPC code. So they don't accept
patches and don't plan to develop it furtner.
 However, looks like it's the simplest way to go on Windows, because we anyway don't have
any RPC code ported. And i guess porting TI-RPC is more complex task. So i would like to
take over portablexdr and contribute the package to MinGW64. The question is - how can i
do it ? What do i need in order to be able to upload it ? Also it would be nice to be able
to host a repository on MinGW64 sourceforge page, because Richard told me that they don't
give away maintainership of their code repositories, and if i want to go on with
portablexdr (which is perfectly OK by itself), i'll have to set up my own repository.
 Could anybody help me with that ? I believe setting up a separate project on sf.net would
be too much for that.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
asmwarrior | 23 May 03:39 2015
Picon

can anyone supply a debug version of cc1plus.exe?

I just want to hunt the GCC bug: (big pch file will crash cc1plus.exe)
56926 – Crash (without ICE) while compiling Boost.Math - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926

It turns out that build the GCC and G++ myself is too complex for me, so I would like to see if someone can supply
a debug version of tool chain, so that I can run them under gdb to see where it crashed.

BTW: I see that the latest LD can have separate debug file generated, so maybe, we can use it.

Thanks.

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Jacek Caban | 22 May 16:28 2015

[PATCH] Install *.c files as headers as well.

I lately added msinkaut_i.c to includes (like MS does), but it's not
installed by build system. The attached patch fixed that.

---
 mingw-w64-headers/Makefile.am  | 1 +
 mingw-w64-headers/configure.ac | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@...
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Etienne Sandré-Chardonnal | 21 May 08:55 2015

Multiple definition issue with -flto, MinGW-w64 4.9.1

Dear all,

I tested -flto on a pretty large program today, and it fails with a multiple definition error:

./release\scenehandler.o (symbol from plugin):(.gnu.linkonce.t._ZN12BufferStreamD0Ev[_ZThn16_N12BufferStreamD0Ev]+0x0): multiple definition of `BufferStream::~BufferStream()'

./release\consolehandler.o (symbol from plugin):(.gnu.linkonce.t._ZN12BufferStreamD0Ev[_ZTv0_n24_N12BufferStreamD0Ev]+0x0): first defined here

./release\scenehandler.o (symbol from plugin):(.gnu.linkonce.t._ZN12BufferStreamD0Ev[_ZThn16_N12BufferStreamD0Ev]+0x0): multiple definition of `non-virtual thunk to BufferStream::~BufferStream()'

./release\consolehandler.o (symbol from plugin):(.gnu.linkonce.t._ZN12BufferStreamD0Ev[_ZTv0_n24_N12BufferStreamD0Ev]+0x0): first defined here

./release\scenehandler.o (symbol from plugin):(.gnu.linkonce.t._ZN12BufferStreamD0Ev[_ZThn16_N12BufferStreamD0Ev]+0x0): multiple definition of `virtual thunk to BufferStream::~BufferStream()'

./release\consolehandler.o (symbol from plugin):(.gnu.linkonce.t._ZN12BufferStreamD0Ev[_ZTv0_n24_N12BufferStreamD0Ev]+0x0): first defined here

./release\bufferstream.o (symbol from plugin):(.gnu.linkonce.t._ZN12BufferStreamD1Ev[_ZTv0_n24_N12BufferStreamD1Ev]+0x0): multiple definition of `BufferStream::~BufferStream()'

./release\consolehandler.o (symbol from plugin):(.gnu.linkonce.t._ZN12BufferStreamD1Ev[_ZThn16_N12BufferStreamD1Ev]+0x0): first defined here

./release\bufferstream.o (symbol from plugin):(.gnu.linkonce.t._ZN12BufferStreamD1Ev[_ZTv0_n24_N12BufferStreamD1Ev]+0x0): multiple definition of `virtual thunk to BufferStream::~BufferStream()'

./release\consolehandler.o (symbol from plugin):(.gnu.linkonce.t._ZN12BufferStreamD1Ev[_ZThn16_N12BufferStreamD1Ev]+0x0): first defined here

./release\bufferstream.o (symbol from plugin):(.gnu.linkonce.t._ZN12BufferStreamD1Ev[_ZTv0_n24_N12BufferStreamD1Ev]+0x0): multiple definition of `non-virtual thunk to BufferStream::~BufferStream()'

./release\consolehandler.o (symbol from plugin):(.gnu.linkonce.t._ZN12BufferStreamD1Ev[_ZThn16_N12BufferStreamD1Ev]+0x0): first defined here



I have found this bug, but it was not followed-up since 2013 and gcc 4.6/4.7

Is this a bug or a problem in my code? The class BufferStream is defined only once in a header file, and uses a default destructor. It is detailed below.

Thanks,

Etienne

class BufferStream : public std::iostream
{
public:
BufferStream();

std::streampos size() const { return streamBuf.size(); }
const char * data() const { return streamBuf.data(); }
std::vector<char> getBufferAndClear() { return streamBuf.getBufferAndClear(); }


private:
class StreamBuf : public std::streambuf
{
public:
explicit StreamBuf();
~StreamBuf() { }

int overflow(int c = EOF);
std::streampos size() const { return pptr()-pbase(); }
const char * data() const { return pbase(); }

std::vector<char> getBufferAndClear();

private:
std::vector<char> buffer;
};

StreamBuf streamBuf;
};

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@...
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Ruben Van Boxem | 19 May 10:21 2015
Picon

Re: "Universal CRT" and Python support

Now without zip...

015-05-19 10:17 GMT+02:00 Ruben Van Boxem <vanboxem.ruben <at> gmail.com>:
2015-05-19 10:03 GMT+02:00 LRN <lrn1986-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
On 19.05.2015 10:09, Ruben Van Boxem wrote:
> Hi guys,
>
> There has recently (as in, yesterday) been a new flicker of activity in the
> mingw-python camp.
> For a long time, GCC on Windows was not a usable option for Python without
> some pretty big workarounds and hacks to get everything working. The
> biggest issue being that you cannot simply build Python extensions with
> MinGW(-w64). For that issue, and the flicker of activity, see this bug
> report:
> http://bugs.python.org/issue4709
>
> Now, it seems that VS2015 is coming with a new "Universal CRT", which will
> be what the new Python version supports. Paule Moore, a new Python
> contributor, is prepared to help significantly as I understand it, but he
> deems support for the new CRT somewhat of a requirement to get streamlined
> support for the GCC/Windows/Python combination. What are the chances of
> this being added to MinGW-w64 "soon"?

IANAL, but UCRT might also improve the licensing situation, where GPLv2
programs can't legally link to anything other than msvcrt.dll that comes
with the OS; if UCRT is, legally, an OS component (and from the way MS
describes it, that seems to be the case), GPLv3 (and, hopefully, GPLv2)
programs will be able to use it. That could serve as an extra motivation
for UCRT support in MinGW-w64.

Yes, that seems to be indeed the case, plus it will be available on older OS versions through Windows update:
http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx

It would be awesome to be able to "update" the CRT underlying MinGW-w64. As a start, attached are the def files for the current Windows 10 ucrtbase DLLs (along with msvcrt, because why not) generated by gendef.

I think it's time to create a new GCC target maybe... How about "{i686,x86_64}-pc-windows", and it links to the ucrtbase libraries, which will be unversioned, serviced in place (much like glibc, as I understand it). Maybe we can use native threading primitives in one go for C++11 for the new target!

/ImustbeonsomethingI'llgotakeawalknow

Cheers,

Ruben
 

--
O< ascii ribbon - stop html email! - www.asciiribbon.org

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



Attachment (x64_msvcrt.def): application/octet-stream, 26 KiB
Attachment (x64_ucrtbase.def): application/octet-stream, 34 KiB
Attachment (x86_msvcrt.def): application/octet-stream, 31 KiB
Attachment (x86_ucrtbase.def): application/octet-stream, 37 KiB
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@...
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Ruben Van Boxem | 19 May 09:09 2015
Picon

"Universal CRT" and Python support

Hi guys,

There has recently (as in, yesterday) been a new flicker of activity in the mingw-python camp.
For a long time, GCC on Windows was not a usable option for Python without some pretty big workarounds and hacks to get everything working. The biggest issue being that you cannot simply build Python extensions with MinGW(-w64). For that issue, and the flicker of activity, see this bug report:
http://bugs.python.org/issue4709

Now, it seems that VS2015 is coming with a new "Universal CRT", which will be what the new Python version supports. Paule Moore, a new Python contributor, is prepared to help significantly as I understand it, but he deems support for the new CRT somewhat of a requirement to get streamlined support for the GCC/Windows/Python combination. What are the chances of this being added to MinGW-w64 "soon"? I'll be sure to point him to the python patches located here which can be used as a starting point:
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python3
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python2

Additionally, there seem to be some misconceptions as to the number of different toolchains available, I'll offer to straighten that out with him, and point him to the official builds we offer here. As to that, is there any (significant/important) difference between the MSYS2 builds and the official installer builds?

Cheers,

Ruben
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@...
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
James Franco | 19 May 00:21 2015
Picon

Building DirectShow - Is it possible ?

Has anyone had success building the binaries of DirectShow with Mingw 64 bit ? 
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@...
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
James Franco | 18 May 22:25 2015
Picon

where to get libstrmbase - DirectShow

I wanted to know if anyone has had success in building strmbase library. I know it has something to do with Directshow. However I am not sure where to get the strmbase library . I am porting a project from Visual Studio to mingw64 bit that uses MS DirectX SDK 2008. 

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@...
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Gmane