[Mingw-w64-public] mingw64-w64 missing libraries

I am trying to compile a library (SFML if it makes a difference) using mingw64-w64, but am getting many errors about libraries not found (e.g. libopengl32.a). Are these not supposed to be included with mingw? Do I have to set them up separately? -- Programming today is a race between software

[Mingw-w64-public] directory structure / lib placement

I just downloaded ruben's build of gcc 4.7.0 for 32-bit, but I think this question applies to other (all?) other builds, too. I tried compiling a program that links to opengl32, but got a linker error that the file wasn't found. In the old mingw32, libopengl32.a was in the lib folder. In this

Re: [Mingw-w64-public] directory structure / lib placement

experience with CMake so that you may suggest where the problem may be? I know nothing about CMake. Thank you. On Tue, May 1, 2012 at 4:41 PM, Ruben Van Boxem vanboxem.ru...@gmail.comwrote: 2012/5/1 Baruch Burstein bmburst...@gmail.com I just downloaded ruben's build of gcc 4.7.0 for 32-bit

Re: [Mingw-w64-public] directory structure / lib placement

1, 2012 at 4:55 PM, Baruch Burstein bmburst...@gmail.comwrote: I downloaded the latest SFML source from github ( https://github.com/LaurentGomila/SFML) and built the makefile with CMake and default options. I just tried a small example like you suggested and it indeed found no problem. I guess

[Mingw-w64-public] changing defaults

I am using ruben's 4.7 build. 1. How can I add paths to the default search paths for headers/libs so that I don't need to add -I -L to almost every project? 2. How can I set the default mode of g++ to be c++11? -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı

Re: [Mingw-w64-public] Building custom version

On Thu, May 24, 2012 at 2:16 PM, Ruben Van Boxem vanboxem.ru...@gmail.comwrote: 2012/5/24 MARTIN Pierre hicksc...@gmail.com Dear Baruch, Ruben, would you be able to write up a simple tutorial or something, explaining how you do your builds so that we can make a few tweaks and build our

Re: [Mingw-w64-public] Building custom version

On Thu, May 24, 2012 at 4:31 PM, Earnie Boyd ear...@users.sourceforge.netwrote: On Thu, May 24, 2012 at 7:46 AM, Baruch Burstein bmburst...@gmail.com wrote: On the other hand it will be easier to just add a specs file to the /path/to/lib/gcc/TARGET/VERSION/ directory with the changed

Re: [Mingw-w64-public] Building custom version

On Wed, May 30, 2012 at 1:06 PM, Baruch Burstein bmburst...@gmail.comwrote: On Thu, May 24, 2012 at 4:31 PM, Earnie Boyd ear...@users.sourceforge.net wrote: On Thu, May 24, 2012 at 7:46 AM, Baruch Burstein bmburst...@gmail.com wrote: On the other hand it will be easier to just add

[Mingw-w64-public] specs file location

Ruben, I tried using a custom specs file with your Win64 build (I suspect it is the same with other builds) as explained here: http://www.mingw.org/wiki/SpecsFileHOWTO. I placed it at mingw64 dir\lib\gcc\build\version\specs, but it wasn't working. I used Process Monitor to see if the file was even

[Mingw-w64-public] c99

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. Does this apply to mingw-w64 too, or is c99 functionality

[Mingw-w64-public] C++11 threads

Does mingw-w64 support the new c++11 thread header? -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat

[Mingw-w64-public] Placement of additional libraries

Where would I place files for additional libraries I want to always be available for `#include`ing and `-l`inking? For example boots headers and libraries, or zlib.h and libz.a. I am using Ruben's 64-64 compiler setup. -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı

Re: [Mingw-w64-public] Cross-compiling BASH

I know nothing about this, I just wanted to comment that the error: error: 'long long long' is too long for GCC Had me laughing out loud. -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı -- Free Next-Gen Firewall

Re: [Mingw-w64-public] New Rubenvb GCC 4.8 std::thread enabled build

/2 Baruch Burstein bmburst...@gmail.com Can you explain the difference from your regular builds? Does std::thread not work with them? If I use std::thread, do I need to link/distribute any additional libraries? Or are there special licenses issues? In short: Why 2 separate builds? std

Re: [Mingw-w64-public] New Rubenvb GCC 4.8 std::thread enabled build

Thank you all for your clear explanations! On Tue, Apr 2, 2013 at 3:23 PM, JonY jo...@users.sourceforge.net wrote: On 4/2/2013 20:05, Ruben Van Boxem wrote: If you want a static winpthreads but shared libgcc/libstdc++, you'll need to remove libwinpthread.dll.a from your toolchain

Re: [Mingw-w64-public] End of rubenvb builds

I used your builds too. I dont remember why, probably cause it was the first one I found that just worked. I'll give the mingw-builds a try. Thank you for your work. On Sun, Jun 23, 2013 at 6:04 PM, K. Frank kfrank2...@gmail.com wrote: Hello Ruben! OOooohhh NOoO!!! On Sun, Jun

Re: [Mingw-w64-public] End of rubenvb builds

that kind of pushes me away from the whole thing) --- END OF RANT On Sun, Jun 23, 2013 at 8:46 PM, Baruch Burstein bmburst...@gmail.comwrote: I used your builds too. I dont remember why, probably cause it was the first one I found that just worked. I'll give the mingw-builds a try. Thank you

