from:"Baruch Burstein"

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

2015-12-27 Thread Baruch Burstein

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ʎ ɟı
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] msys2

2015-05-05 Thread Baruch Burstein

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 
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

2014-11-03 Thread 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 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 get it by default while others don't?

On Sun, Nov 2, 2014 at 10:42 AM, niXman i.nix...@autistici.org wrote:


 *ANNOUNCING* GCC-4.9.2 builds are released.

 Program *versions* in builds:

 1. *GCC-4.9.2*
 2. *binutils-2.24*
 3. *mingw-w64 v3 git c6f0d3d981c70ad31bb1c2bfc2850b827281e189*
 4. *gdb-7.8.1*
 5. *python-2.7.8(with dev-files)*
 6. *make-4.1*


 Links:
 32-bit:
posix-sjlj:

 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.2/threads-posix/sjlj/i686-4.9.2-release-posix-sjlj-rt_v3-rev0.7z
posix-dwarf:

 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.2/threads-posix/dwarf/i686-4.9.2-release-posix-dwarf-rt_v3-rev0.7z
win32-sjlj:

 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.2/threads-win32/sjlj/i686-4.9.2-release-win32-sjlj-rt_v3-rev0.7z
win32-dwarf:

 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.2/threads-win32/dwarf/i686-4.9.2-release-win32-dwarf-rt_v3-rev0.7z

 64-bit:
posix-sjlj:

 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.2/threads-posix/sjlj/x86_64-4.9.2-release-posix-sjlj-rt_v3-rev0.7z
posix-seh:

 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.2/threads-posix/seh/x86_64-4.9.2-release-posix-seh-rt_v3-rev0.7z
win32-sjlj:

 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.2/threads-win32/sjlj/x86_64-4.9.2-release-win32-sjlj-rt_v3-rev0.7z
win32-seh:

 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.2/threads-win32/seh/x86_64-4.9.2-release-win32-seh-rt_v3-rev0.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


 --
 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
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public




-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
--
___
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]

2014-11-03 Thread Baruch Burstein

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 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 get it by default while others don't?


 Because this is a native toolchain. Native toolchains don't have
 everything prefixed. Your makefile shouldn't be using any prefixes, and
 just call the bare gcc etc. instead.


a. Then why are some prefixed?
b. Is there another way to determine in the makefile if compiling for x64
or x32 without using the compiler executable name?


-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

2014-08-18 Thread Baruch Burstein

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
the .rc file, but fails the parser if it is in a .c file that is included
in the .rc file.

Thank you,
Baruch

-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

2014-08-18 Thread Baruch Burstein

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. Apparently it is by design,
with the lexer going out of it's way to ignore any code in .h files. I
guess the windres developers don't expect other forms of source code files
to be #included in .rc files, which is probably a fine assumption 99% of
the time, so it is unlikely to be changed.

-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

2014-08-17 Thread Baruch Burstein

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 mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] MSYS2 issues

2014-07-22 Thread Baruch Burstein

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 -o out.exe
out_4: clean main.c
$(CC2) main.c -o /home/username/out.exe
out_5: clean main.c
$(CC2) main.c -o out.exe
clean:
rm -f out.exe

All 5 targets in the makefile should do the same thing, right?

If I try to run target #1, I get:
C:/Users/username/progs/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.1/../../../../x86_64-w64-mingw32/bin/ld.exe:
cannot open output file /home/username/out.exe: No such file or directory

For #2 I get:
gcc: error: /home/username/main.c: No such file or directory

The other 3 work correctly.

If I run the command in #1 or #2 manually from the msys bash prompt, it
works fine. It only fails using the makefile.
When checking with Process Monitor, I found that in the first 2 cases, it
was trying to access the folder at C:\home\username\ , or in other words -
it was not translating the msys path to the real windows path.

I am using:
msys2-base-x86_64-20140704
x86_64-4.9.1-release-posix-seh-rt_v3-rev0

The make I am using is the mingw32-make included with the compiler version
above.

-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds___
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 issues

2014-07-22 Thread Baruch Burstein

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
automatic path translation. Is there a difference between the 2 makes other
than this?

-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds___
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 is the latest msys(2) download?

2014-05-07 Thread Baruch Burstein

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

 64-bit:
 msys2-base-x86_64-20140507.tar.xzhttp://sourceforge.net/projects/msys2/files/Base/x86_64/msys2-base-x86_64-20140507.tar.xz/download

 Also you need read
 https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/

 Regards,
 Alexey.



 --
 ˙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:
 #149; 3 signs your SCM is hindering your productivity
 #149; Requirements for releasing software faster
 #149; Expert tips and advice for migrating your SCM now
 http://p.sf.net/sfu/perforce___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public




 --
 Is your legacy SCM system holding you back? Join Perforce May 7 to find
 out:
 #149; 3 signs your SCM is hindering your productivity
 #149; Requirements for releasing software faster
 #149; Expert tips and advice for migrating your SCM now
 http://p.sf.net/sfu/perforce
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public




-- 
˙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:
#149; 3 signs your SCM is hindering your productivity
#149; Requirements for releasing software faster
#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce___
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 is the latest msys(2) download?

2014-05-07 Thread Baruch Burstein

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
 написал(а):

 32-bit:
 msys2-base-i686-20140507.tar.xzhttp://sourceforge.net/projects/msys2/files/Base/i686/msys2-base-i686-20140507.tar.xz/download

 64-bit:
 msys2-base-x86_64-20140507.tar.xzhttp://sourceforge.net/projects/msys2/files/Base/x86_64/msys2-base-x86_64-20140507.tar.xz/download

 Also you need read
 https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/

 Regards,
 Alexey.



 --
 ˙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:
 #149; 3 signs your SCM is hindering your productivity
 #149; Requirements for releasing software faster
 #149; Expert tips and advice for migrating your SCM now

 http://p.sf.net/sfu/perforce___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public




 --
 Is your legacy SCM system holding you back? Join Perforce May 7 to find
 out:
 #149; 3 signs your SCM is hindering your productivity
 #149; Requirements for releasing software faster
 #149; Expert tips and advice for migrating your SCM now
 http://p.sf.net/sfu/perforce
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public




 --
 ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı




-- 
˙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:
#149; 3 signs your SCM is hindering your productivity
#149; Requirements for releasing software faster
#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce___
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 is the latest msys(2) download?

