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ıɥʇ pɐǝɹ uɐɔ noʎ ɟı
---
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
On Mon, Nov 3, 2014 at 2:37 PM, Ruben Van Boxem
wrote:
> 2014-11-03 10:30 GMT+01:00 Baruch Burstein :
>
>> 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 i
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
On Mon, Aug 18, 2014 at 5:44 PM, Baruch Burstein
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 c
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
t
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ʎ ɟı
--
_
On Tue, Jul 22, 2014 at 3:36 PM, Ray Donnelly
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
automatic path transl
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) main.c
If I am using a separate mingw installation, which shell would I use?
On Wed, May 7, 2014 at 9:52 PM, Alexpux wrote:
>
> 07 мая 2014 г., в 22:45, Baruch Burstein
> написал(а):
>
> What is the difference between msys2_shell, mingw32_shell, mingw64_shell?
>
>
>
What is the difference between msys2_shell, mingw32_shell, mingw64_shell?
On Wed, May 7, 2014 at 9:44 PM, Baruch Burstein wrote:
> Thank you.
>
>
> On Wed, May 7, 2014 at 9:38 PM, Alexpux wrote:
>
>>
>> 07 мая 2014 г., в 22:31, Baruch Burstein
>> написал(а)
Thank you.
On Wed, May 7, 2014 at 9:38 PM, Alexpux wrote:
>
> 07 мая 2014 г., в 22:31, Baruch Burstein
> написал(а):
>
> 32-bit:
> msys2-base-i686-20140507.tar.xz<http://sourceforge.net/projects/msys2/files/Base/i686/msys2-base-i686-20140507.tar.xz/download>
>
--
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software
On Mon, Mar 24, 2014 at 4:32 AM, K. Frank 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 later.
>
A little
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 ming
On Mon, Jan 20, 2014 at 2:58 PM, lh_mouse 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 a c runtime li
On Wed, Jan 15, 2014 at 7:36 PM, Alexey Pavlov 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 toolchain archive
> *
On Tue, Jan 14, 2014 at 3:46 PM, Ruben Van Boxem
wrote:
> 2014/1/14 Baruch Burstein
>
>> 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 (regular, not
%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 wrote:
>
> On Tue, Jan 14, 2014 at 11:03 AM, Ruben Van Boxem <
> vanboxe
On Tue, Jan 14, 2014 at 11:03 AM, Ruben Van Boxem
wrote:
> 2014/1/13 Baruch Burstein
>
>> 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:
>>
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 using
And if I compile it with MinGW then it uses MinGW's toolchain, no? Does
Clang not have it's own toolchain (specifically linker)?
On Mon, Dec 23, 2013 at 9:45 PM, Ivan Garramona
wrote:
> You have to compile Clang with MinGW, otherwise Clang will use VS's
> toolchain.
&g
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 just tried building clang myself
(nothing fancy, just
I was wondering what the reason was that all implementations of
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 level
On Sat, Oct 5, 2013 at 4:52 AM, Jon 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 together this type of
On Mon, Sep 2, 2013 at 6:44 PM, Ray Donnelly wrote:
> 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 it uses it's ow
Then how is msys essentially different than cygwin?
On Mon, Sep 2, 2013 at 5:25 AM, Alexey Pavlov wrote:
> msys-2.0.dll is renamed and patched cygwin1.dll.
>
>
> 2013/9/2 Baruch Burstein
>
>> What is this msys-2.0.dll? What functions does it supply? How is this
>&
the same.
>
> On Sun, Sep 1, 2013 at 2:13 PM, Baruch Burstein
> 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 i
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?
O
On Wed, Jul 31, 2013 at 10:47 PM, Kai Tietz wrote:
> 2013/7/31 Baruch Burstein :
> > On Wed, Jul 31, 2013 at 9:49 PM, Kai Tietz
> wrote:
> >>
> >> 2013/7/31 Earnie Boyd :
> >> > On Wed, Jul 31, 2013 at 8:21 AM, Kai Tietz wrote:
> >> >>
On Wed, Jul 31, 2013 at 9:49 PM, Kai Tietz wrote:
> 2013/7/31 Earnie Boyd :
> > On Wed, Jul 31, 2013 at 8:21 AM, Kai Tietz wrote:
> >>
> >> As there never was, and won't be in next future a target with ending
> >> ...mingw64 in triplet.
> >>
> >
> > That statement maybe here but not at MinGW.org.
Shouldn't it be updated to change x86_64-*pc*-mingw* to x86_64-*w64*-mingw*?
On Wed, Jul 31, 2013 at 3:39 PM, JonY wrote:
> On 7/31/2013 19:56, Earnie Boyd wrote:
> > On Wed, Jul 31, 2013 at 5:52 AM, JonY wrote:
> >> On 7/31/2013 17:21, Baruch Burstein wrote:
>
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:
*:MINGW6
On Wed, Jul 10, 2013 at 5:30 PM, Jon 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 on their
On Tue, Jul 9, 2013 at 3:56 PM, JonY 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 compi
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 w
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
wrote:
> 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 related things, I us
On Sun, Jun 23, 2013 at 10:47 PM, Earnie Boyd
wrote:
> 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 install
nd not
getting it to work that kind of pushes me away from the whole thing)
--- END OF RANT
On Sun, Jun 23, 2013 at 8:46 PM, Baruch Burstein wrote:
> 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-bui
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 wrote:
> Hello Ruben!
>
> OOooohhh NOoO!!!
>
> On Sun, Jun 23, 2013 at 9:15
On Thu, Jun 20, 2013 at 10:26 PM, Ruben Van Boxem
wrote:
> 2013/6/20 koala01
>
>> Hello,
>> First, i would like to special thanks to ruben for its effort to provide
>> the correct C++11 thread support.
>>
>> His x86_64-w64-mingw32-gcc-4.8-stdthread-win64_rubenvb personnal build
>> has me helped a
A "check/uncheck all" for each section would be useful.
On Mon, May 20, 2013 at 4:37 PM, Erik van Pienbroek wrote:
> Adrien Nader schreef op ma 20-05-2013 om 11:17 [+0200]:
> > As you can see on the page, besides the layout which isn't perfect, the
> > toolchain descriptions are completely wrong
Thank you all for your clear explanations!
On Tue, Apr 2, 2013 at 3:23 PM, JonY 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 directory. Your mileage
> > may
for
every compilation? Does just using a static CRT give me a static
winpthreads, too, or are they separate?
Would having one build with winpthreads bundled into the libstdc++.dll (or
whatever it is) not work?
On Tue, Apr 2, 2013 at 12:38 PM, Ruben Van Boxem
wrote:
> 2013/4/2 Baruch Burstein
&g
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?
On Tue, Mar 26, 2013 at 9:02 PM, Ruben Van Boxem
wrot
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 H
I am not using MSYS.
On Thu, Nov 22, 2012 at 12:56 AM, deneme.true wrote:
> Hello,
>
> Baruch,
>
> I am using similar to this configuration at indicated this article:
> http://ingar.satgnu.net/devenv/mingw32/base.html
>
> I can easily change Mingw32 to Ming64 with:
> for Mingw32:
> source /local
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ʎ ɟı
--
Does mingw-w64 support the new c++11 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 landscape h
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 built
On Wed, May 30, 2012 at 3:55 PM, Ruben Van Boxem
wrote:
> 2012/5/30 Baruch Burstein
>
>> 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.
On Wed, May 30, 2012 at 3:02 PM, Baruch Burstein wrote:
>
> On Wed, May 30, 2012 at 1:06 PM, Baruch Burstein wrote:
>
>>
>> On Thu, May 24, 2012 at 4:31 PM, Earnie Boyd <
>> ear...@users.sourceforge.net> wrote:
>>
>>> On Thu, May 24, 2012 at 7:46
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 \lib\gcc\\\specs, but it wasn't working. I used Process
Monitor to see if the file was even being read, and found t
On Wed, May 30, 2012 at 1:06 PM, Baruch Burstein wrote:
>
> On Thu, May 24, 2012 at 4:31 PM, Earnie Boyd > wrote:
>
>> On Thu, May 24, 2012 at 7:46 AM, Baruch Burstein
>> wrote:
>>
>
>
>> On the other hand it will be easier to just add a specs file
On Thu, May 24, 2012 at 4:31 PM, Earnie Boyd
wrote:
> On Thu, May 24, 2012 at 7:46 AM, Baruch Burstein
> 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 values.
> You can get a sp
On Thu, May 24, 2012 at 2:16 PM, Ruben Van Boxem
wrote:
> 2012/5/24 MARTIN Pierre
>
>> 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 own?
>> Or maybe someone else? I se
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 own?
Or maybe someone else? I seem to remember running into trouble when trying
to use the bundled compilation instructions (but that was a while ago
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ʎ ɟı
---
, May 1, 2012 at 6:50 PM, Ruben Van Boxem wrote:
> 2012/5/1 Baruch Burstein
>
>> I found the problem. It is indeed an SFML CMake script that assumes that
>> libraries are at \lib and has this hard-coded at one point when
>> building static libraries (it calls `ar x
at 4:55 PM, Baruch Burstein wrote:
> 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 the problem
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 wrote:
> 2012/5/1 Baruch Burstein
>
>> I just downloaded ruben's build of gcc 4.7.0 for 32-bit, but I think this
>&
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 bu
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 eng
63 matches
Mail list logo