Re: [Mingw-w64-public] End of rubenvb builds

On Sun, Jun 23, 2013 at 10:47 PM, Earnie Boyd ear...@users.sourceforge.netwrote: On Sun, Jun 23, 2013 at 3:07 PM, Alexey Pavlov wrote: 2013/6/23 Baruch Burstein And of course, as expected. I just went to try the mingw-builds, and downloaded their recommended installer (the download

Re: [Mingw-w64-public] _free_locale and _new_locale

I would go with opt 2, since msvcr100 is already very widely available. On Tue, Jun 25, 2013 at 10:03 PM, Ruben Van Boxem vanboxem.ru...@gmail.comwrote: Hi, You've maybe noticed I took up libc++ hacking again. Last time I started adding Windows support, and in order to provide the locale

[Mingw-w64-public] Confusion as to how mingw works

My understanding was always that mingw, as opposed to Cygwin, didn't supply a CRT, but instead used the Windows CRT. I never gave this a second thought until recently, and am now very confused. Static libraries compiled with the VS compiler (I think toolchain is the correct term?) cannot be used

Re: [Mingw-w64-public] Confusion as to how mingw works

On Tue, Jul 9, 2013 at 3:56 PM, JonY jo...@users.sourceforge.net wrote: On 7/9/2013 20:42, Baruch Burstein wrote: Static libraries compiled with the VS compiler (I think toolchain is the correct term?) cannot be used with mingw compiler as far as I know. So when I compile with mingw

Re: [Mingw-w64-public] End of rubenvb builds

On Wed, Jul 10, 2013 at 5:30 PM, Jon jon.for...@gmail.com wrote: ...SNIP... But interpreting or implying or inferring is not useful. Explicit clarification from Kai and JonY as mingw-w64 leaders is needed. I suspect one reason why this hasn't happened is that both already have too much

[Mingw-w64-public] config.guess

The latest version of config.guess, when run on MSYS2 64bit (posted elsewhere on this list) with ruben's 64bit native compilers reports: x86_64-pc-mingw32 I recall somewhere that the correct triplet should be: x86_64-w64-mingw32 The relevant part of config.guess seems to be this:

Re: [Mingw-w64-public] MinGW and Msys Directories

If I understand your answer correctly, MSYS(2) is basically just Windows with POSIX tools, directory layout and paths, but it is still Windows. If so, hen why does it need it's own toolchain, and what are MSYS binaries? Wouldn't a regular Windows toolchain with Windows binaries be the same? On

Re: [Mingw-w64-public] MinGW and Msys Directories

, 2013 at 2:13 PM, Baruch Burstein bmburst...@gmail.com wrote: If I understand your answer correctly, MSYS(2) is basically just Windows with POSIX tools, directory layout and paths, but it is still Windows. If so, hen why does it need it's own toolchain, and what are MSYS binaries? Wouldn't

Re: [Mingw-w64-public] MinGW and Msys Directories

Then how is msys essentially different than cygwin? On Mon, Sep 2, 2013 at 5:25 AM, Alexey Pavlov alex...@gmail.com wrote: msys-2.0.dll is renamed and patched cygwin1.dll. 2013/9/2 Baruch Burstein bmburst...@gmail.com What is this msys-2.0.dll? What functions does it supply? How

Re: [Mingw-w64-public] MinGW and Msys Directories

On Mon, Sep 2, 2013 at 6:44 PM, Ray Donnelly mingw.andr...@gmail.comwrote: Also, I already answered that question. MSYS2 is basically Cygwin without the posix-purity stuff going and instead a laser sharp focus on interoperability between MSYS2 tools and Windows tools. It is still Windows but

Re: [Mingw-w64-public] Which compiler should I use

On Sat, Oct 5, 2013 at 4:52 AM, Jon jon.for...@gmail.com wrote: Heh heh, Incongruous it's your luck day. JonY, gave you all the answers and you didn't even have to dig. Oh well, the Socratic method is overrated and irritating after about two questions ;) I have been trying to piece