2014-05-07 Thread Baruch Burstein

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?


 If you want to use mingw toolchains from my pacman repository then you can
 use mingw*_shell scripts that switch PATH and some other variables to use
 32 or 64 bit MINGW toolchains.
 Script msys2_shell just start normal MSYS session.

 Regards,
 Alexey.

 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
 написал(а):

 32-bit:
 msys2-base-i686-20140507.tar.xzhttp://sourceforge.net/projects/msys2/files/Base/i686/msys2-base-i686-20140507.tar.xz/download

 64-bit:
 msys2-base-x86_64-20140507.tar.xzhttp://sourceforge.net/projects/msys2/files/Base/x86_64/msys2-base-x86_64-20140507.tar.xz/download

 Also you need read
 https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/

 Regards,
 Alexey.



 --
 ˙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:
 #149; 3 signs your SCM is hindering your productivity
 #149; Requirements for releasing software faster
 #149; Expert tips and advice for migrating your SCM now

 http://p.sf.net/sfu/perforce___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public




 --
 Is your legacy SCM system holding you back? Join Perforce May 7 to find
 out:
 #149; 3 signs your SCM is hindering your productivity
 #149; Requirements for releasing software faster
 #149; Expert tips and advice for migrating your SCM now
 http://p.sf.net/sfu/perforce
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public




 --
 ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı




 --
 ˙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:
 #149; 3 signs your SCM is hindering your productivity
 #149; Requirements for releasing software faster
 #149; Expert tips and advice for migrating your SCM now
 http://p.sf.net/sfu/perforce___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public




 --
 Is your legacy SCM system holding you back? Join Perforce May 7 to find
 out:
 #149; 3 signs your SCM is hindering your productivity
 #149; Requirements for releasing software faster
 #149; Expert tips and advice for migrating your SCM now
 http://p.sf.net/sfu/perforce
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public




-- 
˙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:
#149; 3 signs your SCM is hindering your productivity
#149; Requirements for releasing software faster
#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

2014-03-24 Thread Baruch Burstein

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 later.


A little off-topic, but is there some official policy on how far back a
platform should be supported? Both as a host and as a target? XP will be
officially unsupported in a month. It is 13 years old. Is it really a
problem if newer mingw64 official builds don't support it? If someone
really needs it for some reason, they can always take an older version, or
compile themselves without the threading support.

I am asking this as a general question, not only as a bid for native win32
c++11 threading support.

-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
--
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

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

2014-02-24 Thread Baruch Burstein

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 mingw64 I would expect it to be the x86-x86
compiler suite. Instead, it is a 7 MB file (named
mingw-w64-v3.1.0.tar.bz2). When I opened it I couldn't even figure out what
it is. Why/when/who would need this file? What is it? And why is it the
default download?

Baruch

-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis  security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/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] What to Download?

2014-01-20 Thread Baruch Burstein

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 a c runtime library?


 But you still have to redistribute the libgcc DLL(libgcc_s.dll) and
 libstdc++ DLL(libstdc++-6.dll). You can get these files from /mingwXX/bin
 directory, where XX is 32 or 64.


Is there an option to statically link the libgcc/libstdc++-6, so as not to
have to distribute the .dll?

-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/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] Mingw toolchains and Clang

2014-01-15 Thread Baruch Burstein

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 toolchain archive
 *2.* Provide separate builds of GCC+Clang

 I have a question to users what use our toolchains.
 I want you to vote for the best variant of doing that.


I would also vote for #2. I am assuming that most of the users of MinGW64,
especially the users of your prebuilt binaries, are just interested in a
compiler that they can use. Bundling 2 compilers together would just make
using the package more confusing. People (including myself) like your
packages because they make using the toolchain much less confusing.

-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/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] Ruben's Clang builds

2014-01-14 Thread Baruch Burstein

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:
 fatal error: 'stdio.h' file not found
 Anyone (Ruben or other) know what the problem is/how to solve this?


 You also need my GCC 4.6.3-dw2 build available here:

 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/gcc-dw2-4.6-release/i686-w64-mingw32-gcc-dw2-4.6.3-2-release-win32_rubenvb.7z

 The readme on the Clang 3.2 download 
 pagehttp://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/clang-3.2-release/tells
  you to do this, but I agree it's not the most obvious place to look.


Indeed, the Clang 3.2 targeting Win32 download page is not the most obvious
place to look when I am downloading the toolchain targeting Win64 ;) (
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/clang-3.2-release/
)
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/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] Ruben's Clang builds

2014-01-14 Thread 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 seh or std::thread, from here
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%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...@gmail.com wrote:

 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:
 fatal error: 'stdio.h' file not found
 Anyone (Ruben or other) know what the problem is/how to solve this?


 You also need my GCC 4.6.3-dw2 build available here:

 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/gcc-dw2-4.6-release/i686-w64-mingw32-gcc-dw2-4.6.3-2-release-win32_rubenvb.7z

 The readme on the Clang 3.2 download 
 pagehttp://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/clang-3.2-release/tells
  you to do this, but I agree it's not the most obvious place to look.


 Indeed, the Clang 3.2 targeting Win32 download page is not the most
 obvious place to look when I am downloading the toolchain targeting Win64
 ;) (
 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/clang-3.2-release/
 )




-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/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] Ruben's Clang builds

2014-01-14 Thread Baruch Burstein

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 (regular, not seh or std::thread, from here
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%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?

Oh, in that case, know that C++ support is nonexistent (at least as far as
exceptions or the standard library go).

That is fine. I only need C support.

After playing with this for a while, I found that the process to build
Clang+LLVM from source on windows is much easier then it used to be (grab a
couple of SVN repos, run CMake, Open in VS, compile. Easy) so that is what
I ended up doing, and it works fine for me.

Thanks anyway.

As a side question, what does Clang development have to do with MinGW64?
Aren't these actually competing projects?
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/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] Ruben's Clang builds

2014-01-13 Thread 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:
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 Ruben's older builds and not the current
official 3.4 Windows build is that I got the exact same error after using
the 3.4 installer. I thought it was because the installer version was only
for compiling from within VS.

-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/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] clang on Windows

2013-12-24 Thread Baruch Burstein

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
heavenandhell...@gmail.comwrote:

 You have to compile Clang with MinGW, otherwise Clang will use VS's
 toolchain.


 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 just tried building clang
 myself (nothing fancy, just following the step-by-step instructions on
 their site for building with VS) and discovered the the resulting clang.exe
 uses the VS linker. There is an executable llvm-link.exe, though I am not
 sure it is a linker (just guessing from the name). What did you do in your
 toolchains? Did you include the mingw64 linker, or did you get it to use
 the llvm linker somehow?

 Thanks,
 Baruch

 --
 ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı


 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics
 Pro!

 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public




 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics
 Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public




-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/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] thread implementation without pthread

2013-11-24 Thread Baruch Burstein

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 level of indirection, not to mention the whole issue with an extra
runtime dependency. I assume this is for one of the following three reasons:

1. It is not easily feasible to implement this over Win32 threads (I am not
to familiar with either the C++11 requirements, or with the Win32 API, so
don't know if this is true)
2. MinGW64, being a GCC port, prefers to keep as much GCC code as possible,
only adding the porting at the bottom-most layer. If so, while a native
implementation would be possible, it is not of interest to the MinGW64
community.
3. No one has bothered.

Which is it?

-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/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] Which compiler should I use

2013-10-05 Thread Baruch Burstein

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 together this type of information for the past
few months (when I have time). Do you know of any good source for things
like this (understanding the different parts of the toolchain and how they
work together, compiling and cross compiling, binutils, etc.).  I have
basically been using Google when I know the name of the puzzle piece I need
info about, but I don't even always know that, and depending on the
tool/stage. Google may be very helpful or near useless (not actually
Google, but the available documentation is sometimes very lacking)
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/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] MinGW and Msys Directories

