On Thu, 15 Sep 2011 12:33:38 +0200
Ruben Van Boxem wrote:
> Op 15 sep. 2011 12:16 schreef "Andrei Lapshin" het
> volgende:
> >
> > Solved the problem by moving Z:\mingw32 to C:\mingw32.
>
> Wow, that's strange. I always place my mingw* folders at
> m:/development/mingw*. Weird :s
What I notice
> On 9/19/2011 22:38, Jon wrote:
> > I'm working on an app (targeted to run on WinXP_SP2+) having DLLs
> > with runtime dependencies on the particular MinGW-w64
> > `libgcc_s_sjlj-1.dll` and `libstdc++-6.dll` artifacts used to build
> > the app. As such, these specific artifact versions will need t
On Tue, Jan 3, 2012 at 3:18 PM, Jim Michaels wrote:
> http://www.h-online.com/open/news/item/ISO-updates-C-standard-1400814.html
>
> new ISO C standard, C1X, more C++ features, including threads...
>
Jim, can you please put this link in some appropriate spot on the wiki?
Thanks,
--
Earnie
-- h
On Wed, Jan 4, 2012 at 2:57 AM, Peter Meyer wrote:
> History:
> As far as i know. The MinGW64 Project was forked from the MinGW32
> Project because of foolery from the MinGW32 Project Staff. Some Members
> of the MinGW32
> Teams wanted to have a 64-Bit 64-Bit 86_64 Version of the MinGW Project
> b
On Thu, Jan 5, 2012 at 5:09 PM, JonY wrote:
>
> iirc Perl 5.8 for MSYS is out, you could try to persuade the maintainers
> to make it threaded.
>
That would be Chuck Wilson who IIRC monitors this list but discussion
should happen at mingw-us...@lists.sourceforge.net.
--
Earnie
-- https://sites
On Fri, Jan 13, 2012 at 8:07 AM, Erik van Pienbroek
wrote:
> Kai Tietz schreef op do 12-01-2012 om 22:54 [+0100]:
>> 2012/1/12 Kyle :
>> > I'm getting:
>> > trunk/mingw-w64-crt/stdio/mingw_pformat.c:476: undefined reference to
>> > `wcslen'
>>
>> As wcslen is in libmsvcrt.a present, it seems to me
On Tue, Jan 31, 2012 at 9:12 PM, Rafaël Carré wrote:
> Le 2012-01-31 01:57, JonY a écrit :
>> On 1/31/2012 11:07, Rafaël Carré wrote:
>>> ---
>>> mingw-w64-headers/configure.ac | 19 +++
>>> 1 files changed, 11 insertions(+), 8 deletions(-)
>>>
>>
>> What is the benefit of it be
On Wed, Feb 8, 2012 at 4:27 AM, Davidson, Josh wrote:
>
>
> “The procedure entry point vsnprintf could not be located in the dynamic
> link library msvcrt.dll”
>
>
>
> I know this error has been posted to the mailing list before, but I’m
> wondering if there is any way of working around it in bina
On Sat, Feb 11, 2012 at 11:49 AM, Christer Solskogen wrote:
>
> Is it because gcc is braindead that we really need that symlink? I can't
> quite understand why we need it in the first place.
>
No, it is because Windows isn't POSIX. If you desire you can use a
utility called junction.exe to repla
On Thu, Feb 16, 2012 at 6:17 AM, Jim Michaels wrote:
>
> too bad the standard says that the definition in any particular compiler of
> size_t should not be relied upon.
>
C99 defines SIZE_MAX which is (size_t)(-1).
--
Earnie
-- https://sites.google.com/site/earnieboyd
-
hing. Cygwin has 4.2 if I'm not mistaken. MinGW !=
>> MSYS/Cygwin, it's native Win32, without any serious posix support. MinGW-w64
>> fills some gaps, but it's impossible to have decent POSIX support for native
>> Win32.
>
> Earnie Boyd and others started MSYS
On Wed, Feb 22, 2012 at 4:02 AM, Vincent Torri wrote:
> On Tue, Feb 21, 2012 at 5:02 AM, Me Myself and I wrote:
>
>> Can someone here give me the url for the
>> 64 bit equivalent of 32 bit
>>
>> mingw-get-inst-20110530.exe
>>
>> file?
>
> There is no such installer for the mingw-w64 project (at lea
On Fri, Mar 2, 2012 at 4:45 PM, Joshua Boyce
wrote:
>
> On Sat, Mar 3, 2012 at 5:13 AM, Luis Lavena wrote:
>>
>> On Fri, Mar 2, 2012 at 1:09 PM, niXman wrote:
>> >
>> > I didn't upload sources and scripts cause nobody needs them. I didn't
>> > want to hide them =)
>> >
>> > BTW, Why should I dup
On Fri, Mar 2, 2012 at 10:49 PM, Joshua Boyce
> Personally I think it's all a little ridiculous, especially when it comes to
> distributing the source of such massive and ubiquitous applications like
> GCC...
You need to take that up with Richard Stallman. ;-p
--
Earnie
-- https://sites.google.
On Thu, Mar 8, 2012 at 4:26 AM, JonY wrote:
>>> On 3/1/2012 11:06, Kyle wrote:
The only __declspec(dllexport) I can find in fribidi is in lib/common.h:
#if (defined(WIN32)) || (defined(_WIN32_WCE))
# define FRIBIDI_ENTRY __declspec(dllexport)
#endif /* WIN32 */
If dllexport wit
On Tue, Mar 13, 2012 at 4:54 AM, Kai Tietz wrote:
> 2012/3/13 Teemu Nätkinniemi :
>> On 13.3.2012 10:26, Kyle wrote:
>>
>>> I have tried adding -static and -static-libstdc++ to both the LDFLAGS
>>> and CFLAGS for FFmpeg. I have tried adding them to utvideo as well.
>>>
>>> I'm not sure how to forc
On Tue, Mar 13, 2012 at 4:41 AM, Vincent Torri wrote:
> Hey,
>
> I'm trying to get the callstack of programs, so I try to use dbghelp.
> The code is here:
>
> http://codepad.org/wAhYYChY
>
> compilation is fine (see the first line to see how I compile it with
> mingw). I use mingw-w64, Windows XP
On Tue, Mar 13, 2012 at 4:24 PM, Luis Lavena wrote:
> Compiled as:
>
> g++ hello.cc -o hello.exe
>
> Still depends on LIBSTDC++-6.DLL
>
> Adding -static-libstdc++ made it depend on LIBWINPTHREAD-1.DLL
>
It depended on both before.
> Maybe I'm confusing how it is supposed to work?
>
Try -static
On Tue, Mar 13, 2012 at 4:45 PM, Ruben Van Boxem
wrote:
> 2012/3/13 Earnie Boyd
>>
>> On Tue, Mar 13, 2012 at 4:24 PM, Luis Lavena wrote:
>> > Compiled as:
>> >
>> > g++ hello.cc -o hello.exe
>> >
>> > Still depends on LIBSTDC++-
On Tue, Mar 20, 2012 at 4:21 PM, Colin S. Miller
wrote:
> On 20/03/12 10:25, JonY wrote:
> > On 3/20/2012 17:54, postmas...@csmiller.demon.co.uk wrote:
> >> JonY said:
> >>> On 3/20/2012 00:57, mingw...@csmiller.demon.co.uk wrote:
> >>
> >>> I'm trying to build ffmpeg-0.5.5 for MS-Windows 64
On Tue, Mar 20, 2012 at 1:50 PM, Vincent Torri wrote:
> Hey
>
> with latest d-bus release (1.4.18) :
>
> In file included from dbus-sockets-win.h:36:0,
> from dbus-sysdeps-win.c:49:
> c:\mingw_efl\mingw-w64-x86_32\bin\../lib/gcc/i686-w64-mingw32/4.6.2/../../../../i686-w64-mingw32/i
On Tue, Mar 20, 2012 at 5:16 PM, Ruben Van Boxem
wrote:
> 2012/3/20 Earnie Boyd
>>
>> On Tue, Mar 20, 2012 at 1:50 PM, Vincent Torri
>> wrote:
>> > Hey
>> >
>> > with latest d-bus release (1.4.18) :
>> >
>> > In file included fr
On Thu, Mar 22, 2012 at 3:35 PM, Kai Tietz wrote:
>
> Yes, this winsup thing was introduced by mingw.org and cygwin ... It
> is indeed a pain in the ... Therefore in our Wiki there were the
> description for multilib build that said to setup winsup link. I
> checked and this information is lost
On Mon, Mar 26, 2012 at 5:38 PM, Whitequill Riclo
wrote:
>
> On Sun, Mar 25, 2012 at 8:37 PM, NightStrike wrote:
>>
>> On Sun, Mar 25, 2012 at 2:18 PM, JonY wrote:
>> > On 3/26/2012 07:17, Jim Michaels wrote:
>> >> vityan provided a compiler set for 64-bit windows host for ubuntu and
>> >> free
On Wed, Mar 28, 2012 at 8:28 AM, Jim Michaels wrote:
>
> they tabled it for C++11. which I thought wasn't too bright. maybe it was
> someone who used the windows cmd shell and never figured out he could switch
> from raster font to"lucida console".
>
It has nothing to do with C++11, it is about
On Tue, Mar 27, 2012 at 12:25 PM, Whitequill Riclo
wrote:
>
> I'm using 1, to try and build... here:
> http://pastebin.me/c589420d23daa3d5ddbe15e58e03b0ab that is what I've been
> doing.
One thing I've noticed here is that you use sudo for most commands
touching directories in /tools except for:
On Wed, Mar 28, 2012 at 10:06 AM, Ruben Van Boxem
wrote:
> 2012/3/28 Earnie Boyd
>>
>> On Wed, Mar 28, 2012 at 8:28 AM, Jim Michaels wrote:
>> >
>> > they tabled it for C++11. which I thought wasn't too bright. maybe it
>> > was
>> >
On Mon, Apr 2, 2012 at 6:28 AM, Christer Solskogen wrote:
> diff -r 57225b741f27 mingw-w64/mingw-w64-headers/configure
> --- a/mingw-w64/mingw-w64-headers/configure Mon Apr 02 08:55:41 2012
> +0200
> +++ b/mingw-w64/mingw-w64-headers/configure Mon Apr 02 12:28:19 2012
> +0200
Your change s
On Tue, Apr 3, 2012 at 1:59 AM, rajeshwari b wrote:
> Hi all,
> I followed "http://wiki.videolan.org/Win32CompileMSYSNew" and have installed
> Msys 1.0.11 in "E:\Msys", TDM-GCC in "E:\MINGW32_64" (both 32 and 64 bit)
> and Msys-git in "E:\msysgit\msysgit". I want to use autoconf and automake
> for
On Tue, Apr 3, 2012 at 10:53 AM, rajeshwari b
wrote:
> Hi all,
> Sorry, i didn't get it. There is no folder as mentioned i.e., "
> e:/msysgit/msysgit
> /opt/msysgit ". Instead of opt, there is a "libpopt" at
> msysgit/msysgit/src. I am first timer, so pl let it be clear.
You installed MSYS in E:\
On Wed, Apr 4, 2012 at 4:52 AM, rajeshwari b wrote:
> Hi all,
> As directed, have deleted the "msys-1.0.dll" from E:\msysgit\msysgit\bin
> directory.
> Have mounted the directory E:\msys\msys\ as /opt/msysgit
You need to use E:/msysgit/msysgit
Use the / and not the \ in /etc/fstab.
> Have added
On Thu, Apr 12, 2012 at 7:04 AM, niXman wrote:
> I.e. these warnings is reported when building gcc.
>
> ../../../mingw-src/gcc-trunk/gcc/lto-streamer.c:173:5: warning: ISO C
> does not support the 'I64' ms_printf length modifier [-Wformat]
Add -Wno-format after the -pedantic.
--
Earnie
-- https:
On Thu, Apr 12, 2012 at 11:10 AM, niXman wrote:
> 2012/4/12 Earnie Boyd :
>> On Thu, Apr 12, 2012 at 7:04 AM, niXman wrote:
>>> I.e. these warnings is reported when building gcc.
>>>
>>> ../../../mingw-src/gcc-trunk/gcc/lto-streamer.c:173:5: warning: ISO C
>
On Fri, Apr 20, 2012 at 7:49 AM, MARTIN Pierre wrote:
> Dear MinGW-w64 readers,
>
> Is there anyone aware of some kind of wrapper so i could use the MSVC
> compiler with either MSYS or cygwin? By that, i mean that i have bash scripts
> which perform under either linux, macos and windows, and i w
On Wed, May 9, 2012 at 11:58 AM, K. Frank wrote:
> Again, I'm not all that big on backward compatibility, and, as noted
> above, I don't understand what --enable-threads=win32 is for. But
> my gut reaction is if that the gcc implementation (with
> --enable-threads=win32) is sub-optimal, maybe i
On Wed, May 9, 2012 at 12:04 PM, K. Frank wrote:
>
> Personally, as mentioned above, I am quite happy with the winpthreads
> implementation of , as made available in Ruben's build.
>
> Please, let's have mingw-w64 (and mingw) users chime in. Do folks
> prefer one approach (native vs. pthreads) to
On Fri, May 11, 2012 at 2:20 AM, Ruben Van Boxem
wrote:
> Op 11 mei 2012 03:50 schreef "tomdean" het volgende:
>
>
>>
>> On 5/10/2012 6:00 PM, Luis Lavena wrote:
>> > Use gcc -mwindows, by default it will create a console application.
>> > See gcc --target-help
>> I am using 'g++ -I. -lgdi32 -lco
On Thu, May 10, 2012 at 3:57 PM, David Froger wrote:
>> Sure, you are using here within cygwin a native gcc. Of course it
>> doesn't support cygwin's pathname.
>> If you want to use cygwin, then please use the mingw-w64 package
>> provided within cygwin's setup.
>
> Thanks for your reply!
>
> I u
On Tue, May 15, 2012 at 9:02 AM, MARTIN Pierre wrote:
> i have a quick question about this MSYS environment. i primarily
> use it because all my scripts are initially made on an unix system,
> and are also being ran on my Debian machine. i didn't want to go
> through the hassle of making windows b
On Mon, May 14, 2012 at 6:56 PM, Antony Riakiotakis wrote:
> Ah, looks like the reason for the strange behaviour was my using
> release with debug info build type for cmake. Optimizations play funky
> with the debugger it seems. Now all is in order...phew.
>
If you're debugging code you should st
On Tue, May 15, 2012 at 11:39 AM, Kai Tietz wrote:
> Hello Anthony,
>
> those symbols are present in our libmingwex.a library. So I assume
> that there might be a link-order issue.
Or perhaps a link command issue? If you use GCC or G++ to link then
these frontends should add the most common lib
On Wed, May 16, 2012 at 6:44 AM, Joshua Boyce
wrote:
>
> I didn't mean that an additional import library was required, simply that
> the correct import lib needs to be linked in as normal (just like you do
> when using windows.h). For functions exported by kernel32 this
> happens automatically, fo
On Tue, May 15, 2012 at 8:24 PM, Anthony Walter wrote:
> I fixed the problem. It was caused by out of order link lib statements. Link
> order is important sometimes.
s/sometimes/always
--
Earnie
-- https://sites.google.com/site/earnieboyd
---
On Tue, May 22, 2012 at 10:13 AM, Antony Riakiotakis wrote:
> Personally I don't mind using a toolchain with sse3 support
> requirements but we have a policy towards backwards compatibility for
> the program itself going back to 32 bit single core systems. For the
> build systems I am not sure...
On Tue, May 22, 2012 at 9:06 AM, Ruben Van Boxem
wrote:
>
> My new builds (along with the 4.5.3) will be built with
> -march=nocona -mtune=core2
>
Have you considered passing the options directly to the assembler.
You can be specific with your refinements of the extensions added.
--
Earnie
-- h
On Thu, May 24, 2012 at 7:46 AM, Baruch Burstein wrote:
> Specifically, I am looking to change the default mode of g++ to c++11. Where
> would I change that?
Well, you have several options for this. If you're set on building
the code you'll need to find the source for the internal specs file
and
On Thu, May 24, 2012 at 9:31 AM, Earnie Boyd
wrote:
> You can also create a script file
>
>
> #! /path/to/bin/sh
>
> g++ -std=c++11 "$@"
This should be
g++.exe -std=c++11 "$@"
>
>
On Wed, May 30, 2012 at 9:06 AM, xunxun wrote:
> 于 2012/5/30 20:55, Ruben Van Boxem 写道:
>> Hmm... it seems like it's looking in my --prefix or --sysroot
>> directory. The MinGW;org version would only work if you installed it
>> in C:\MinGW or are using MSYS.
>>
>> I unfortunately do not know where
On Tue, Jun 5, 2012 at 12:46 PM, niXman wrote:
> Hello list!
>
> I would like to to understand this problem.
> The fact is that, if MinGW is built on the disc 'D:', and is used on a
> machine that does not have the disk 'D:' - then the windows shows the
> dialog with the error of the access to the
On Tue, Jun 5, 2012 at 10:21 PM, John E. / TDM wrote:
> (2) MSYS' path
> translation can get in the way, or at least has gotten in the way for me in
> the past when building GCC.
When I was maintaining MSYS I wouldn't release it if GCC would not
build. Building the GCC package was my test of san
On Thu, Jun 7, 2012 at 5:08 AM, Baruch Burstein wrote:
> I am trying to compile a program with mingw-w64, but the instructions they
> supply only target "regular" mingw. They say to compile with the `-lmingwex`
> flag. By Googling I found that this is a compatibility layer for c99
> functionality.
On Thu, Jun 7, 2012 at 3:36 AM, Jim Michaels wrote:
> $ tail -1 config.log
> configure: exit 77
You need more than just the tail end of the file. You need to find
the section in config.log that failed. For some reason GCC aborted
when trying to execute a program or aborted during the build of t
On Wed, Jun 6, 2012 at 8:04 PM, John E. / TDM wrote:
> On 6/6/2012 7:18 AM, Earnie Boyd wrote:
>> On Tue, Jun 5, 2012 at 10:21 PM, John E. / TDM wrote:
>>> (2) MSYS' path
>>> translation can get in the way, or at least has gotten in the way for me in
>>>
On Fri, Jun 8, 2012 at 3:52 AM, Jim Michaels wrote:
> it looks to be the fact that *this* gcc expects an argument on -V while the
> one on linux does not (?).
> interesting. there are a LOT of things I would like to compile, but I can't
> because of this bug.
>
> --config.log
>
>
On Sat, Jun 9, 2012 at 4:08 AM, Jim Michaels wrote:
> 2027 auto build 32-bit windows.
> here is my fstab:
> $ cat /etc/fstab
> c:/ /c
> e:/ /e
> c:/prj /prj
> c:/prj/fltk /fltk
> c:/wxWidgets-2.9.3 /wx
> c:/mingw-w32-bin_i686-mingw_2027 /mingw
> c:/mingw-w64-bin_i686-mingw_2027 /mingw6
On Tue, Jun 12, 2012 at 5:11 AM, Jacek Caban wrote:
> On 06/12/12 10:51, Jacek Caban wrote:
>> On 06/12/12 07:06, Yaakov (Cygwin/X) wrote:
>>> On 2012-06-04 04:04, Jacek Caban wrote:
Where? I don't see any. There is one change to propkeydef.h, but and I
believe incorrect. Generally, this
On Tue, Jun 12, 2012 at 6:53 AM, Earnie Boyd wrote:
> We (mingw.org) doesn't support COM and never has. A GCC supported IDL
> compiler would be great but whose going to pick up the support on
> that?
Please excuse my improper English, s/doesn't/do not/
--
Earnie
-- https
On Sun, Jun 17, 2012 at 4:35 AM, Kai Tietz wrote:
> Hi everybody,
>
> here come my 5-cent on that. First libmingw32.a and libmingwex.a are
> two pretty different things.
>
I'll throw in 2 more cents worth. The mingwex was started by
mingw.org and meant to contain code maintained by us that exten
On Wed, Jun 20, 2012 at 7:17 AM, Ozkan Sezer wrote:
>
> If the MSVC *.lib that other project using is 32 bit, no problems with mingw.
> Only 64 bit MSVC *.lib aren't supported.
>
Do you have a pointer to explain why?
--
Earnie
-- https://sites.google.com/site/earnieboyd
---
I do not yet have a 64bit system to try this so please humor me a bit
with this question. When compiling with 64bit version will
__MINGW32__ be defined as well as __MINGW64__?
--
Earnie
-- https://sites.google.com/site/earnieboyd
-
On Fri, Jul 6, 2012 at 1:25 AM, Ozkan Sezer wrote:
> On 7/5/12, Rune K. Svendsen wrote:
>
>> -lwsock32 -lws2_32 -liberty-o streamer-ml-monl-chunkstream-static.exe
>
> You aren't supposed to link to both wsock32 and ws2_32:
> only to one which you are supposed to be using.
And you should be u
On Fri, Jul 6, 2012 at 9:07 AM, Ozkan Sezer wrote:
-lwsock32 -lws2_32 -liberty-o streamer-ml-monl-chunkstream-static.exe
>>>
>>> You aren't supposed to link to both wsock32 and ws2_32:
>>> only to one which you are supposed to be using.
>>
>> And you should be using ws2_32 (WinSOCK version
On Mon, Jul 9, 2012 at 11:52 AM, Zouzou wrote:
> On 09/07/12 17:16, Simson Garfinkel wrote:
>> x86_64-w64-mingw32-g++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
>> -fexceptions --param=ssp-buffer-size=4 -Wno-format --static -static-libgcc
>> -static-libstdc++ -Wall -MD -D_FORTIFY_SOURCE=2 -Wpoi
On Wed, Aug 1, 2012 at 3:51 PM, Ozkan Sezer wrote:
>
>> you look on http://sourceforge.net/projects/mingw-w64/, under the
>> "Mailing Lists" link, there are three lists only, mingw-w64-documentation,
>> mingw-w64-ironcrate and mingw-w64-public. No trace of a developers list.
>>
>
> I think it is v
List,
I've been trying to find a proper use of the genidl tool. If you wish
contact me off list for it. I've seen the documentation but how does
one find proper enabled files?
--
Earnie
-- https://sites.google.com/site/earnieboyd
---
On Fri, Aug 3, 2012 at 2:54 PM, Kai Tietz wrote:
> Hope this helps a bit about this tool,
Yes, thank you.
--
Earnie
-- https://sites.google.com/site/earnieboyd
--
Live Security Virtual Conference
Exclusive live event w
I need some math whiz help. So it seems to me that strtod("NAN",
NULL) should return the same as __builtin_nan(""). And G++ should
return the same result as GCC. For the GCC instance I believe that
the crt/gdtoa/strtodnrp.c code is wrong. For the G++ instance I
believe stdlib.h isn't correct.
On Wed, Aug 8, 2012 at 5:56 AM, Ruben Van Boxem wrote:
> PS: I investigated the implications of the -march=nocona option and it seems
> this is unfortunately also passed to runtime libraries. It is not a general
> cause for concern; only libgfortran contained 3 calls to an SSE3
> instruction, all t
On Wed, Aug 8, 2012 at 11:01 AM, Kai Tietz wrote:
> 2012/8/4 Earnie Boyd :
>> I need some math whiz help. So it seems to me that strtod("NAN",
>> NULL) should return the same as __builtin_nan(""). And G++ should
>> return the same result as GCC. For t
On Wed, Aug 8, 2012 at 1:33 PM, dashesy wrote:
> BTW, this is the line in Wikipedia "64-bit Windows has switched to
> using position-independent code for DLLs as well and has abandoned
> relocation"
> And it references here: http://msdn.microsoft.com/en-us/magazine/bb985017.aspx
For 64 bit binarie
On Wed, Aug 8, 2012 at 1:52 PM, Kai Tietz wrote:
> Found the cause for this. This was caused by dg_qnan.h header ... I
> really should get rid of this gdtoa ...
>
> Revision 5361 fixes this problem.
>
> Thanks for reporting,
The thanks belongs to you for fixing it.
--
Earnie
-- https://sites.go
On Wed, Aug 8, 2012 at 3:29 PM, Earnie Boyd wrote:
> On Wed, Aug 8, 2012 at 1:52 PM, Kai Tietz wrote:
>> Found the cause for this. This was caused by dg_qnan.h header ... I
>> really should get rid of this gdtoa ...
>>
>> Revision 5361 fixes this problem.
>>
On Wed, Aug 8, 2012 at 3:49 PM, Ruben Van Boxem wrote:
>
> Further reduction to (removed unistd.h):
> #define __STDC_FORMAT_MACROS
> #include
> #include
> #include
> #include
> #include
> int main(int argc,char **argv)
> {
>uint64_t val=1234567890;
>printf("%"PRId64"\n",val);
>exit
On Sat, Aug 11, 2012 at 8:20 AM, Martin Mitáš wrote:
>
> Dne 11.8.2012 12:26, Ruben Van Boxem napsal(a):
>> Would you mind conjuring up a small test case (dll .c file, main.c
>> file and compile options)? dllexport/dllimport of normal functions
>> should work (dllexport of C++ classes is WIP). I *s
On Tue, Aug 14, 2012 at 3:59 PM, Greg Dove wrote:
> Hi, a recent starter with mingw64is it right or wrong to patch the
> header files in mingw to get something to compile?
>
> I had to patch winsock2.h with some #defines from winsock.h to get ocaml to
> compile under mingw64. Is that an ocaml p
On Fri, Aug 17, 2012 at 6:12 AM, Jacek Caban wrote:
>
> That's a good question, it seems like MSVC has only one declaration in
> direct.h. I don't know why do we have it duplicated in io.h. IMO we
> should consider removing it from there, leaving only direct.h version.
My guess is that the MS dire
On Fri, Aug 17, 2012 at 4:18 AM, Ruben Van Boxem wrote:
> (I'm not entirely sure what the "c++" executable is
> or does)
It is a symlink or copy of g++. The same is true for gcc and cc.
--
Earnie
-- https://sites.google.com/site/earnieboyd
--
On Fri, Aug 17, 2012 at 9:37 AM, Ozkan Sezer wrote:
>> information, see Windows Runtime Unsupported CRT Functions." How does
>> one know when they are "in the Windows Runtime"? I.E. How can we
>> guard against an application using the CRT functions that are not
>> supported "in the Windows Runti
On Tue, Aug 21, 2012 at 2:35 PM, Greg Peele wrote:
>
> If this is a spurious warning, I can use -Wno-format to suppress it (this
> inline method gets included a LOT of places in my code) but of course that
> loses the ability of using that warning as a legitimate way to warn about
> printf bugs.
>
On Tue, Aug 21, 2012 at 3:11 PM, Greg Peele wrote:
>
>
>> Date: Tue, 21 Aug 2012 14:46:51 -0400
>> From: ear...@users.sourceforge.net
>> To: mingw-w64-public@lists.sourceforge.net
>> Subject: Re: [Mingw-w64-public] printf + long long on GCC 4.7.1
>>
>> On Tue, Aug 21, 2012 at 2:35 PM, Greg Peele wr
On Wed, Aug 29, 2012 at 6:17 PM, JonY wrote:
> On 8/30/2012 05:58, niXman wrote:
>> Hello,
>>
>> Can it be affirmed that mingw-w64 CRT built in 32 bit mode is ABI
>> compatible with CRT from the mingw.org project?
>> In other words, I am interested if there will appear problems when
>> using boost(
On Wed, Sep 12, 2012 at 9:02 AM, Dongsheng Song wrote:
>
> Oh, My automake is 1.11.6, mingw-w64 use 1.12.2. please re-generate
> Makefile.in yourself.
>
My preference is to not store the auto generated files in the
repository and have the configuration set to ignore the generated
files so the gene
On Thu, Sep 13, 2012 at 12:46 PM, CanisMajorWuff wrote:
> strip -x lib/libglew32.a
> make: *** [lib/libglew32.a] Error 5
Permission denied.
>
> And a window with text "strip.exe has stoped working". Does somebody know
> what can be wrong?
>
I'm guessing antivirus software or other BLODA.
http:/
On Thu, Sep 13, 2012 at 1:36 PM, CanisMajorWuff wrote:
> I don't know what is BLODA, and I did not understand from the description
> how it could influence to stip work. But I removed the cygwin binaries from
> path. I did not give any effect.
BLODA doesn't affect just Cygwin, the Big List Of Dodg
On Thu, Sep 13, 2012 at 2:34 PM, CanisMajorWuff
wrote:
> I don't any antivirus software on my Windows Home Premium.
> If some Windows component scans newly created files, then I tried this
> command 'strip -x lib/glew32.dll' by myself in several minutes after
> creation.
>
Does something have the
On Sun, Sep 16, 2012 at 3:04 PM, CanisMajorWuff wrote:
> Hi,
>
> My antivirus (Dr.Web) tells me that fgrep.exe in MSYS package is a
> trojan ( Trojan.Packed.140). Are you aware of this issue?
Either Dr. Web has a false positive or you have infected the file
locally. File a support issue with Dr.
On Fri, Sep 28, 2012 at 11:17 AM, Ruben Van Boxem wrote:
>
> That's interesting. I'll check out mingw-builds' patches.
>
--8<--
>
> True, but at least all CMake generated Makefiles work great as well. Maybe
> you could push for better MinGW support in jom ;-).
>
> I'll try to get a complete CVS GNU
Please forgive my laziness as not having enough time yet to download
and format an environment with 4.8 GCC as yet. Is there a predefined
macro to indicate when I have SEH support?
--
Earnie
-- https://sites.google.com/site/earnieboyd
On Thu, Oct 11, 2012 at 11:51 PM, Dongsheng Song wrote:
> Hi,
>
> What's the difference between pe and pei ?
>
> I see:
>
> ld: supported targets: pe-i386 pei-i386 pe-x86-64 pei-x86-64 ...
> ld: supported emulations: i386pe i386pep
>
> When I use 'gcc.exe -m32 example.c', which target file format g
On Tue, Oct 16, 2012 at 5:24 AM, Ruben Van Boxem wrote:
> __MINGW64__ only really signifies x64 Windows and MinGW. I bet that if
> MinGW.org ever come with a 64-bit variant (not likely), they'd define this
> for consistency (just as MinGW-w64 does).
Since it is defined by the compiler, of course a
On Fri, Oct 19, 2012 at 3:19 PM, Roger Pack wrote:
>>> Who is defining const as an empty macro? That doesn't seem right.
>>
>>
>> C++ only makes it undefined behavior, and the rules are fuzzy at best (seems
>> that it's only undefined behavior when the translation unit includes a
>> standard header
On Thu, Oct 25, 2012 at 9:07 PM, JonY wrote:
> Microsoft DLLs when possible, eg msvcrt.dll, though it is not possible
> unless you stick strictly to C. Like Kai says, C++ support comes from
> GCC libstdc++, fortran support from libgfortran etc. You should have no
> legal problems distributing these
On Fri, Oct 26, 2012 at 8:05 AM, Ruben Van Boxem
wrote:
> 2012/10/26 Earnie Boyd
>>
>> On Thu, Oct 25, 2012 at 9:07 PM, JonY wrote:
>> > Microsoft DLLs when possible, eg msvcrt.dll, though it is not possible
>> > unless you stick strictly to C. Like Kai says
On Fri, Oct 26, 2012 at 9:04 AM, Ruben Van Boxem
wrote:
>
> And that Section 6 clearly states you can point to e.g. the GCC website for
> the source code:
> http://www.gnu.org/licenses/gpl-faq.html#SourceAndBinaryOnDifferentSites
>
> So absolutely no end-developer hassle in providing toolchain sou
On Fri, Oct 26, 2012 at 11:39 AM, Ruben Van Boxem
wrote:
>
> I also don't think a static runtime link changes any of this, TDM. >From the
> same FAQ as before:
> "neither the GPL nor the GCC Runtime Library Exception distinguish between
> static linking, dynamic linking, and other methods for comb
On Fri, Oct 26, 2012 at 11:54 AM, Ray Donnelly wrote:
> On Fri, Oct 26, 2012 at 4:38 PM, Corinna Vinschen wrote:
>> On Oct 26 16:10, Ray Donnelly wrote:
>>> I've never seen any precedent of anyone ever doing this anywhere.
>>>
>>> Are you saying we are all in violation here? If so, 'we' includes a
On Fri, Oct 26, 2012 at 12:27 PM, Ruben Van Boxem
wrote:
>
> Also, can someone clarify that you only need to be able to provider the
> source when asked for it vs providing it in some public place, which might
> not even be reachable everywhere in the world?
AIUI, at least for v2 of the license,
On Thu, Nov 1, 2012 at 10:38 AM, Ruben Van Boxem
wrote:
> Dear list,
>
> Using MinGW-w64 v2.0.7 and my 4.7.2 toolchain, I get a build failure in LLVM
> related to strerror_s.
> It performs a CMake check to see if the function is declared, and finds it
> (I configured the headers with --enable-secu
On Thu, Nov 1, 2012 at 11:02 AM, Ruben Van Boxem wrote:
>
> The first I don't know, the second is obviously yes; the compiler takes care
> of that.
Compilers are programs that can contain bugs.
> I don't think declarations are influences by extern "C" though.
Yes it matters. The name mangling i
On Thu, Nov 1, 2012 at 11:27 AM, Ruben Van Boxem wrote:
> I get a compile-time error.
Browsing the SVN data, try including strings.h instead of string.h.
See
http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/mingw-w64-headers/crt/string.h?revision=1520&view=markup&sortby=rev&pathrev=509
1 - 100 of 169 matches
Mail list logo