[Mingw-w64-public] thread implementation without pthread

I was wondering what the reason was that all implementations of thread and co. mentioned here seem to be by using the GNU implementation over pthreads and adding a pthread implementation over Win32 threads, instead of directly implementing these headers over Win32 threads. This seems like an extra

Re: [Mingw-w64-public] clang on Windows

. 2013/12/23 Baruch Burstein bmburst...@gmail.com I apologize if this is not the right place for this. If so, letme know and I will not post more questions about clang to here. This question is really targeted towards Ruben and others on this list who have built clang toolchains for Windows. I

[Mingw-w64-public] Ruben's Clang builds

I am trying to use Ruben's clang builds (clang 3.2). I unpacked the zip and ran `clang64env.cmd`. When I tried compiling a trivial c program, I get the error: fatal error: 'stdio.h' file not found Anyone (Ruben or other) know what the problem is/how to solve this? P.S. The reason I tried

Re: [Mingw-w64-public] Ruben's Clang builds

On Tue, Jan 14, 2014 at 11:03 AM, Ruben Van Boxem vanboxem.ru...@gmail.comwrote: 2014/1/13 Baruch Burstein bmburst...@gmail.com I am trying to use Ruben's clang builds (clang 3.2). I unpacked the zip and ran `clang64env.cmd`. When I tried compiling a trivial c program, I get the error

Re: [Mingw-w64-public] Ruben's Clang builds

%20Builds/rubenvb/gcc-4.8-release/), but when I ran `clang` I got a crash message that it can't start because libgcc_s_sjlj-1.dll is missing. Ruben? Thanks On Tue, Jan 14, 2014 at 11:38 AM, Baruch Burstein bmburst...@gmail.comwrote: On Tue, Jan 14, 2014 at 11:03 AM, Ruben Van Boxem vanboxem.ru

Re: [Mingw-w64-public] Ruben's Clang builds

On Tue, Jan 14, 2014 at 3:46 PM, Ruben Van Boxem vanboxem.ru...@gmail.comwrote: 2014/1/14 Baruch Burstein bmburst...@gmail.com I am trying to use the Win64 toolchain. I assume I need to unpack the Clang into the same directory as one of your GCC builds? I tried it with the 4.8.0 release

Re: [Mingw-w64-public] Mingw toolchains and Clang

On Wed, Jan 15, 2014 at 7:36 PM, Alexey Pavlov alex...@gmail.com wrote: Long time ago we add possibility to build Clang into mingw-builds scripts. Now we want to provide Clang builds for mingw-w64 toolchains. There are two possibilities that we can do: *1. *Include clang builds into

Re: [Mingw-w64-public] What to Download?

On Mon, Jan 20, 2014 at 2:58 PM, lh_mouse lh_mo...@126.com wrote: MinGW uses MSVCRT.DLL which shipps with Windows XP so there is no additional CRT DLL needed to redistribute. If MinGW64-compiled executables use MSVCRT.DLL as a runtime, then what do they use libgcc.dll for? Isn't it also just

[Mingw-w64-public] What is the default download on sourceforge?