2013-09-02 Thread Baruch Burstein

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 is this
 different than cygwin's infamous dll?


 On Sun, Sep 1, 2013 at 4:35 PM, Ray Donnelly mingw.andr...@gmail.comwrote:

 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 own GCC that
 links to (and creates software that links to) msys-2.0.dll that
 provides a more posix-like set of system libraries and environment.

 A regular Windows toolchain would not be the same.

 On Sun, Sep 1, 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 a regular Windows toolchain with Windows binaries be the same?
 
 
  On Sat, Aug 31, 2013 at 5:09 PM, LRN lrn1...@gmail.com wrote:
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  On 31.08.2013 17:14, wynfi...@gmail.com wrote:
  
   #1
  
   I'm sure that there is a good reason to have two very similiar root
 type
   directories such as MinGW and msys, but I can't see it. But, I am
 new to
   MinGW. To me two different pseudo root directories.
  
   Can someone explain why the two are necessary and on would not
 suffice?
   Or point me to a document which explains it?
  
   C:\MinGW  and
   C:\inGW\msys\1.0
  
   Also some directory has a link or is a link.  /usr?
  
 
  Welcome to the land of crazy!
 
  First, some clarifications:
 
  MinGW is a toolchain (compiler, linker, import libraries for MS
  runtimes, headers). It works on W32 and produces pure W32 code, just
  like MSVC does. There are two independent projects that make these
  toolchains:
  * mingw.org - they make mingw.org toolchains (their mailing list is
  mingw-users at sourceforge.net)
  * mingw-w64 - they make mingw-w64 toolchains (this is mingw-w64
 mailing
  list you're writing to).
 
  I won't try to explain to you which toolchain is better (spoiler:
  mingw-w64 is).
 
  However, you need something to a buildsystem to drive the toolchain
 (run
  it with appropriate arguments to compile things and produce binaries).
  MSVC uses Visual Studio and Microsoft make (nmake, if i remember
  correctly?) or some other crazy stuff.
 
  The decision on which buildsystem to use falls upon package
 developers,
  not on mingw developers. Most free software packages are built by GNU
  autotools (which produce GNU makefiles, which are interpreted by GNU
  make).
 
  GNU Autotools use POSIX shell to run. GNU Makefiles produced by GNU
  Autotools almost always use POSIX shell in some places. And while GNU
  Make itself can be built for W32 (and thus may not have any POSIX
  dependencies), these makefiles require a POSIX shell, and to produce
  them ('configure' the package) you need a POSIX shell.
 
  MSYS provides a POSIX environment (including a POSIX shell, compatible
  versions of GNU Autotools, and a POSIXly version of GNU Make) on W32.
 
  Thus, unless the package you are compiling uses some kind of
 alternative
  buildsystem without any POSIX dependencies (CMake, SCons, plain
  makefiles with no shell code, insert your example here), you need
 both
  MinGW and MSYS.
 
  There are two projects that make MSYS:
  * mignw.org - they make the original MSYS (MSYS1)
  * some random people on the net (mostly it's just alexey) affiliated
  mostly with mingw-w64 project - they make MSYS2
 
  (also, there's the Cygwin project, which has its own POSIX-only
  environment, and its own toolchains, but to produce W32 binaries there
  you have to cross-compile from Cygwin to W32; if you know what
  cross-compiling is, and you're ok with it, then stop reading here
 and
  go downloadinstall Cygwin, and ask questions on Cygwin mailing list).
 
  Your MSYS is from mingw.org (i can tell from the way directories are
  laid out).
  I don't know which flavor of MinGW toolchains you're using though.
 
  At this point you should decide whether you really want to use
 mingw-w64
  toolchain or a mingw.org toolchain. If it's mingw.org, then stop
 reading
  and go to their mailing list and ask your questions there. If it's
  mingw-w64, then read on.
 
  Since MSYS is a separate, POSIX environment, it has its own stuff - a
  special toolchain (i686-pc-msys) that produces MSYS binaries, its own
  set of GNU Autotools scripts. Also, all non-portable (POSIX-only)
 stuff
  lives in MSYS - such as bash.
 
  Inside MSYS environment you have a virtual root directory and lots of
  POSIXly things. Namely, for compatibility with real POSIX OSes, MSYS
 has
  a /usr

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

2013-09-02 Thread Baruch Burstein

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 it uses it's own GCC that
 links to (and creates software that links to) msys-2.0.dll that
 provides a more posix-like set of system libraries and environment.

 A regular Windows toolchain would not be the same.

 .. could you do us all a huge favour and actually bother to read the
 replies people write to you, or just use Google?


I actually read that reply. That is what confused me. I guess I didn't
understand the term POSIX-purity stuff. I had understood your answer to
mean that MSYS provides posixy tools and libraries and a shell so that
things like autoconf and various make scripts and #includes will work, but
this is all just for compile time and in the end the compiled programs are
Windowsy, while cygwin lets them compile and run as i on a posix system,
with the .dll supplying the missing parts at runtime.
Then another answer here said that MSYS also had this .dll issue, and that
was what confused me.

-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/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] MinGW and Msys Directories

2013-09-01 Thread Baruch Burstein

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 Sat, Aug 31, 2013 at 5:09 PM, LRN lrn1...@gmail.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 31.08.2013 17:14, wynfi...@gmail.com wrote:
 
  #1
 
  I'm sure that there is a good reason to have two very similiar root type
  directories such as MinGW and msys, but I can't see it. But, I am new to
  MinGW. To me two different pseudo root directories.
 
  Can someone explain why the two are necessary and on would not suffice?
  Or point me to a document which explains it?
 
  C:\MinGW  and
  C:\inGW\msys\1.0
 
  Also some directory has a link or is a link.  /usr?
 

 Welcome to the land of crazy!

 First, some clarifications:

 MinGW is a toolchain (compiler, linker, import libraries for MS
 runtimes, headers). It works on W32 and produces pure W32 code, just
 like MSVC does. There are two independent projects that make these
 toolchains:
 * mingw.org - they make mingw.org toolchains (their mailing list is
 mingw-users at sourceforge.net)
 * mingw-w64 - they make mingw-w64 toolchains (this is mingw-w64 mailing
 list you're writing to).

 I won't try to explain to you which toolchain is better (spoiler:
 mingw-w64 is).

 However, you need something to a buildsystem to drive the toolchain (run
 it with appropriate arguments to compile things and produce binaries).
 MSVC uses Visual Studio and Microsoft make (nmake, if i remember
 correctly?) or some other crazy stuff.

 The decision on which buildsystem to use falls upon package developers,
 not on mingw developers. Most free software packages are built by GNU
 autotools (which produce GNU makefiles, which are interpreted by GNU make).

 GNU Autotools use POSIX shell to run. GNU Makefiles produced by GNU
 Autotools almost always use POSIX shell in some places. And while GNU
 Make itself can be built for W32 (and thus may not have any POSIX
 dependencies), these makefiles require a POSIX shell, and to produce
 them ('configure' the package) you need a POSIX shell.

 MSYS provides a POSIX environment (including a POSIX shell, compatible
 versions of GNU Autotools, and a POSIXly version of GNU Make) on W32.

 Thus, unless the package you are compiling uses some kind of alternative
 buildsystem without any POSIX dependencies (CMake, SCons, plain
 makefiles with no shell code, insert your example here), you need both
 MinGW and MSYS.

 There are two projects that make MSYS:
 * mignw.org - they make the original MSYS (MSYS1)
 * some random people on the net (mostly it's just alexey) affiliated
 mostly with mingw-w64 project - they make MSYS2

 (also, there's the Cygwin project, which has its own POSIX-only
 environment, and its own toolchains, but to produce W32 binaries there
 you have to cross-compile from Cygwin to W32; if you know what
 cross-compiling is, and you're ok with it, then stop reading here and
 go downloadinstall Cygwin, and ask questions on Cygwin mailing list).

 Your MSYS is from mingw.org (i can tell from the way directories are
 laid out).
 I don't know which flavor of MinGW toolchains you're using though.

 At this point you should decide whether you really want to use mingw-w64
 toolchain or a mingw.org toolchain. If it's mingw.org, then stop reading
 and go to their mailing list and ask your questions there. If it's
 mingw-w64, then read on.

 Since MSYS is a separate, POSIX environment, it has its own stuff - a
 special toolchain (i686-pc-msys) that produces MSYS binaries, its own
 set of GNU Autotools scripts. Also, all non-portable (POSIX-only) stuff
 lives in MSYS - such as bash.

 Inside MSYS environment you have a virtual root directory and lots of
 POSIXly things. Namely, for compatibility with real POSIX OSes, MSYS has
 a /usr directory (which is just an alias for the root directory).

 /usr is an alias, not a link. In fact, MSYS doesn't use any symlinks at
 all. Cygwin has its own symlink emulation (which is not compatible with
 W32) by default (but you can make it use W32 symlinks on newer versions
 of Winodws). MSYS2 and Cygwin tend to have more complex directory layouts.

 To keep MinGW stuff from conflicting with MSYS stuff, these two are kept
 in separate roots, and MinGW root is (usually) mounted in MSYS as /mingw.
 Also, when you run bash, /mingw/bin is put into your PATH before
 /usr/bin, unless you set MSYSTEM=MSYS. This means that MinGW stuff has
 priority over MSYS stuff. This is also the reason why MinGW make (if you
 have it) is (or should be) re-named, so that you use /usr/bin/make.exe,
 not /mingw/bin/make.exe, because usually it's the msys-make that you
 want. On the other hand, is not renamed, so you'll be using
 /mingw/bin/gcc.exe, not /usr/bin/gcc.exe, because you definitely don't
 want to use

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

2013-09-01 Thread Baruch Burstein

What is this msys-2.0.dll? What functions does it supply? How is this
different than cygwin's infamous dll?


On Sun, Sep 1, 2013 at 4:35 PM, Ray Donnelly mingw.andr...@gmail.comwrote:

 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 own GCC that
 links to (and creates software that links to) msys-2.0.dll that
 provides a more posix-like set of system libraries and environment.

 A regular Windows toolchain would not be the same.

 On Sun, Sep 1, 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 a regular Windows toolchain with Windows binaries be the same?
 
 
  On Sat, Aug 31, 2013 at 5:09 PM, LRN lrn1...@gmail.com wrote:
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  On 31.08.2013 17:14, wynfi...@gmail.com wrote:
  
   #1
  
   I'm sure that there is a good reason to have two very similiar root
 type
   directories such as MinGW and msys, but I can't see it. But, I am new
 to
   MinGW. To me two different pseudo root directories.
  
   Can someone explain why the two are necessary and on would not
 suffice?
   Or point me to a document which explains it?
  
   C:\MinGW  and
   C:\inGW\msys\1.0
  
   Also some directory has a link or is a link.  /usr?
  
 
  Welcome to the land of crazy!
 
  First, some clarifications:
 
  MinGW is a toolchain (compiler, linker, import libraries for MS
  runtimes, headers). It works on W32 and produces pure W32 code, just
  like MSVC does. There are two independent projects that make these
  toolchains:
  * mingw.org - they make mingw.org toolchains (their mailing list is
  mingw-users at sourceforge.net)
  * mingw-w64 - they make mingw-w64 toolchains (this is mingw-w64 mailing
  list you're writing to).
 
  I won't try to explain to you which toolchain is better (spoiler:
  mingw-w64 is).
 
  However, you need something to a buildsystem to drive the toolchain (run
  it with appropriate arguments to compile things and produce binaries).
  MSVC uses Visual Studio and Microsoft make (nmake, if i remember
  correctly?) or some other crazy stuff.
 
  The decision on which buildsystem to use falls upon package developers,
  not on mingw developers. Most free software packages are built by GNU
  autotools (which produce GNU makefiles, which are interpreted by GNU
  make).
 
  GNU Autotools use POSIX shell to run. GNU Makefiles produced by GNU
  Autotools almost always use POSIX shell in some places. And while GNU
  Make itself can be built for W32 (and thus may not have any POSIX
  dependencies), these makefiles require a POSIX shell, and to produce
  them ('configure' the package) you need a POSIX shell.
 
  MSYS provides a POSIX environment (including a POSIX shell, compatible
  versions of GNU Autotools, and a POSIXly version of GNU Make) on W32.
 
  Thus, unless the package you are compiling uses some kind of alternative
  buildsystem without any POSIX dependencies (CMake, SCons, plain
  makefiles with no shell code, insert your example here), you need both
  MinGW and MSYS.
 
  There are two projects that make MSYS:
  * mignw.org - they make the original MSYS (MSYS1)
  * some random people on the net (mostly it's just alexey) affiliated
  mostly with mingw-w64 project - they make MSYS2
 
  (also, there's the Cygwin project, which has its own POSIX-only
  environment, and its own toolchains, but to produce W32 binaries there
  you have to cross-compile from Cygwin to W32; if you know what
  cross-compiling is, and you're ok with it, then stop reading here and
  go downloadinstall Cygwin, and ask questions on Cygwin mailing list).
 
  Your MSYS is from mingw.org (i can tell from the way directories are
  laid out).
  I don't know which flavor of MinGW toolchains you're using though.
 
  At this point you should decide whether you really want to use mingw-w64
  toolchain or a mingw.org toolchain. If it's mingw.org, then stop
 reading
  and go to their mailing list and ask your questions there. If it's
  mingw-w64, then read on.
 
  Since MSYS is a separate, POSIX environment, it has its own stuff - a
  special toolchain (i686-pc-msys) that produces MSYS binaries, its own
  set of GNU Autotools scripts. Also, all non-portable (POSIX-only) stuff
  lives in MSYS - such as bash.
 
  Inside MSYS environment you have a virtual root directory and lots of
  POSIXly things. Namely, for compatibility with real POSIX OSes, MSYS has
  a /usr directory (which is just an alias for the root directory).
 
  /usr is an alias, not a link. In fact, MSYS doesn't use any symlinks at
  all. Cygwin has its own symlink emulation (which is not compatible with
  W32) by default (but you can

[Mingw-w64-public] config.guess

2013-07-31 Thread Baruch Burstein

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:
*:MINGW64*:*)
echo ${UNAME_MACHINE}-pc-mingw64
 exit ;;
*:MINGW*:*)
echo ${UNAME_MACHINE}-pc-mingw32
 exit ;;
i*:MSYS*:*)
echo ${UNAME_MACHINE}-pc-msys
 exit ;;