Hi all, On the Sourceforge page for mingw64 ( http://sourceforge.net/projects/mingw-w64/) the is a download button. On Sourceforge, this default download is usually reserved for the most common download, the file(/archive) that most people looking to use this software are going to want. For

Re: [Mingw-w64-public] libwinpthreads dependency should be optional

On Mon, Mar 24, 2014 at 4:32 AM, K. Frank kfrank2...@gmail.com wrote: but it will cut off XP users completely due to how conditional variables are only available in Vista and later. Yes, windows condition variables are not supported in xp, so the above scheme only works for vista and

Re: [Mingw-w64-public] Where is the latest msys(2) download?

Thank you. On Wed, May 7, 2014 at 9:38 PM, Alexpux alex...@gmail.com wrote: 07 мая 2014 г., в 22:31, Baruch Burstein bmburst...@gmail.com написал(а): 32-bit: msys2-base-i686-20140507.tar.xzhttp://sourceforge.net/projects/msys2/files/Base/i686/msys2-base-i686-20140507.tar.xz/download

Re: [Mingw-w64-public] Where is the latest msys(2) download?

What is the difference between msys2_shell, mingw32_shell, mingw64_shell? On Wed, May 7, 2014 at 9:44 PM, Baruch Burstein bmburst...@gmail.comwrote: Thank you. On Wed, May 7, 2014 at 9:38 PM, Alexpux alex...@gmail.com wrote: 07 мая 2014 г., в 22:31, Baruch Burstein bmburst...@gmail.com

Re: [Mingw-w64-public] Where is the latest msys(2) download?

If I am using a separate mingw installation, which shell would I use? On Wed, May 7, 2014 at 9:52 PM, Alexpux alex...@gmail.com wrote: 07 мая 2014 г., в 22:45, Baruch Burstein bmburst...@gmail.com написал(а): What is the difference between msys2_shell, mingw32_shell, mingw64_shell

[Mingw-w64-public] MSYS2 issues

Hi, I (think I) found a bug in msys2. Here is a simple demo case: main.c: int main() { return 42; } Makefile: CC = gcc CC2 = $(shell which $(CC)) out_1: clean main.c $(CC) main.c -o /home/username/out.exe out_2: clean main.c $(CC) /home/username/main.c -o out.exe out_3: clean main.c $(CC)

Re: [Mingw-w64-public] MSYS2 issues

On Tue, Jul 22, 2014 at 3:36 PM, Ray Donnelly mingw.andr...@gmail.com wrote: No, you didn't find any bug in MSYS2. If you want MSYS2 path translation to happen then use an MSYS2 program, i.e. MSYS2 make, not mingw32-make. Oh, OK, sorry. I thought that any program run from within msys got

[Mingw-w64-public] Where are the sources for windres?

I can't seem to find them, and I am getting a very strange bug that I would like to try to track down (as an exercise) -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı --

[Mingw-w64-public] Problem with windres.exe

Hi all, Is this the right place for windres issues? If so, can someone explain to me why windres seems to parse #included .c files differently than #included .h files? Specifically, the line: typedef unsigned long ulong; gets parsed fine (i.e. ignored) if it is in a .h file that is included in

Re: [Mingw-w64-public] Problem with windres.exe

On Mon, Aug 18, 2014 at 5:44 PM, Baruch Burstein bmburst...@gmail.com wrote: Hi all, Is this the right place for windres issues? If so, can someone explain to me why windres seems to parse #included .c files differently than #included .h files? Never mind. I finally found this in the code

Re: [Mingw-w64-public] [Project News | New Builds]

I am curious why only a few of the executables get prefixed versions? I just tried running a certain makefile with prefixed versions of the toolchain, and it failed looking for the prefixed versions of 'ar' and 'windres'. Easily solvable (make a copy and prefix it), but I am still curious why some

Re: [Mingw-w64-public] [Project News | New Builds]

On Mon, Nov 3, 2014 at 2:37 PM, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: 2014-11-03 10:30 GMT+01:00 Baruch Burstein bmburst...@gmail.com: I am curious why only a few of the executables get prefixed versions? I just tried running a certain makefile with prefixed versions

[Mingw-w64-public] msys2

Is this list also the unofficial/official msys2 list, or is there a separate one for that? -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı -- One dashboard for servers and applications across Physical-Virtual-Cloud

Re: [Mingw-w64-public] Patch for ffmpeg

On Thu, Dec 3, 2015 at 12:35 AM, Mateusz wrote: > Sorry for previous patch -- I often link to msvcr120.dll instead of > msvcrt.dll. > I didn't know that was possible. How do you do that and why would you? What is the advantage? -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