i*:windows32*:*)
# uname -m includes -pc on this system.
 echo ${UNAME_MACHINE}-mingw32
exit ;;

I don't understand how this triplet thingy works, but would like to know
what the correct host triplet is for each of the following, and if a change
is needed in the config.guess script:
regular windows executables (32bit) e.g. WinXP
regular windows executables (64bit) e.g. Win7(x64)

Does mingw* at the end of the triplet mean regular windows programs? What
is msys at the end of the triplet? What is the difference between mingw32and
mingw64 at the end of the triplet?

And finally, can someone explain/point me to an explanation of how these
triplets actually work? Do they really make any difference, or are they
just used as the prefix for the compiler chosen? If I rename my compiler
and tools to a-silly-long-prefix-gcc, a-silly-long-prefix-g++,
a-silly-long-prefix-ar etc, would I have a problem compiling like this:

./configure --host=a-silly-long-prefix
make

?

-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/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

2013-07-13 Thread Baruch Burstein

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 on their plate and don't want
 to set the
 expectation that either will be responsible for implementing and
 maintaining an official
 toolchain like JonY appears (aweome) to be doing at
 http://cygwin.mirrors.pair.com/release/gcc4/
 The old speak-up-and-get-stuck-with-it paradox ;)



Thoughts?

 Jon


Speak-up-and-get-stuck-with-it ;)

-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
--
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

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

2013-07-09 Thread Baruch Burstein

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 with mingw compiler as far as I know. So when
I compile with mingw and a static CRT, which CRT is it using? It can't be
using the Windows CRT, since it is a static library from a different
compiler. So does mingw actually supply a CRT? And if so, when I compile
with a dynamic CRT, why is there no dependency on some mingwCRT.dll? Or is
there? Or does mingw supply a static CRT, but use the Windows CRT for
dynamic CRT? Or am I missing some critical knowledge about what CRTs are
without which this whole paragraph makes no sense? I am confused.

All the above is assuming mingw and mingw-w4 are the same in this respect.
Again, my understanding is that the difference between them is just that
mingw-w64 uses newer versions of gcc and binutils and stuff. Am I wrong
again?

If the above is too hard to explain, or my question is too hard to
understand, at the very least, can someone explain to me what parts of
mingw-w64 are gcc code compiled for Windows (minimal adaptions), what parts
are used directly from Windows/MS, and what parts are written specifically
for mingw-w64?

Thank you

-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
--
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] Confusion as to how mingw works

2013-07-09 Thread Baruch Burstein

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 and a static CRT, which CRT is it using? It can't be
  using the Windows CRT, since it is a static library from a different
  compiler. So does mingw actually supply a CRT? And if so, when I compile
  with a dynamic CRT, why is there no dependency on some mingwCRT.dll? Or
 is
  there? Or does mingw supply a static CRT, but use the Windows CRT for
  dynamic CRT? Or am I missing some critical knowledge about what CRTs are
  without which this whole paragraph makes no sense? I am confused.
 

 It does, but only as a supplement to msvcrt.dll, and it is almost always
 linked statically. There is no such dll, the supplement is in
 libmingwex, C startup code in libmingw32 etc.


So if the libmingwex is always linked statically, and the main part of the
CRT is always used dynamically from MSVCRT.dll (since static libraries from
different compilers can't be mixed), then what is the difference between
static and dynamic CRT linking? Or am I wrong and there is no such thing in
mingw(-w64)?





 --
 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




-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
--
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] _free_locale and _new_locale

2013-06-26 Thread Baruch Burstein

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 related things, I used _free_locale and _new_locale, which are in
msvcr80 and up.

Now I have a question and two alternatives:
Q: How hard would it be to implement this in a MinGW-w64 library like
mingw32 or mingwex?
Alt: How hard would it be to provide an efficient uselocale function?
Alt2: How hard would it be to provide *_l functions, which are normal
functions like isdigit etc. that take an additional parameter of type
locale_t instead of using the thread's locale. These are defined in xlocale
on BSD and Mac OS X systems, and Microsoft has them in the newer CRTs.

My current solution is located here:

https://github.com/llvm-mirror/libcxx/blob/master/include/support/win32/locale_win32.h#L37
and here:

https://github.com/llvm-mirror/libcxx/blob/master/src/support/win32/locale_win32.cpp#L16

which
1. is quite inefficient as it tries to do the right thing, but relies on
_configthreadlocale to do so.
2. relies on msvcr100+

The correct path would be to implement the *_l functions, which are quite
useful, but that is above my skill set.

Any help is much appreciated. This will allow MinGW-w64 to work
independent of GCC's C++ Standard library and allow Clang access to a
feature-complete C++11 Standard Library.

Thanks,

Ruben

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
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

2013-06-23 Thread Baruch Burstein

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 23, 2013 at 9:15 AM, Ruben Van Boxem
 vanboxem.ru...@gmail.com wrote:
  Hi everyone,
 
  I have come to the conclusion that my MinGW-w64 builds bring too little
 to
  the table for me to continue maintaining them.
 
  I strongly encourage you to use the plethora of toolchains in a
 multitude of
  configurations available at mingw-builds. Comparing download numbers they
  have a much higher visibility, and e.g. their adoption by the Qt Project
  speaks of their quality. They have succeeded in doing what I missed when
 I
  decided to start building GCC, so my effort spent in doing that is now
  wasted.
 
  I may dabble into getting Clang 3.3 to work on Windows, perhaps even with
  libc++, but I am not promising anything.
 
  I'll still linger around here though, don't worry.

 Sad to see your builds depart!  (But glad you're staying ...)

 Now, I'm sure them mingw-builds builds are fine, and such, but where's a
 fellow to go when he wants a nice, WACKY build?  Hmm?

 You know, like a fine wine -- maybe a bit off the beaten path, quirky,
 even,
 but a worthy vintage, nonetheless.

 Thanks for all your work and all your builds.

  All the best,
 
  Ruben


 Happy Hacking!


 K. Frank


 --
 This SF.net email is sponsored by Windows:

 Build for Windows Store.

 http://p.sf.net/sfu/windows-dev2dev
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public




-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
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

2013-06-23 Thread Baruch Burstein

And of course, as expected. I just went to try the mingw-builds, and
downloaded their recommended installer (the download button on the front
page), and when tried to run it, it didn't work (couldn't download
repository.txt or some such). We really need a build that just works. (I
know, your builds didn't have any installer, and if I am willing to live
without the installer for your builds, I can just directly download the
appropriate package from the mingw-builds site and unpack it, but there is
something anoying about trying the recommended way of doing things and 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 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 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 23, 2013 at 9:15 AM, Ruben Van Boxem
 vanboxem.ru...@gmail.com wrote:
  Hi everyone,
 
  I have come to the conclusion that my MinGW-w64 builds bring too little
 to
  the table for me to continue maintaining them.
 
  I strongly encourage you to use the plethora of toolchains in a
 multitude of
  configurations available at mingw-builds. Comparing download numbers
 they
  have a much higher visibility, and e.g. their adoption by the Qt Project
  speaks of their quality. They have succeeded in doing what I missed
 when I
  decided to start building GCC, so my effort spent in doing that is now
  wasted.
 
  I may dabble into getting Clang 3.3 to work on Windows, perhaps even
 with
  libc++, but I am not promising anything.
 
  I'll still linger around here though, don't worry.

 Sad to see your builds depart!  (But glad you're staying ...)

 Now, I'm sure them mingw-builds builds are fine, and such, but where's a
 fellow to go when he wants a nice, WACKY build?  Hmm?

 You know, like a fine wine -- maybe a bit off the beaten path, quirky,
 even,
 but a worthy vintage, nonetheless.

 Thanks for all your work and all your builds.

  All the best,
 
  Ruben


 Happy Hacking!


 K. Frank


 --
 This SF.net email is sponsored by Windows:

 Build for Windows Store.

 http://p.sf.net/sfu/windows-dev2dev
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public




 --
 ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı




-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
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

2013-06-23 Thread Baruch Burstein

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 button on the front
  page), and when tried to run it, it didn't work (couldn't download
  repository.txt or some such). We really need a build that just works.
 (I
  know, your builds didn't have any installer, and if I am willing to live
  without the installer for your builds, I can just directly download the
  appropriate package from the mingw-builds site and unpack it, but there
 is
  something anoying about trying the recommended way of doing things and
 not
  getting it to work that kind of pushes me away from the whole thing)
  --- END OF RANT 
 
  Sometimes SF.net has problems with downloading files...

 Exactly, especially recently since all projects have been moved to
 their new Allura systems.  And sometimes you'll get a partial
 download.  Try differing mirrors to determine if it helps.


The installer does not ask for a mirror.




 --
 Earnie
 -- https://sites.google.com/site/earnieboyd


 --
 This SF.net email is sponsored by Windows:

 Build for Windows Store.

 http://p.sf.net/sfu/windows-dev2dev
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public




-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
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 GCC 4.8 std::thread enabled build

2013-04-02 Thread Baruch Burstein

Just to clarify that I understand the process:
The GCC implementation of thread and friends (part of the libc or libgcc
or libstdc++ or whatever the GCC standard library is called) really uses
pthread calls under the hood. Changing that would mean changing the code of
the standard library implementation. So in order to use those headers, an
implementation of pthreads needs to exist and be available to the linker =
winpthreads. Is this correct?

I assume that these builds automatically have -lwinpthreads or whatever the
correct name is added to the linking command, since it would be needed 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
vanboxem.ru...@gmail.comwrote:

2013/4/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::thread (and other stuff like mutex) only works on the builds
labeled stdthread'. The difference is that gcc is built based on the posix
threading model using the winpthreads library. The result is a libstdc++
that has multithreading functionality. The affected headers are thread,
mutex, condition_variable, and future. atomic has always worked and
will continue to work without posix threading.

You will need to additionally distribute the winpthreads dll if you do not
link statically. There are no licensing issues, as the winpthreads code is
placed in the Public Domain in the same way the rest of the MinGW-w64
headers and crt are.

The two builds are incompatible due to the difference in libgcc. All code
has to be recompiled with the same toolchain.

I have two builds because currently enabling posix threading (like in the
std::thread builds) makes libgcc depend on winpthreads. This is not a
problem for most people, but it does make even C code not using pthreads
that depends on libgcc (pretty much all code compiled by gcc depends on
libgcc), depend on winpthreads as well.

Ruben

On Tue, Mar 26, 2013 at 9:02 PM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:

Hi,

I have uploaded a new GCC 4.8 experimental std::thread build. Nothing
fundamentally changed since the previous posix-threaded builds.

Enjoy,

Ruben

Find the goodies here:

http://sourceforge.net/projects/mingw-w64/files/Toolchain%20sources/Personal%20Builds/rubenvb/experimental/

http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/gcc-4.8-experimental-stdthread/

http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/gcc-4.8-experimental-stdthread/

--
Own the Future-Intelreg; Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest.
Compete for recognition, cash, and the chance to get your game
on Steam. $5K grand prize plus 10 genre and skill prizes.
Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı

--
Own the Future-Intel(R) Level Up Game Demo Contest 2013

Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2

___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete
for recognition, cash, and the chance to get your game on Steam.
$5K grand prize plus 10 genre and skill prizes. Submit your demo
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
--
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness

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

2013-04-02 Thread Baruch Burstein

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 directory. Your mileage
  may vary. Note my current builds only work with -static, I omitted the
  known fix for this issue from my recent builds.
 
 

 You might end up with weird behavior if you mix thread handles about,
 seeing that you now have 2 or more winpthreads instances, one in the
 libstdc++ DLL, and others in your statically linked code.

 Imagine if each DLL you used had their own statically linked instances.
 It might work if the interfaces are rock solid without any
 implementation detail leaks and/or depend on any static init variables
 that may subject to race conditions.

 If you want static, it is best to use static for everything.

 
  Would having one build with winpthreads bundled into the libstdc++.dll
 (or
  whatever it is) not work?
 
 
  Sure, it might work, but I'm no going to hack that into GCC's brittle
 build
  system.
 

 Likewise, never a good idea to mix static/shared, it may cause ODR
 violation.





 --
 Own the Future-Intel(R) Level Up Game Demo Contest 2013
 Rise to greatness in Intel's independent game demo contest. Compete
 for recognition, cash, and the chance to get your game on Steam.
 $5K grand prize plus 10 genre and skill prizes. Submit your demo
 by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public




-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
--
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete 
for recognition, cash, and the chance to get your game on Steam. 
$5K grand prize plus 10 genre and skill prizes. Submit your demo 
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

2013-02-14 Thread Baruch Burstein

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 Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Placement of additional libraries

2012-11-21 Thread Baruch Burstein

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ʎ ɟı
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

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

2012-06-11 Thread Baruch Burstein

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 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

[Mingw-w64-public] c99

2012-06-07 Thread Baruch Burstein

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-in?

-- 
˙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 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] Building custom version

2012-05-30 Thread Baruch Burstein

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 values.
 You can get a specs file by simply doing g++ -dumpspecs  specs.


I tried this. I went to mingw64_dir\lib\gcc\x86_64-w64-mingw32\4.7.0 and
ran `gcc -dumpspecs  specs`. I then edited the following line in that file:

%(cpp_unique_options) %1 %{m*} %{std*ansitrigraphs} %{W*pedantic*} %{w}
%{f*} %{g*:%{!g0:%{g*} %{!fno-working-directory:-fworking-directory}}}
%{O*} %{undef} %{save-temps*:-fpch-preprocess}

to:

%(cpp_unique_options) %1 %{m*} %{std*c++11trigraphs} %{W*pedantic*} %{w}
%{f*} %{g*:%{!g0:%{g*} %{!fno-working-directory:-fworking-directory}}}
%{O*} %{undef} %{save-temps*:-fpch-preprocess}

This seems to have no affect. Am I doing something wrong?

-- 
˙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 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] Building custom version

2012-05-30 Thread Baruch Burstein

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 a specs file to the
 /path/to/lib/gcc/TARGET/VERSION/ directory with the changed values.
 You can get a specs file by simply doing g++ -dumpspecs  specs.


 I tried this. I went to mingw64_dir\lib\gcc\x86_64-w64-mingw32\4.7.0 and
 ran `gcc -dumpspecs  specs`. I then edited the following line in that file:

 %(cpp_unique_options) %1 %{m*} %{std*ansitrigraphs} %{W*pedantic*} %{w}
 %{f*} %{g*:%{!g0:%{g*} %{!fno-working-directory:-fworking-directory}}}
 %{O*} %{undef} %{save-temps*:-fpch-preprocess}

 to:

 %(cpp_unique_options) %1 %{m*} %{std*c++11trigraphs} %{W*pedantic*}
 %{w} %{f*} %{g*:%{!g0:%{g*} %{!fno-working-directory:-fworking-directory}}}
 %{O*} %{undef} %{save-temps*:-fpch-preprocess}

 This seems to have no affect. Am I doing something wrong?

 I just tried using this spec file explicitly with the
-specs=mingw64_dir\lib\gcc\x86_64-w64-mingw32\4.7.0\specs and it still
doesn't work. What am I doing wrong?

-- 
˙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 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

[Mingw-w64-public] specs file location

2012-05-30 Thread 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. 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 being read, and found that it is
searching in
C:\home\ruben\mingw-w64\toolchain\mingw64mingw64\mingw64\lib\gcc\x86_64-w64-mingw32\specs,
which is obviously wrong.
Can you please fix this?
Thank you.

-- 
˙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 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] Building custom version

2012-05-24 Thread Baruch Burstein

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 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)

 A while ago, i asked the same, and Ruben kindly gave me the
 URL of a repository he maintains, containing all the build scripts
 he crafted to compile his build of the toolchain.

 The link was: https://github.com/rubenvb/MinGW-w64-build-scripts


 Yes this is correct. One thing has changed though since then: I have three
 branches matching my Personal build directories. release and master should
 be usable, experimental is not guaranteed. Note that all the build
 machinery is included in every source package I upload on Sourceforge,
 including all the necessary sources.

 If you need any guidance other than: follow buildall.sh through every
 other scripts, let me know.

 Specifically, I am looking to change the default mode of g++ to c++11.
Where would I change that?

-- 
˙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 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

[Mingw-w64-public] changing defaults

2012-05-23 Thread Baruch Burstein

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ʎ ɟı
--
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

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

2012-05-01 Thread Baruch Burstein

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 build it isn't. After searching for it I found it in
'i686-w64-mingw32\lib', along with what looks like many other important lib
files. in 'i686-w64-mingw32' there is also an 'include' dir and a 'bin' dir
with a few of the tools that are also in the main 'bin' dir such as 'ar',
'as', 'dlltool', 'strip' and a few others.

What is this 'i686-w64-mingw32' folder, and why are some things
separated/duplicated into it? Can I just merge it into the main
lib/include/bin dirs, so that I can compile with the standard makefiles,
without having to always adjust to add another include and lib folder?

-- 
Programming today is a race between software engineers striving to build
bigger and better idiot-proof programs, and the Universe trying to produce
bigger and better idiots. So far, the Universe is winning.  - Rich Cook
--
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] directory structure / lib placement

2012-05-01 Thread Baruch Burstein

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 s somewhere in the cmake/sfml
combo.
Do you have any 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, 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 build it isn't. After searching for it I found
 it in 'i686-w64-mingw32\lib', along with what looks like many other
 important lib files. in 'i686-w64-mingw32' there is also an 'include' dir
 and a 'bin' dir with a few of the tools that are also in the main 'bin' dir
 such as 'ar', 'as', 'dlltool', 'strip' and a few others.

 What is this 'i686-w64-mingw32' folder, and why are some things
 separated/duplicated into it? Can I just merge it into the main
 lib/include/bin dirs, so that I can compile with the standard makefiles,
 without having to always adjust to add another include and lib folder?


 Hi Baruch,

 The directory structure is determined by binutils and gcc. An explanation:
  - the i686-w64-mingw32/bin/* tools are part of binutils and placed there
 for internal use of gcc. Do not use or touch these.
  - the rest of i686-w64-mingw32 subfolder is a strict difference between
 MinGW.org and MinGW-w64 toolchains. In both cases, GCC is configured to
 search these directories automatically, and you should not have to add any
 library paths manually whatsoever.

 To better see what I mean, below the output of gcc -v test.c -lopengl32
 -o test.exe for my 4.7.0 (64-bit) build. Note that all the directories
 containing headers and libraries are searched as appropriate (marked in
 bold).


 COLLECT_GCC=gcc

 COLLECT_LTO_WRAPPER=m:/development/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.7.0/lto-wrapper.exe
 Target: x86_64-w64-mingw32
 Configured with: /home/ruben/mingw-w64/toolchain/src/gcc/configure
 --host=x86_64-w64-mingw32 --build=x86_64-linux-gnu
 --target=x86_64-w64-mingw32
 --with-sysroot=/home/ruben/mingw-w64/toolchain/mingw64mingw64/mingw64
 --prefix=/home/ruben/mingw-w64/toolchain/mingw64mingw64/mingw64
 --with-libiconv-prefix=/home/ruben/mingw-w64/toolchain/mingw64mingw64/prereq_install
 --with-gmp=/home/ruben/mingw-w64/toolchain/mingw64mingw64/prereq_install
 --with-mpfr=/home/ruben/mingw-w64/toolchain/mingw64mingw64/prereq_install
 --with-mpc=/home/ruben/mingw-w64/toolchain/mingw64mingw64/prereq_install
 --with-ppl=/home/ruben/mingw-w64/toolchain/mingw64mingw64/prereq_install
 --with-cloog=/home/ruben/mingw-w64/toolchain/mingw64mingw64/prereq_install
 --enable-cloog-backend=isl --with-host-libstdcxx='-static -lstdc++
 -lm' --enable-shared --enable-static --enable-threads=win32
 --disable-multilib --enable-plugins
 --enable-languages=c,lto,c++,objc,obj-c++,fortran,java --enable-libgomp
 --enable-libstdcxx-debug --enable-sjlj-exceptions
 --enable-fully-dynamic-string --disable-nls --disable-werror
 --enable-checking=release --with-pkgversion=rubenvb-4.7.0 --with-bug-url=
 mingw-w64-public@lists.sourceforge.net --disable-win32-registry
 --disable-rpath --disable-werror CFLAGS='-O2 -mtune=corei7
 -fomit-frame-pointer -momit-leaf-frame-pointer -fgraphite-identity
 -floop-interchange -floop-block -floop-parallelize-all' LDFLAGS=
 Thread model: win32
 gcc version 4.7.0 (rubenvb-4.7.0)
 COLLECT_GCC_OPTIONS='-v' '-o' 'test.exe' '-mtune=generic' '-march=x86-64'
  m:/development/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.7.0/cc1.exe
 -quiet -v -iprefix
 m:\development\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.7.0/ -isysroot
 m:\development\mingw64\bin\../../mingw64 -U_REENTRANT test.c -quiet
 -dumpbase test.c -mtune=generic -march=x86-64 -auxbase test -version -o
 R:\cc8IVxCr.s
 GNU C (rubenvb-4.7.0) version 4.7.0 (x86_64-w64-mingw32)
 compiled by GNU C version 4.7.0, GMP version 5.0.4, MPFR version
 3.1.0, MPC version 0.9
 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
 ignoring duplicate directory
 m:/development/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.7.0/include
 ignoring nonexistent directory
 m:\development\mingw64\bin\../../mingw64/home/ruben/mingw-w64/toolchain/mingw64mingw64/mingw64/lib/gcc/x86_64-w64-mingw32/4.7.0/../../../../include
 ignoring duplicate directory
 m:/development/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.7.0/include-fixed
 ignoring duplicate directory
 m:/development/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/4.7.0/../../../../x86_64-w64-mingw32/include
 ignoring nonexistent directory

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

2012-05-01 Thread Baruch Burstein

I found the problem. It is indeed an SFML CMake script that assumes that
libraries are at mingw\lib and has this hard-coded at one point when
building static libraries (it calls `ar x lib` to open all the static
libraries and then repackages them as a single static library).
Can you explain further which libs would be in `i686-w64-mingw32\lib` and
which in `lib`, so I can try to fix this? And is the name
`i686-w64-mingw32` fixed for all versions of mingw-w64, or is it only for
32-bit builds, or only for 32-bit-generating builds, and if so what would
it be called in other builds?

On Tue, May 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 the problem s somewhere in the cmake/sfml
 combo.
 Do you have any 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, 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 build it isn't. After searching for it I found
 it in 'i686-w64-mingw32\lib', along with what looks like many other
 important lib files. in 'i686-w64-mingw32' there is also an 'include' dir
 and a 'bin' dir with a few of the tools that are also in the main 'bin' dir
 such as 'ar', 'as', 'dlltool', 'strip' and a few others.

 What is this 'i686-w64-mingw32' folder, and why are some things
 separated/duplicated into it? Can I just merge it into the main
 lib/include/bin dirs, so that I can compile with the standard makefiles,
 without having to always adjust to add another include and lib folder?


 Hi Baruch,

 The directory structure is determined by binutils and gcc. An explanation:
  - the i686-w64-mingw32/bin/* tools are part of binutils and placed there
 for internal use of gcc. Do not use or touch these.
  - the rest of i686-w64-mingw32 subfolder is a strict difference between
 MinGW.org and MinGW-w64 toolchains. In both cases, GCC is configured to
 search these directories automatically, and you should not have to add any
 library paths manually whatsoever.

 To better see what I mean, below the output of gcc -v test.c -lopengl32
 -o test.exe for my 4.7.0 (64-bit) build. Note that all the directories
 containing headers and libraries are searched as appropriate (marked in
 bold).


 COLLECT_GCC=gcc

 COLLECT_LTO_WRAPPER=m:/development/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.7.0/lto-wrapper.exe
 Target: x86_64-w64-mingw32
 Configured with: /home/ruben/mingw-w64/toolchain/src/gcc/configure
 --host=x86_64-w64-mingw32 --build=x86_64-linux-gnu
 --target=x86_64-w64-mingw32
 --with-sysroot=/home/ruben/mingw-w64/toolchain/mingw64mingw64/mingw64
 --prefix=/home/ruben/mingw-w64/toolchain/mingw64mingw64/mingw64
 --with-libiconv-prefix=/home/ruben/mingw-w64/toolchain/mingw64mingw64/prereq_install
 --with-gmp=/home/ruben/mingw-w64/toolchain/mingw64mingw64/prereq_install
 --with-mpfr=/home/ruben/mingw-w64/toolchain/mingw64mingw64/prereq_install
 --with-mpc=/home/ruben/mingw-w64/toolchain/mingw64mingw64/prereq_install
 --with-ppl=/home/ruben/mingw-w64/toolchain/mingw64mingw64/prereq_install
 --with-cloog=/home/ruben/mingw-w64/toolchain/mingw64mingw64/prereq_install
 --enable-cloog-backend=isl --with-host-libstdcxx='-static -lstdc++
 -lm' --enable-shared --enable-static --enable-threads=win32
 --disable-multilib --enable-plugins
 --enable-languages=c,lto,c++,objc,obj-c++,fortran,java --enable-libgomp
 --enable-libstdcxx-debug --enable-sjlj-exceptions
 --enable-fully-dynamic-string --disable-nls --disable-werror
 --enable-checking=release --with-pkgversion=rubenvb-4.7.0 --with-bug-url=
 mingw-w64-public@lists.sourceforge.net --disable-win32-registry
 --disable-rpath --disable-werror CFLAGS='-O2 -mtune=corei7
 -fomit-frame-pointer -momit-leaf-frame-pointer -fgraphite-identity
 -floop-interchange -floop-block -floop-parallelize-all' LDFLAGS=
 Thread model: win32
 gcc version 4.7.0 (rubenvb-4.7.0)
 COLLECT_GCC_OPTIONS='-v' '-o' 'test.exe' '-mtune=generic' '-march=x86-64'
  m:/development/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.7.0/cc1.exe
 -quiet -v -iprefix
 m:\development\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.7.0/ -isysroot
 m:\development\mingw64\bin\../../mingw64 -U_REENTRANT test.c -quiet
 -dumpbase test.c -mtune=generic -march=x86-64 -auxbase test -version -o
 R:\cc8IVxCr.s
 GNU C (rubenvb-4.7.0) version 4.7.0 (x86_64-w64-mingw32)
 compiled by GNU C version 4.7.0, GMP version 5.0.4, MPFR version

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

2011-12-13 Thread Baruch Burstein

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 engineers striving to build
bigger and better idiot-proof programs, and the Universe trying to produce
bigger and better idiots. So far, the Universe is winning.  - Rich Cook
--
Systems Optimization Self Assessment
Improve efficiency and utilization of IT resources. Drive out cost and 
improve service delivery. Take 5 minutes to use this Systems Optimization 
Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

50 matches

Mail list logo