Re: [Mingw-w64-public] runtime difference between code compiled with VS and gcc

[Ruben Van Boxem]

Op do 27 aug. 2020 om 07:18 schreef Vincent Torri :

> On Thu, Aug 27, 2020 at 3:24 AM Liu Hao  wrote:
> >
> > 在 2020/8/27 上午2:06, Vincent Torri 写道:
> > >
> > > i've checked in cmd too, same result
> > >
> > > But there is anyway something strange to me :
> > >
> > > myprog_gcc.exe and myprog_vs are *both* run in MSYS2, and the result
> > > is different. So I don't think it's related to path translation. It
> > > would suggest something related to how gcc builds the binary
> > >
> >
> >
> > In 'mingw-w64-crt/crt/crtexe.c' , `argv` is initialized by the function
> `__getmainargs()` which is imported from MSVCRT. VC
> > uses new versions of runtime libraries so it'd be MSVCR100, MSVCR120,
> etc. There might be some differences in the
> > aforementioned function.
>
> that makes sense. Is it possible to tell gcc to use msvcr*.dll instead
> of msvcrt.dll ?
>

Asking where the difference comes from is a useful question.
Relying on these kinds of details to make Unicode work is not IMHO.

If you want correct handling of unicode path names, call the appropriate
functions.
Either compile the GCC code with -municode and use _wmain, or call
CommandLineToArgvW with GetCommandLineW and then a _wfopen.
Windows is an obtuse platform, and its shells do not support the Unix-wide
UTF-8 assumption.
Relying on locally set code pages and how shells interpret them is a recipe
for disaster, not to mention an incredible waste of time and effort.

Ruben

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

Re: [Mingw-w64-public] cmake not creating directories on mingw64, works fine on linux.

[Ruben Van Boxem]

Op vr 24 jan. 2020 00:30 schreef David Mathog :

> On 2020-01-23 15:08, David Grayson wrote:
> > Since CMake in MSYS2 is a native Windows program, if you ask it to make
> > /tmp, I expect it will make C:/tmp.  Did that happen?
>
> Good call, that is exactly what happened!
>
> This is a problem (especially for a cross platform build environment)
> because the path usage within CMakeLists.txt seems to be inconsistent.
>

In my eyes, your CMakeLists.txt shouldn't contain a hardcoded Unix path
such as /tmp. Instead it should e.g. check if it exists and accept a
parameter from the command line to overwrite this using an option. In this
case, it is much more conventional (and it will probably work better
already) if you pass CMAKE_INSTALL_PREFIX from the command line.

Additionally, directly calling unix commands within a CMakeLists.txt is
also suboptimal. Instead you should call cmake -E (replace "cmake" with the
variable CMake defines for itself) followed by the appropriate command you
want to execute.

Lastly, if the path issue is really getting in your way, you could try
calling/building/using an MSYS2 version of CMake. I'm not sure there is a
ready-made package for it, and in light of the above options, I don't think
this will really be necessary.

Ruben

While the file creation actions went into C:/tmp, after doing this:
>
> >>
> >> mkdir /tmp/testinstall
> >> mkdir /tmp/testinstall/bin
> >> mkdir /tmp/testinstall/man
> >> cmake -G "MSYS Makefiles" ..
> >> make
>
> the binaries and man files were all correctly deposited into
> /tmp/testinstall, not C:\tmp\testinstall.  If this was a bash script I
> would know how to handle this, but within cmake I don't.  Skipping all
> the compile stuff look at this subsection:
>
> SET(CMAKE_INSTALL_PREFIX "/tmp/testinstall")
> SET(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_INSTALL_PREFIX}/bin)
> SET(MAN_INSTALL_DIR  ${CMAKE_INSTALL_PREFIX}/man/man1)
>
> FILE(MAKE_DIRECTORY ${CMAKE_RUNTIME_OUTPUT_DIRECTORY})
> if (DO_MAN)
> FILE(GLOB MAN_FILES  "${CMAKE_CURRENT_SOURCE_DIR}/*.1")
> FILE(MAKE_DIRECTORY ${MAN_INSTALL_DIR})
> #install man pages
> ADD_CUSTOM_TARGET(man ALL
> ${CMAKE_COMMAND} -E copy  ${MAN_FILES} ${MAN_INSTALL_DIR}
> COMMENT "Copying all man pages")
> endif (DO_MAN)
>
> The MAKE_DIRECTORY for ${MAN_INSTALL_DIR} went to C:\tmp\testinstall\man
> and the CMAKE_COMMAND -E copy went to /tmp/testinstall/man.  I think
> what is happening
> here is that when the CMAKE_COMMAND (or a compiler action) is done cmake
> actually spins out
> a bash session and runs the command line within that, so the usual
> cygwin to windows path conversions are performeds.  But
> FILE(MAKE_DIRECTORY...) is internal to cmake and it probably does a
> mkdir() call directly, so the conversions are not made.
>
> Suggestions for making this portable
>
> Thanks,
>
> David Mathog
> mat...@caltech.edu
> Manager, Sequence Analysis Facility, Biology Division, Caltech
>
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

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

Re: [Mingw-w64-public] requirements to use a mingw dll with python

[Ruben Van Boxem]

Op di 21 jan. 2020 om 05:48 schreef Biswapriyo Nath :

> Generally, there would not be any big difference between compiled dll by
> msvc and mingw-w64.
>

There are quite a few differences actually, not limited to:
 - dependencies on VS or MinGW-w64/GCC runtime libraries. This will improve
if GCC is configured to link with the ucrt, which I do not think is the
default yet (although it really should be ASAP in my opinion)
 - C++ and structured exception handling code
 - some minor calling convention issues
 - actual compiled code is different
 - many C runtime functions (mostly math and I/O) are different between them
 - ...

In general, the 64-bit GCC C++ ABI is not compatible with the one used by
VS. C code should be fine (with the above caveats), but again, your mileage
may vary.

Ruben


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

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

Re: [Mingw-w64-public] libxml2 2.9.7 built a year ago, not now

[Ruben Van Boxem]

Op wo 11 dec. 2019 23:31 schreef David Mathog :

>
>  or some switch
> used with "./configure".
>

You'll need to pass "--host=i686-w64-mingw32".
If you don't, it tries to identify the MSYS2 environment, which in the best
case returns something Unix-like, which is not what you want.

If there are any dependencies you need, be sure to install e.g.
mingw-w64-i686-libcrypt, which will put the 32-bit windows variant where
the compiler looks for it (prefixed to /mingw32).

Ruben


> In any case, searched for that package and found out who built it and
> will write there to find out where I am going wrong.
>
> Thanks,
>
> David Mathog
> mat...@caltech.edu
> Manager, Sequence Analysis Facility, Biology Division, Caltech
>
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

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

Re: [Mingw-w64-public] GMP compile error with GCC 9.2.0

[Ruben Van Boxem]

This GMP's configure script that is misdetecting your bitness.

Clear your build directory, and be sure to run configure with
"--host=i686-w64-mingw32", perhaps even a "--build=i686-w64-mingw32" if
that's not enough.

That should make sure everything is lined up properly.

Ruben


Op wo 20 nov. 2019 18:35 schreef Kacvinsky, Tom :

> I am using the latest MinGW-w64 i686 tool chain (which is based on GCC
> 9.2.0) to build
> a custom tool chain with UCRT support.   But the compiler is throwing an
> error when
> building GMP:
>
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I..
> -DOPERATION_pre_divrem_1 -m32 -O2 -pedantic -fomit-frame-pointer
> -mtune=pentiumpro -march=pentiumpro -c pre_divrem_1.c -o pre\
> _divrem_1.o
> In file included from ../gmp-impl.h:146,
>  from pre_divrem_1.c:36:
> ../fib_table.h:4:1: warning: data definition has no type or storage class
> 4 | Error, error, this data is for 64 bits
>   | ^
> ../fib_table.h:4:1: warning: type defaults to 'int' in declaration of
> 'Error' [-Wimplicit-int]
> ../fib_table.h:4:8: warning: type defaults to 'int' in declaration of
> 'error' [-Wimplicit-int]
> 4 | Error, error, this data is for 64 bits
>   |^
> ../fib_table.h:4:20: error: expected '=', ',', ';', 'asm' or
> '__attribute__' before 'data'
> 4 | Error, error, this data is for 64 bits
>   |^~~~
>
> This didn't happen when I built GCC 9.1 with GCC 9.1, or when compiling
> GCC 8.3.0 with
> GCC 8.3.0.
>
> I know what the error means, but I am wondering the best way of going
> about fixing it.
> Is there a patch that the MinGW-w64 developers have for this, or should I
> try to fix it
> upstream in GMP?
>
> Thanks,
>
> Tom
>
>
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

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

Re: [Mingw-w64-public] Fwd: [patch] Reimplement GNU threads library on native Windows

[Ruben Van Boxem]

This is awesome!

Although winpthreads was a nice in-between solution for this (and it still
is a good solution for those who want a pthreads library on Windows), this
is what everyone (using C++ and/or OpenMP, heck, even C11 thread support)
needs of course.

I'm interested in seeing real-world benchmarks when using this code!

If only my build scripts still worked reliably (they never really did to be
honest) I could prepare myself (and others) a nice preview of this
functionality.

Ruben

Op vr 28 jun. 2019 om 15:43 schreef NightStrike :

> FYI, Eric posted this today to the GCC patches list.  This may be of
> great interest to many who would prefer native threads instead of the
> winpthreads posix style interface.
>
> Great work, Eric!  I look forward to trying this out!
>
> -- Forwarded message -
> From: Eric Botcazou 
> Date: Fri, Jun 28, 2019 at 6:51 AM
> Subject: [patch] Reimplement GNU threads library on native Windows
> To: 
> Cc: 
>
>
> Hi,
>
> this reimplements the GNU threads library on native Windows (except for the
> Objective-C specific subset) using direct Win32 API calls, in lieu of the
> implementation based on semaphores.  This base implementations requires
> Windows XP/Server 2003, which is the default minimal setting of MinGW-W64.
> This also adds the support required for the C++11 threads, using again
> direct
> Win32 API calls; this additional layer requires Windows Vista/Server 2008
> and
> is enabled only if _GTHREADS_USE_COND is defined to 1.
>
> This also changes libstdc++ to setting _GTHREADS_USE_COND to 1 when the
> switch
> --enable-libstdcxx-threads is passed, which means that C++11 threads are
> still
> disabled by default on native Windows and that you need to explicitly pass
> the
> switch to enable them.  The 30_threads chapter of the testsuite is clean.
>
> Tested on i686-pc-mingw32 and x86_64-pc-mingw32, OK for the mainline?
>
>
> 2019-06-28  Eric Botcazou  
>
> libgcc/
> * config.host (i[34567]86-*-mingw*): Add thread fragment after EH
> one
> as well as new i386/t-slibgcc-mingw fragment.
> (x86_64-*-mingw*): Likewise.
> * config/i386/gthr-win32.h: If _GTHREADS_USE_COND is 1, define both
> __GTHREAD_HAS_COND & __GTHREADS_CXX0X to 1 and _WIN32_WINNT to
> 0x0600.
> Error out if _GTHREAD_USE_MUTEX_TIMEDLOCK is 1.
> Include stdlib.h instead of errno.h and do not include _mingw.h.
> (CONST_CAST2): Add specific definition for C++.
> (ATTRIBUTE_UNUSED): New macro.
> (__UNUSED_PARAM): Delete.
> Define WIN32_LEAN_AND_MEAN before including windows.h.
> (__gthread_objc_data_tls): Use TLS_OUT_OF_INDEXES instead of
> (DWORD)-1.
> (__gthread_objc_init_thread_system): Likewise.
> (__gthread_objc_thread_get_data): Minor tweak.
> (__gthread_objc_condition_allocate): Use ATTRIBUTE_UNUSED.
> (__gthread_objc_condition_deallocate): Likewise.
> (__gthread_objc_condition_wait): Likewise.
> (__gthread_objc_condition_broadcast): Likewise.
> (__gthread_objc_condition_signal): Likewise.
> Include sys/time.h.
> (__gthr_win32_DWORD): New typedef.
> (__gthr_win32_HANDLE): Likewise.
> (__gthr_win32_CRITICAL_SECTION): Likewise.
> (__gthr_win32_CONDITION_VARIABLE): Likewise.
> (__gthread_t): Adjust.
> (__gthread_key_t): Likewise.
> (__gthread_mutex_t): Likewise.
> (__gthread_recursive_mutex_t): Likewise.
> (__gthread_cond_t): New typedef.
> (__gthread_time_t): Likewise.
> (__GTHREAD_MUTEX_INIT_DEFAULT): Delete.
> (__GTHREAD_RECURSIVE_MUTEX_INIT_DEFAULT): Likewise.
> (__GTHREAD_COND_INIT_FUNCTION): Define.
> (__GTHREAD_TIME_INIT): Likewise.
> (__gthr_i486_lock_cmp_xchg): Delete.
> (__gthr_win32_create): Declare.
> (__gthr_win32_join): Likewise.
> (__gthr_win32_self): Likewise.
> (__gthr_win32_detach): Likewise.
> (__gthr_win32_equal): Likewise.
> (__gthr_win32_yield): Likewise.
> (__gthr_win32_mutex_destroy): Likewise.
> (__gthr_win32_cond_init_function): Likewise if _GTHREADS_USE_COND
> is 1.
> (__gthr_win32_cond_broadcast): Likewise.
> (__gthr_win32_cond_signal): Likewise.
> (__gthr_win32_cond_wait): Likewise.
> (__gthr_win32_cond_timedwait): Likewise.
> (__gthr_win32_recursive_mutex_init_function): Delete.
> (__gthr_win32_recursive_mutex_lock): Likewise.
> (__gthr_win32_recursive_mutex_unlock): Likewise.
> (__gthr_win32_recursive_mutex_destroy): Likewise.
> (__gthread_create): New inline function.
> (__gthread_join): Likewise.
> (__gthread_self): Likewise.
> (__gthread_detach): Likewise.
> (__gthread_equal): Likewise.
> (__gthread_yield): Likewise.
> (__gthread_cond_init_function): Likewise if _GTHREADS_USE_COND is
> 1.
>   

Re: [Mingw-w64-public] Wine and mingw-w64 cooperation

[Ruben Van Boxem]

All this probably is a great idea :). I just have (entirely worthless) 2c
two share on one point you bring up:

Op wo 22 mei 2019 om 21:44 schreef Jacek Caban :

> - mingw-w64 name
>
> There have been talks about rebranding mingw-w64 for a long time (longer
> than I am in joined the project). While it's a good name for a branch,
> an established project that is no longer related to mingw.org could have
> a better branding. Kai mentioned that ironcrate was considered as some
> point, but to my knowledge no action was taken at that time. Alexandre
> offered lately that Wine brand could be used for mingw-w64 as well. I
> personally like the idea. Wine is already well recognised brand and
> brings roughly right associations. So... how about WineSDK?
>

The thing is, "mingw" is also a "recognized name". Not only as what it
stands for (minimalistic gnu for windows, although I never understood that
name to describe a windows API implementation...), but also as a toolchain
*target*.

Technically, a lot of things are named to match "mingw" (GCC and Clang
target names, for example). It has even grown out to its own frankenstein
ABI of sorts, next to the MSVC ABI on Windows.

The suggestion to name it WineSDK (very close to WinSDK, clever that ;-) )
seems like a missed oportunity: it would seem to tie the purpose of
"mingw-w64" to Wine, which (for me, and a lot of other people) not the
primary goal of this project.
That goal is providing an "implementation" of the Windows API such that one
can generate code that runs on Windows without proprietary tools. The fact
that there is a lot of code shared with Wine or where it's hosted doesn't
change that, IMHO.

I have no say in any of this (nor do I want to push my opinion), so you can
see this as an interested user's comment. Just try to not confuse people
even more about what this project is supposed to be.

Cheers and keep up the incredible work!

Ruben

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

Re: [Mingw-w64-public] [PATCH] crt/misc/imaxdiv.c: Fix prototype of `lldiv()`.

[Ruben Van Boxem]

The patch is about something totally different. You're replying to another
thread on this mailing list ;)

Great that you got it to work!

2018-06-10 19:36 GMT+02:00 Brian Johnson :

> Thanks very much for the replies.   I was able to successfully link with
> the following string:
>
> sudo ld -dll -o PST.dll -e Main_Entry_fn 
> -L/opt/minGW64/x86_64-w64-mingw32/lib/
> -L/opt/Test_Project PST.obj -l:libmsvcr110.a
>
> The patch that's referred to in the email from Liu Hao -- do I need to
> apply a patch, or should I install a new version of the minGW-64 software?
>
>
> On 6/10/2018 7:30 AM, Liu Hao wrote:
> 在 2018/6/10 22:15, JonY via Mingw-w64-public 写道:
> On 06/10/2018 10:59 AM, Liu Hao wrote:
> This function shall return the struct `lldiv_t`, which used to be
> `long long` mistakenly. Although this function is never used throughout
> this file, the follow warning was observed when compiling this file:
>
> imaxdiv.c:31:1: warning: 'lldiv' alias between functions of
> incompatible types 'ldiv_t(long long int,  long long int)' {aka 'struct
> _ldiv_t(long long int,  long long int)'} and 'imaxdiv_t(intmax_t,
> intmax_t)' {aka 'struct (long long int,  long long int)'}
> [-Wattribute-alias]
>
> This patch fixes the return type hence eliminates the warning.
>
>
>
>
> Patch OK.
>
>
>
> Thanks. Pushed to master.
>
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Crash with Windows 7

[Ruben Van Boxem]

It would really helpful there were a backtrace of the crash, so we could
pinpoint where the problem might lie.

Ruben

Op 27 nov. 2017 10:17 a.m. schreef "Christer Solskogen" <
christer.solsko...@gmail.com>:

> Hi!
>
> I cross compile a Atari ST(e) emulator called hatari using a Linux
> machine. The binary works on Windows 8[.1] and 10, but for some reason it
> does not work on Windows 7. Not all binaries produced crashes. A simple
> hello world program works on Windows 7 as well.
>
> Both 32bit and 64bit versions of the emulator crash. I've used Windows 7
> in both 32bit and 64bit versions.
>
> I know that this is not enough information to help me, but my question
> is... How do I investigate this further?
>
> The cross compiler used is something I've compiled myself.
> Using built-in specs.
> COLLECT_GCC=/opt/cross-mingw-w64/bin/x86_64-w64-mingw32-gcc
> COLLECT_LTO_WRAPPER=/opt/cross-mingw-w64/bin/../lib/gcc/x86_
> 64-w64-mingw32/7.2.1/lto-wrapper
> Target: x86_64-w64-mingw32
> Configured with: /home/solskogen/mingw-w64-builder/trunk/bin/gcc/configure
> --prefix=/home/solskogen/obj/cross-mingw-w64
> --libexecdir=/home/solskogen/obj/cross-mingw-w64/lib
> --target=x86_64-w64-mingw32 --disable-nls --enable-languages=c,c++
> --enable-libgomp --disable-libstdcxx-pch --enable-checking=release
> --enable-threads=win32 --disable-multilib --with-sysroot=/home/solskogen
> /obj/cross-mingw-w64
> Thread model: win32
> gcc version 7.2.1 20171115 (GCC)
>
>
> mingw version is 5.x (from git)
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] no WIN32 predefined macro with -std=c++{98, 11, 14}, only with gnu++{98, 11, 14}

[Ruben Van Boxem]

Op 12 okt. 2017 2:04 p.m. schreef "Norbert Pfeiler" <
norbert.pfeiler+mingw-...@gmail.com>:

Well LH_Mouse did answer the question:

WIN32 is a non-reserved name, would thus break standards-conforming code
(int
WIN32 = 0;) and is therefore not defined in strict standard-conforming mode
(-std=c++??).


The question as how I see it is why WIN32 is defined at all in the
-std=gnu++XX modes. There's no answer to that in this thread.

Ruben


Best, Norbert.

On Thu, Oct 12, 2017 at 1:58 PM Ruben Van Boxem <vanboxem.ru...@gmail.com>
wrote:

> Op 12 okt. 2017 11:15 a.m. schreef "Frédéric" <ufosp...@gmail.com>:
>
> > If you look at MSDN, it's actually _WIN32 is the only macro really
> > mentioned anywhere. WIN32 is defined by most Visual studio projects at
> that
> > level, not the compiler. So in my eyes, changing code to check for
_WIN32
> > is the only right thing to do.
>
>
> Yes and on our suggestion, the library has just done that (changing
> WIN32 to _WIN32).
>
> However, why does w64 treat differently -std=gnu++XX than -std=c++XX?
> This does not look consistent to me as WIN32 is not concerned by the
> standard.
>
>
> That is a good question. I would say it is something decided long ago and
> now either still there due to no one working on changing that, or there is
> a valid reason this is required.
>
> If no one here answers your question, you might try the GCC mailing list,
> although not a lot of Windows developers lurk there..
>
> Ruben
>
>
> F
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
> 
--
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] no WIN32 predefined macro with -std=c++{98, 11, 14}, only with gnu++{98, 11, 14}

[Ruben Van Boxem]

Op 12 okt. 2017 11:15 a.m. schreef "Frédéric" :

> If you look at MSDN, it's actually _WIN32 is the only macro really
> mentioned anywhere. WIN32 is defined by most Visual studio projects at
that
> level, not the compiler. So in my eyes, changing code to check for _WIN32
> is the only right thing to do.


Yes and on our suggestion, the library has just done that (changing
WIN32 to _WIN32).

However, why does w64 treat differently -std=gnu++XX than -std=c++XX?
This does not look consistent to me as WIN32 is not concerned by the
standard.


That is a good question. I would say it is something decided long ago and
now either still there due to no one working on changing that, or there is
a valid reason this is required.

If no one here answers your question, you might try the GCC mailing list,
although not a lot of Windows developers lurk there..

Ruben


F


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] no WIN32 predefined macro with -std=c++{98, 11, 14}, only with gnu++{98, 11, 14}

[Ruben Van Boxem]

If you look at MSDN, it's actually _WIN32 is the only macro really
mentioned anywhere. WIN32 is defined by most Visual studio projects at that
level, not the compiler. So in my eyes, changing code to check for _WIN32
is the only right thing to do.

Ruben

Op 12 okt. 2017 9:11 a.m. schreef "Frédéric" :

> Hi,
>
> I am using mingw w64 5.0.2 on a linux machine with gcc/g++ 7.2.0.
> I noticed that the macro WIN32 is:
> - defined if -std=gnu++{98,11,14,17}
> - not defined if -std=c++{98,11,14,17}
>
> why such difference?
>
> A library I try to cross-compile tests for WIN32 and fails. I have to
> manually change all WIN32 in _WIN32.
>
> From what I understand, macros without _ are the responsability of
> w64, not gcc but I may be wrong.
>
> F
>
> Here is how I test (foo.cpp is an empty file):
> for o in c gnu; do for y in 98 11 14 17; do echo "-std=${o}++${y}";
> x86_64-w64-mingw32-g++-7.2.0 -E -dM -O3 -std=${o}++${y} foo.cpp|grep
> WIN32; done; done
> -std=c++98
> #define _WIN32 1
> #define __WIN32 1
> #define __WIN32__ 1
> -std=c++11
> #define _WIN32 1
> #define __WIN32 1
> #define __WIN32__ 1
> -std=c++14
> #define _WIN32 1
> #define __WIN32 1
> #define __WIN32__ 1
> -std=c++17
> #define _WIN32 1
> #define __WIN32 1
> #define __WIN32__ 1
> -std=gnu++98
> #define _WIN32 1
> #define __WIN32 1
> #define __WIN32__ 1
> #define WIN32 1
> -std=gnu++11
> #define _WIN32 1
> #define __WIN32 1
> #define __WIN32__ 1
> #define WIN32 1
> -std=gnu++14
> #define _WIN32 1
> #define __WIN32 1
> #define __WIN32__ 1
> #define WIN32 1
> -std=gnu++17
> #define _WIN32 1
> #define __WIN32 1
> #define __WIN32__ 1
> #define WIN32 1
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] Handle __CTOR_LIST__ for clang

[Ruben Van Boxem]

Op 3 aug. 2017 9:26 p.m. schreef "Martell Malone" :

Hey Martin,

Glad to see you following up on my various LLVM adventures :)

From what I remember the initialization is done in mingw-w64/crt/gccmain.c.
I believe it may be possible to add this code and not make is clang
specific.

Before the iteration loop check in __do_global_ctors
and __do_global_dtors check if nptrs+1 is equal to -1 and if so just bump
the counter and continue.
This would mean that programs linked with LD would have an extra 2 pointers
in the table but it should be fine otherwise.

Not sure how others would feel about this though.


I for one would like to be able to use one crt with both Clang and GCC. No
use in duplicating 99% of the code for that one little bit of startup code
that needs to be different. Perhaps ldd or Clang needs to be taught to link
a different startup object, but that should be trivial to accomplish!

Cheers!

Ruben


Best,
Martell



On Wed, Aug 2, 2017 at 10:22 PM, Martin Storsjö  wrote:

> Hi Martell, André and Kai,
>
> On Sun, 28 Aug 2016, André Hentschel wrote:
>
> Am 09.08.2016 um 11:16 schrieb Kai Tietz:
>>
>>> Hallo Martell,
>>>
>>> patch is ok.  Wouldn't it be better to have those symbols in linker
>>> scrpt instead?  That is actually the way used in ld for it.
>>>
>>> Thanlks,
>>> Kai
>>>
>>> 2016-08-06 5:14 GMT+02:00 Martell Malone :
>>>
 This patch should be the last piece of the puzzle.
 Now c++ works, it relied heavily on ctors which was broken with clang
 and
 lld.


>>
>> Hi,
>>
>> Kai could you please point Martell on some examples or related files in
>> the mingw-w64 tree?
>> I hope this way we can continue to fix this.
>>
>
> I see that this matter stalled last year when this was discussed...
>
> I had a look at this, and if I understand things correctly, this is
> handled somewhere in e.g. https://sourceware.org/git/git
> web.cgi?p=binutils-gdb.git;a=blob;f=ld/scripttempl/pe.sc.
>
> I don't think the LLD COFF linker supports such linker scripts, so I think
> a clang/lld-based mingw needs to do things differently, using something
> like Martell's patch.
>
> One of the downsides of doing things differently between the two, is that
> you basically need to link your executables using a linker that matches
the
> compiler used to build the mingw CRT. But I guess this is the only way to
> handle it if things are to work with clang at all, right?
>
> Kai approved the patch last year, so I guess it could be applied as a
> first attempt at least? It shouldn't break the setup for normal users,
> contrary to the patch that was reverted before.
>
> // Martin
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Various std::experimental::filesystem errata

[Ruben Van Boxem]

Op 3 jul. 2017 11:27 p.m. schreef "Riot" :

Sure, but they're embarassingly trivial, as my email suggests.

// build with g++ test_temp_path.cpp -lstdc++fs
#include 
#include 

auto main()->int {
  std::cout << "Temp dir: \"" <<
std::experimental::filesystem::temp_directory_path() << "\"" << std::endl;
  return EXIT_SUCCESS;
}


Temp dir: "terminate called after throwing an instance of
'std::experimental::filesystem::v1::__cxx11::filesystem_error'
  what():  filesystem error: temp_directory_path: Unknown error


Similarly:

// build with g++ test_remove.cpp -lstdc++fs
#include 

auto main()->int {
  std::experimental::filesystem::remove("my_file.txt");
  return EXIT_SUCCESS;
}


terminate called after throwing an instance of
'std::experimental::filesystem::v
1::__cxx11::filesystem_error'
  what():  filesystem error: cannot remove: Unknown error [my_file.txt]



Regards,
Riot


What GCC version is this? Where does the filesystem code come from (patch,
upstream, ...)? It might be incomplete and this error may just be the
library telling you it's not implemented.

Ruben


On 3 July 2017 at 21:19, niXman  wrote:

> Riot 2017-07-03 20:04:
>
>> I came across two fairly major inconsistencies with
>> std::experimental::filesystem support today.
>>
>> One is that std::experimental::filesystem::temp_directory_path returns
>> empty every time, with "unknown error."
>>
>> The other is that std::experimental::filesystem::remove silently fails to
>> delete anything.
>>
>
> Hi,
>
> Can you provide testcases, please?
>
>
> --
> Regards, niXman
> ___
> Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows:
> https://sf.net/p/mingw-w64/
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Default _WIN32_WINNT version too low?

[Ruben Van Boxem]

I would maybe go one step further and make this a configure option (with
default value). Then a user can decide if it's necessary to increase this
for any reason whatsoever.

Op 9 jun. 2017 11:18 a.m. schreef "Kai Tietz via Mingw-w64-public" <
mingw-w64-public@lists.sourceforge.net>:

> I agree that - if we want to increase default windows version - we
> should bump our default to Windows 7. Windows Vista is already on the
> way to die ...
> Nevertheless, IMHO we should do that increase just for our master.
>
> Regards,
> Kai
>
> 2017-06-04 1:33 GMT+02:00 Martell Malone :
> > Thanks for that clarification Ricardo.
> > It seems that when we bumped we didn't bump far enough :)
> > Kai what are your thoughts?
> >
> > On Sun, Jun 4, 2017 at 12:13 AM, Ricardo Constantino 
> > wrote:
> >
> >> On 3 June 2017 at 19:52, Mateusz Mikuła  wrote:
> >>
> >> >  0x0502 is Windows Server 2003
> >> >
> >> > If changing default target it should be done properly. Windows Vista
> is
> >> > EOL and it's share is lower than XP so I'd vote for Windows 7.
> >> >
> >> >
> >> > -- Original Message --
> >> > Subject: [Mingw-w64-public] Default _WIN32_WINNT version too low?
> >> > Date: Sat, 3 Jun 2017 18:27:40 +0100
> >> > To: Mingw-w64-public
> >> > From: Martell Malone
> >> > > Hey,
> >> > >
> >> > > As per my discussion with LLVM devs here.
> >> > > 0x600 is the min version required to support libc++ win32 threading.
> >> > > https://reviews.llvm.org/D33384
> >> > >
> >> > > I'm not quite sure why we currently have 0x502 as the default.
> >> > > It seems to be a number sitting between Windows XP and Vista.
> >> >
> >>
> >> Besides being Windows Server 2003 it's also XP SP2.
> >>
> >>
> >> > > I would like to propose we bump to 0x600 which is Vista for this
> >> reason.
> >> > >
> >> > > Kind Regards
> >> > > Martell
> >> > > 
> >> > --
> >> > > Check out the vibrant tech community on one of the world's most
> >> > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >> > > ___
> >> > > Mingw-w64-public mailing list
> >> > > Mingw-w64-public@lists.sourceforge.net
> >> > > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> >> >
> >> >
> >> > 
> >> > --
> >> > Check out the vibrant tech community on one of the world's most
> >> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >> > ___
> >> > Mingw-w64-public mailing list
> >> > Mingw-w64-public@lists.sourceforge.net
> >> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> >> >
> >> >
> >> 
> >> --
> >> Check out the vibrant tech community on one of the world's most
> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >> ___
> >> Mingw-w64-public mailing list
> >> Mingw-w64-public@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> >>
> > 
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > Mingw-w64-public mailing list
> > Mingw-w64-public@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] implicit-fallthrough GCC warning as error in gendef/genpeimg

[Ruben Van Boxem]

Hi,

GCC 7.1 warns on implicit fallthrough in switch-case. Adding attributes or
comments silences this warning.

See https://sourceforge.net/p/mingw-w64/bugs/616/

Attached patch solves this for gendef and genpeimg.

Please apply if OK.

Ruben
diff --git a/mingw-w64-tools/gendef/src/gendef.c 
b/mingw-w64-tools/gendef/src/gendef.c
index a935abfe..cefdd8cb 100644
--- a/mingw-w64-tools/gendef/src/gendef.c
+++ b/mingw-w64-tools/gendef/src/gendef.c
@@ -1031,13 +1031,16 @@ redo_switch:
 PRDEBUG(" 0x%x illegal ", (unsigned int) b);
 #endif
 *aCode=c_ill; return 0;
-  case c_4: sz++;
-  case c_3: sz++;
-  case c_lb:
-  case c_2: sz++;
-  case c_retn: case c_retf:
-  case c_iret: case c_int3:
-  case c_ad: case c_op:
+  case c_4: sz++; // fallthrough
+  case c_3: sz++; // fallthrough
+  case c_lb: // fallthrough
+  case c_2: sz++; // fallthrough
+  case c_retn: // fallthrough
+  case c_retf: // fallthrough
+  case c_iret: // fallthrough
+  case c_int3: // fallthrough
+  case c_ad: // fallthrough
+  case c_op: // fallthrough
   case c_1: *aCode=tb1; return sz;
   case c_lv:
 if (oper_mode) sz+=4;
diff --git a/mingw-w64-tools/genpeimg/src/genpeimg.c 
b/mingw-w64-tools/genpeimg/src/genpeimg.c
index b2430bbc..6a37b1a0 100644
--- a/mingw-w64-tools/genpeimg/src/genpeimg.c
+++ b/mingw-w64-tools/genpeimg/src/genpeimg.c
@@ -203,7 +203,7 @@ pass_args (int argc, char **argv)
  goto error_point;
case 'h':
  if (h[2] == 0)
-   show_usage ();
+   show_usage (); // fallthrough
default:
 error_point:
  fprintf (stderr, "Unknown option ,%s'\n", h);
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] C++ cout executable size

[Ruben Van Boxem]

Op 2 jun. 2017 9:54 p.m. schreef "bob by" <blaoiwn4920...@gmail.com>:

2017-06-02 22:24 GMT+04:00 Ruben Van Boxem <vanboxem.ru...@gmail.com>:

> Be sure to check the final program code size in case of using such a
> utility library vs just the C++ standard library. You might be
surprised...
>
> Also important to note c++ isn't just an object oriented language. It is
so
> much more. If you get through the initial syntactical and semantical
> hurdles of the language and its intricacies.
>
> Lastly I would like to emphasise that unless you are programming a
> microwave or router that this whole discussion based on the size of a
hello
> world program is outright ridiculous. Write a complex program, and then
> discuss the advantages of one language over another.
>
> And now, on to the weekend!
>

Rude. You told pretty much nothing.


I'm sorry you feel that way.

Let me sum up the things I told you and the list:
0. Tl;DR If you want to write c++ code, write c++ code and stop obsessing
over unimportant things like 500kB of binary.
Now for the points I did make in my previous message:
1. Executable size in the order of 500kB means nothing unless you are
programming a memory constrained system. Such a system won't be running
Windows, so getting your Hello World program size down is a waste of time.
2. Rewriting the logic contained in the C++ standard library, libgcc, etc
will require code. It will be less than but near the same size. Using a C
utility library to give you certain things will have a similar effect than
just using the C++ standard library.
3. I pointed out that a limiting definition of C++ as "object-oriented
language" is just not fair to the possibilities it provides. There is so
much more that C cannot possibly give you. Granted, I'm not saying one is
better than the other. Both have their domain. But C++ is a must paradigm
language in which you can write the most funky/cool stuff if you get the
hang of it.
Additionally, because you've got me typing again:
4. Don't reinvent the wheel. Especially when you're learning as you seem to
be. Writing your own cout will only result in bugs because you missed all
the corner cases. Especially when your code becomes more and more complex.

If you want the smallest executable possible, you don't link with any
runtime library (not even msvcrt), but instead link directly to ntdll.dll
and user32.dll, set up a custom entry point, and call the Win32 API
WriteConsole function. Just remember you can't actually do anything useful
then, because all of the C and C++ library functions are off limits.

Ruben


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] C++ cout executable size

[Ruben Van Boxem]

Op 2 jun. 2017 3:32 p.m. schreef "LRN" :

On 6/2/2017 3:53 PM, bob by wrote:
> On 2017-06-02 16:23 GMT+04:00 LRN wrote:
>> On 6/2/2017 2:47 PM, bob by wrote:
>>> Can somebody here write a replacement for the standard cout, that will
be
>>> able to print strings and integers, and internally will just redirect to
>>> puts and itoa? I'm only starting with C++, I'm not sure how to do it.
>>
>> I feel compelled to cite my own first experience with C++. Specifically,
i
>> would like to mention that at the time i did not understand the
difference
>> between C and C++. It took me a while to understand the difference and
>> realize
>> that the programs i was writing were really just C programs, even though
i
>> was
>> compiling them with a C++ compiler. I stopped writing in C++ shortly
>> afterwards.
>>
>> I remembered that because you've mentioned cout and printf in the same
>> sentence.
>>
>
> Do you use datatypes like linked lists or trees or hashmaps? Can you share
> some libraries or code to work with them?
>
> I'm trying to learn C++ just because a lot of code I see is written in
C++.
> Pretty much just in case.

glib[1] is the easiest for me to name. In my experience, large-ish C
projects
tend to include their own (developed in-house or just copy-pasted from
somewhere) implementations of linked lists or trees when needed. Or use
other
utility libraries (google for "C utility library") that complement the C
standard library, which is rather bare by itself.

If you want, you can google for "C vs C++". Also - look for articles on pros
and cons of object-oriented programming in general, and C++ (as an OOP
language) in particular. That might help you understand the current
situation
around C++ better.


Be sure to check the final program code size in case of using such a
utility library vs just the C++ standard library. You might be surprised...

Also important to note c++ isn't just an object oriented language. It is so
much more. If you get through the initial syntactical and semantical
hurdles of the language and its intricacies.

Lastly I would like to emphasise that unless you are programming a
microwave or router that this whole discussion based on the size of a hello
world program is outright ridiculous. Write a complex program, and then
discuss the advantages of one language over another.

And now, on to the weekend!


[1] https://en.wikipedia.org/wiki/GLib


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


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Duplicate symbols definition in between uuid.c and extra-uuid.c

[Ruben Van Boxem]

Your attachment was eaten by the Sourceforge cookie monster :)



2017-05-01 18:55 GMT+02:00 David Grayson :

> I sent a patch to this list 6 days ago that fixes a problem with the way we
> use the selectany attribute.  If you're getting multiple definition errors
> for GUIDs, this will probably fix it.  I'll attach it again.
>
> --David
>
> On Mon, May 1, 2017 at 9:34 AM, Mateusz Mikuła  wrote:
>
> > Symbols in libuuid.a are definitely duplicated, tested on MSYS2, Ubuntu,
> > Arch:
> >
> > nm '/usr/x86_64-w64-mingw32/lib/libuuid.a' | grep FileProtocol
> >  R CLSID_FileProtocol
> >  r .rdata$CLSID_FileProtocol
> > 00f0 R CLSID_FileProtocol
> >
> > Here is disassembly of first duplicated symbol from Ubuntu:
> > https://paste.ubuntu.com/24493619/
> >
> >
> > 2017-05-01 18:03 GMT+02:00 Liu Hao :
> >
> > > On 2017/5/1 21:27, Tomay wrote:
> > > > The following UUIDs are defined in both *uuid.c* and *extra-uuid.c*
> > > source
> > > > files, whitch leads to linking errors with duplicate symbols when
> using
> > > > *libuuid.a*
> > > >
> > > In my opinion it is practically incorrect, but you shouldn't get linker
> > > errors because the macro `INITGUID` is defined in both files hence each
> > > GUID definition is marked with the `selectany` attribute (see
> definition
> > > of the macro `DEFINE_GUID` in [guiddef.h]).
> > >
> > > --
> > > Best regards,
> > > LH_Mouse
> > >
> > >
> > > 
> > > --
> > > Check out the vibrant tech community on one of the world's most
> > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > ___
> > > Mingw-w64-public mailing list
> > > Mingw-w64-public@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> > >
> > 
> > --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > Mingw-w64-public mailing list
> > Mingw-w64-public@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> >
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] Add DBG_PRINTEXCEPTION_WIDE_C exception

[Ruben Van Boxem]

Op 21 mrt. 2017 8:07 a.m. schreef "Liu Hao" :

On 2017/3/20 20:49, Jon Turney wrote:
> Windows 10 now has a separate exception for OutputDebugStringW, rather
than
> converting the string to ANSI and raising DBG_PRINTEXCEPTION_C.
>
> (See https://ntquery.wordpress.com/2015/09/07/windows-10-new-
anti-debug-outputdebugstringw/)
It can also be found here:
https://github.com/x64dbg/x64dbg/commit/50008401ee71b7d84fa2bc6dec1591
7f0f21e94e

Because this is a Windows 10 thing it should probably be wrapped inside
an `#if _WIN32_WINNT >= ??? ... #endif` block. Nevertheless I don't
think we should apply this until we start adding Win10 stuff.


Win10 stuff has been added before. I don't see how this should be any
different?

Ruben


--
Best regards,
LH_Mouse



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Erroneous "out of memory" using LTO

[Ruben Van Boxem]

Additionally, if you look at the default values of the parameters you're
changing, it seems you're stretching the (compiler) implementation quite a
bit, so I'm not sure why you are surprised that the compiler can't handle
it. It seems like you're loading ten blocks of granite into a minivan and
surprised it won't budge.

I'm not criticising you, just telling you you're using the tools outside of
their design specifications.

Ruben

Op 14 mrt. 2017 11:48 p.m. schreef "Ruben Van Boxem" <
vanboxem.ru...@gmail.com>:

> Hello again,
>
> Op 14 mrt. 2017 9:26 p.m. schreef "Riot" <rain.back...@gmail.com>:
>
> On 14 March 2017 at 18:53, Ruben Van Boxem <vanboxem.ru...@gmail.com>
> wrote:
>
> > These options look quite... inefficient... and frankly suboptimal. I hope
> > you do regular benchmarking to see if these are actually any/much better
> > than default -O2 -march=native 'or whatever).
>
> Yes, we benchmark extensively, and we would not use those options if we
> didn't see speed increases.  However, that is not relevant to the topic
> here, which is that certain compiler options appear to cause an erroneous
> claim of memory exhaustion when memory is not, in fact, exhausted.
>
>
> Just making sure. Most people don't know what they're doing, and I'm glad
> you seem to know what you're doing.
>
>
> Inlining everything is not
> > the best optimization.
>
>
> I didn't claim it was.  Again, this is a bit off topic.
>
>
> > Sometimes, -Os (optimizing for speed) can generate
> > faster code than inlined and loop unrolled -O2, because of cache misses.
> In
> > any case, I hope you have hard numbers to back up these very weird
> options.
> >
>
> You mean "optimising for size"?  Yes, that can often be true, especially
> for small programs.  But I asked about a crash in Mingw-w64, not "how would
> you optimise my software?"
>
> I don't think it's entirely reasonable to provide "Doctor, my elbow hurts
> when I do this / Well, don't do that, then!" kind of responses - I'm using
> features of the compiler that should work, that do work on other platforms
> and other builds of the compiler, and worked fine until our codebase
> reached some unclear threshold beyond which they began to fail, with what
> appears to be a Mingw-w64 bug.  Whether or not we're right to be using
> these options in this specific project is not the question, the question is
> whether the compiler is broken, or these features are actually not properly
> supported, or whether something else is at fault.
>
>
> Frankly, LTO does not work well, and things like what you're experiencing
> are exactly the common issues people using GCC's LTO are running into.
> That being said, this is not a MinGW-w64 bug, but a GCC or rather an ld
> (binutils) bug. See for example a similar problem experienced on Linux
> compiling Clang:
> https://sourceware.org/bugzilla/show_bug.cgi?id=18028
>
> Note this doesn't even involve any special options.
>
> As for the whole doctor analogy, although I'm technically a doctor, your
> metafor doesn't make much sense. I seriously hope your doctor does ask "so
> you sprained your knee, have you been skiing lately?" or "ah your elbow
> hurts, perhaps you've been playing tennis a bit too intensively" type of
> questions, instead of just prescribing medication that may not treat the
> root cause of your problem.
>
>
>
> > 2. The RAM usage for the entire system (a stripped down Windows 7 VM)
> does
> > > not seem to exceed 3GB at any point during the linking process, based
> on
> > > observing the windows task manager.  This is the reason that caused me
> to
> > > suspect there was a bug somewhere, rather than the result of actual
> > memory
> > > pressure.
> > >
> >
> > 3GB is the memory usqge limit of 32-bit processes on Windows 64-bit.
> You're
> > running into architectural OS limitations.
> >
>
> With respect, this is simply not the case.  For a start, there is no 3GB
> limit - 32bit programs linked with /LARGEADDRESSAWARE have access to 4GB on
> Windows, otherwise they're limited to 2GB.  I said the entire system,
> Windows included, and the IDE, and all services, are under 3GB at this
> time.  Windows 7 alone weighs around 2.5GB in memory from startup on this
> VM.  The entire compiler appears to use less than 200MB of memory through
> the entire link step until it halts due to the issue - although I can't
> confirm this precisely, because the Windows tools do not appear to allow
> very precise monitoring.  In any case If the linker were spiking in memory
> usage of two gigabytes, that would sure

Re: [Mingw-w64-public] Erroneous "out of memory" using LTO

[Ruben Van Boxem]

The default values can be found in
https://github.com/gcc-mirror/gcc/blob/master/gcc/params.def

For example, but I guess you already knew where to find those.

Op 14 mrt. 2017 11:55 p.m. schreef "Ruben Van Boxem" <
vanboxem.ru...@gmail.com>:

> Additionally, if you look at the default values of the parameters you're
> changing, it seems you're stretching the (compiler) implementation quite a
> bit, so I'm not sure why you are surprised that the compiler can't handle
> it. It seems like you're loading ten blocks of granite into a minivan and
> surprised it won't budge.
>
> I'm not criticising you, just telling you you're using the tools outside
> of their design specifications.
>
> Ruben
>
> Op 14 mrt. 2017 11:48 p.m. schreef "Ruben Van Boxem" <
> vanboxem.ru...@gmail.com>:
>
>> Hello again,
>>
>> Op 14 mrt. 2017 9:26 p.m. schreef "Riot" <rain.back...@gmail.com>:
>>
>> On 14 March 2017 at 18:53, Ruben Van Boxem <vanboxem.ru...@gmail.com>
>> wrote:
>>
>> > These options look quite... inefficient... and frankly suboptimal. I
>> hope
>> > you do regular benchmarking to see if these are actually any/much better
>> > than default -O2 -march=native 'or whatever).
>>
>> Yes, we benchmark extensively, and we would not use those options if we
>> didn't see speed increases.  However, that is not relevant to the topic
>> here, which is that certain compiler options appear to cause an erroneous
>> claim of memory exhaustion when memory is not, in fact, exhausted.
>>
>>
>> Just making sure. Most people don't know what they're doing, and I'm glad
>> you seem to know what you're doing.
>>
>>
>> Inlining everything is not
>> > the best optimization.
>>
>>
>> I didn't claim it was.  Again, this is a bit off topic.
>>
>>
>> > Sometimes, -Os (optimizing for speed) can generate
>> > faster code than inlined and loop unrolled -O2, because of cache
>> misses. In
>> > any case, I hope you have hard numbers to back up these very weird
>> options.
>> >
>>
>> You mean "optimising for size"?  Yes, that can often be true, especially
>> for small programs.  But I asked about a crash in Mingw-w64, not "how
>> would
>> you optimise my software?"
>>
>> I don't think it's entirely reasonable to provide "Doctor, my elbow hurts
>> when I do this / Well, don't do that, then!" kind of responses - I'm using
>> features of the compiler that should work, that do work on other platforms
>> and other builds of the compiler, and worked fine until our codebase
>> reached some unclear threshold beyond which they began to fail, with what
>> appears to be a Mingw-w64 bug.  Whether or not we're right to be using
>> these options in this specific project is not the question, the question
>> is
>> whether the compiler is broken, or these features are actually not
>> properly
>> supported, or whether something else is at fault.
>>
>>
>> Frankly, LTO does not work well, and things like what you're experiencing
>> are exactly the common issues people using GCC's LTO are running into.
>> That being said, this is not a MinGW-w64 bug, but a GCC or rather an ld
>> (binutils) bug. See for example a similar problem experienced on Linux
>> compiling Clang:
>> https://sourceware.org/bugzilla/show_bug.cgi?id=18028
>>
>> Note this doesn't even involve any special options.
>>
>> As for the whole doctor analogy, although I'm technically a doctor, your
>> metafor doesn't make much sense. I seriously hope your doctor does ask "so
>> you sprained your knee, have you been skiing lately?" or "ah your elbow
>> hurts, perhaps you've been playing tennis a bit too intensively" type of
>> questions, instead of just prescribing medication that may not treat the
>> root cause of your problem.
>>
>>
>>
>> > 2. The RAM usage for the entire system (a stripped down Windows 7 VM)
>> does
>> > > not seem to exceed 3GB at any point during the linking process, based
>> on
>> > > observing the windows task manager.  This is the reason that caused
>> me to
>> > > suspect there was a bug somewhere, rather than the result of actual
>> > memory
>> > > pressure.
>> > >
>> >
>> > 3GB is the memory usqge limit of 32-bit processes on Windows 64-bit.
>> You're
>> > running into architectural OS limitations.
>> >
>>
>> With respect, this is simply not the case.

Re: [Mingw-w64-public] Erroneous "out of memory" using LTO

[Ruben Van Boxem]

Hello again,

Op 14 mrt. 2017 9:26 p.m. schreef "Riot" <rain.back...@gmail.com>:

On 14 March 2017 at 18:53, Ruben Van Boxem <vanboxem.ru...@gmail.com> wrote:

> These options look quite... inefficient... and frankly suboptimal. I hope
> you do regular benchmarking to see if these are actually any/much better
> than default -O2 -march=native 'or whatever).

Yes, we benchmark extensively, and we would not use those options if we
didn't see speed increases.  However, that is not relevant to the topic
here, which is that certain compiler options appear to cause an erroneous
claim of memory exhaustion when memory is not, in fact, exhausted.


Just making sure. Most people don't know what they're doing, and I'm glad
you seem to know what you're doing.


Inlining everything is not
> the best optimization.


I didn't claim it was.  Again, this is a bit off topic.


> Sometimes, -Os (optimizing for speed) can generate
> faster code than inlined and loop unrolled -O2, because of cache misses.
In
> any case, I hope you have hard numbers to back up these very weird
options.
>

You mean "optimising for size"?  Yes, that can often be true, especially
for small programs.  But I asked about a crash in Mingw-w64, not "how would
you optimise my software?"

I don't think it's entirely reasonable to provide "Doctor, my elbow hurts
when I do this / Well, don't do that, then!" kind of responses - I'm using
features of the compiler that should work, that do work on other platforms
and other builds of the compiler, and worked fine until our codebase
reached some unclear threshold beyond which they began to fail, with what
appears to be a Mingw-w64 bug.  Whether or not we're right to be using
these options in this specific project is not the question, the question is
whether the compiler is broken, or these features are actually not properly
supported, or whether something else is at fault.


Frankly, LTO does not work well, and things like what you're experiencing
are exactly the common issues people using GCC's LTO are running into.
That being said, this is not a MinGW-w64 bug, but a GCC or rather an ld
(binutils) bug. See for example a similar problem experienced on Linux
compiling Clang:
https://sourceware.org/bugzilla/show_bug.cgi?id=18028

Note this doesn't even involve any special options.

As for the whole doctor analogy, although I'm technically a doctor, your
metafor doesn't make much sense. I seriously hope your doctor does ask "so
you sprained your knee, have you been skiing lately?" or "ah your elbow
hurts, perhaps you've been playing tennis a bit too intensively" type of
questions, instead of just prescribing medication that may not treat the
root cause of your problem.



> 2. The RAM usage for the entire system (a stripped down Windows 7 VM) does
> > not seem to exceed 3GB at any point during the linking process, based on
> > observing the windows task manager.  This is the reason that caused me
to
> > suspect there was a bug somewhere, rather than the result of actual
> memory
> > pressure.
> >
>
> 3GB is the memory usqge limit of 32-bit processes on Windows 64-bit.
You're
> running into architectural OS limitations.
>

With respect, this is simply not the case.  For a start, there is no 3GB
limit - 32bit programs linked with /LARGEADDRESSAWARE have access to 4GB on
Windows, otherwise they're limited to 2GB.  I said the entire system,
Windows included, and the IDE, and all services, are under 3GB at this
time.  Windows 7 alone weighs around 2.5GB in memory from startup on this
VM.  The entire compiler appears to use less than 200MB of memory through
the entire link step until it halts due to the issue - although I can't
confirm this precisely, because the Windows tools do not appear to allow
very precise monitoring.  In any case If the linker were spiking in memory
usage of two gigabytes, that would surely be visible on the task manager
trace, and nothing of the sort appears.  If you can suggest any windows
tools I can use to monitor the peak memory usage of a specific process and
its children, I can try to get a more accurate figure, but it seems to be
significantly lower than any point when memory *should* run out.


Fair enough. But ld is failing to allocate memory. That much is clear. How
and why is a mystery and buried deep in the bowels of its source code.
Have you checked that the ld binary has the large address aware PE flag set?



> Good to know you found the culprit.
>

> Ruben
>

I'm not really clear on the point you're making here.  It seems to me like
a clear case that a bug exists in Mingw-w64 here; I was hoping you could
either confirm that, or show how I'm doing something wrong that's causing
this behaviour.  I may have worked around the possible bug by disabling the
option, but that doesn't address the root cause.  Are you saying that t

Re: [Mingw-w64-public] Erroneous "out of memory" using LTO

[Ruben Van Boxem]

2017-03-13 17:27 GMT+01:00 Riot <rain.back...@gmail.com>:

> Thanks for the quick replies.
>
> I have realised now I made a mistake in my original listing, and omitted
> some commandline options that had been included by our build script, and
> disabling one of these prevents the problem occurring.
>
> The linker options I failed to include in my previous listing were: --param
> max-gcse-memory=10 --param max-inline-insns-single=1 --param
> max-inline-insns-auto=1 --param inline-min-speedup=20 --param
> large-function-insns=1 --param large-function-growth=2000 --param
> large-unit-insns=2 --param inline-unit-growth=200
>
> Although we've used these for years without problem, I decided to try
> various combinations of options, and narrowed it down to one - removing
> just the `max-inline-insns-auto=1` param allows linking to succeed
> normally.
>

These options look quite... inefficient... and frankly suboptimal. I hope
you do regular benchmarking to see if these are actually any/much better
than default -O2 -march=native 'or whatever). Inlining everything is not
the best optimization. Sometimes, -Os (optimizing for speed) can generate
faster code than inlined and loop unrolled -O2, because of cache misses. In
any case, I hope you have hard numbers to back up these very weird options.


>
> The project involved has been steadily growing and I believe the size or
> content of some unit may have just passed some threshold that causes this
> behaviour to be exhibited; nothing has changed in the compiler options we
> use or the version of mingw-w64 since it previously worked successfully.
>
> To answer the questions in the last message:
> 1. I can't test a 64bit build of this particular project just now, because
> we don't currently have 64bit builds of some of the libraries we need to
> statically link with, so I can't report on whether this occurs with the
> 64bit build.  I don't see a 64-to-32bit cross-compiler on windows available
> just now, but if there's a build of one available somewhere I'd be happy to
> try it out.
>

Bah, it's a strange thing to use anyway. Never mind this.


> 2. The RAM usage for the entire system (a stripped down Windows 7 VM) does
> not seem to exceed 3GB at any point during the linking process, based on
> observing the windows task manager.  This is the reason that caused me to
> suspect there was a bug somewhere, rather than the result of actual memory
> pressure.
>

3GB is the memory usqge limit of 32-bit processes on Windows 64-bit. You're
running into architectural OS limitations.


> 3.  I haven't tried stripping the objects prior to linking;  I was going to
> do that until I discovered that I can work around the issue by disabling
> the above-mentioned param.  If it would still be useful for me to try this
> and test further, I can do - just let me know.
>

Good to know you found the culprit.

Ruben

>
> Regards,
> Riot
>
> On 13 March 2017 at 16:01, Ruben Van Boxem <vanboxem.ru...@gmail.com>
> wrote:
>
> > Hi,
> >
> > Just some random helpful thoughts:
> > - the linker typically uses a lot more memory than the sum of everything
> it
> > is linking together.
> > - LTO is still quite unstable, even on Linux, where I know of no Linux
> > distro that actually enables the option to build its binaries.
> > - The 32-bit process is limited to its 3 GB of memory, and it might be
> that
> > some (large) allocations start failing due to memory fragmentation, which
> > can be very prominent in Windows.
> >
> > Some questions as well:
> > - Does this happen if you would use a 64-bit toolchains (perhaps even a
> > 64-bit to 32-bit crosscompiler, if these are still built, probably
> not...)
> > - what is the RAM usage at the point ld bails out?
> > - Have you tried stripping the object files as much as possible before
> > linking them together? Same for all static and dynamic libraries.
> >
> > Cheers,
> >
> > Ruben
> >
> >
> > Op 13 mrt. 2017 1:19 p.m. schreef "Riot" <rain.back...@gmail.com>:
> >
> > Hi all,
> >
> > First a bit of background.  We've been building a large number of
> projects
> > with Mingw-w64 on Windows for about five years now, using LTO for our
> > release builds without any problems until now.  We are building large
> > executables containing a lot of binary assets compiled as objects; input
> > objects to the link step for the problematic project currently total
> 105MB,
> > linking to produce a stripped binary of 68MB.  We are building on 64bit
> > windows, but for a 32bit target.  The version we're using is g++.exe
> > (i686-posix-dwarf

Re: [Mingw-w64-public] Erroneous "out of memory" using LTO

[Ruben Van Boxem]

Hi,

Just some random helpful thoughts:
- the linker typically uses a lot more memory than the sum of everything it
is linking together.
- LTO is still quite unstable, even on Linux, where I know of no Linux
distro that actually enables the option to build its binaries.
- The 32-bit process is limited to its 3 GB of memory, and it might be that
some (large) allocations start failing due to memory fragmentation, which
can be very prominent in Windows.

Some questions as well:
- Does this happen if you would use a 64-bit toolchains (perhaps even a
64-bit to 32-bit crosscompiler, if these are still built, probably not...)
- what is the RAM usage at the point ld bails out?
- Have you tried stripping the object files as much as possible before
linking them together? Same for all static and dynamic libraries.

Cheers,

Ruben


Op 13 mrt. 2017 1:19 p.m. schreef "Riot" :

Hi all,

First a bit of background.  We've been building a large number of projects
with Mingw-w64 on Windows for about five years now, using LTO for our
release builds without any problems until now.  We are building large
executables containing a lot of binary assets compiled as objects; input
objects to the link step for the problematic project currently total 105MB,
linking to produce a stripped binary of 68MB.  We are building on 64bit
windows, but for a 32bit target.  The version we're using is g++.exe
(i686-posix-dwarf-rev1, Built by MinGW-W64 project) 6.3.0.

We have now started to receive the error on the one problematic project:

lto1.exe: out of memory allocating 98173120 bytes
lto-wrapper.exe: fatal error: g++.exe returned 1 exit status

This is the case on several different machines; the VM from which I
received this error has over 20GB RAM allocated, and is not coming close to
exhausting this - memory usage system-wide during the build does not exceed
3GB and there is plenty to spare.

I have tried replacing -flto with -whopr as suggested at
https://sourceforge.net/p/mingw-w64/wiki2/LTO%20and%20GCC/, but this is now
an unrecognised commandline option.

I have tried using -fwpa but I then get "lto1.exe: error: -fwpa and
-fltrans are mutually exclusive" even though -fltrans is not specified
anywhere on the commandline.

The full linker commandline is:
g++.exe  -o  -s -no-pie -flto -static-libstdc++
-static-libgcc -static -m32 -Wl,--stack,8388608 -fuse-linker-plugin -Ofast
-mthreads -mmmx -msse -msse2 -m3dnow -maccumulate-outgoing-args -fgcse-sm
-fgcse-las -fgcse-after-reload -fsched-spec-load
-fsched-spec-load-dangerous -fmerge-all-constants -fmodulo-sched
-fmodulo-sched-allow-regmoves -funsafe-loop-optimizations -fsched-pressure
-fsched-stalled-insns=0 -fsched-stalled-insns-dep=32
-fsched2-use-superblocks -fipa-pta -ftracer -fno-var-tracking-assignments
-fpeel-loops -funroll-loops -funswitch-loops -ftree-loop-if-convert
-ftree-loop-distribution -ftree-loop-im -ftree-loop-ivcanon -fivopts
-fvariable-expansion-in-unroller -freorder-blocks-and-partition
-fbranch-target-load-optimize -ffast-math -fno-math-errno
-funsafe-math-optimizations -fassociative-math -freciprocal-math
-fno-signed-zeros -fno-trapping-math   -mwindows

It seems like the memory exhaustion error is a bug, since there is plenty
of system memory available (even for a 32bit process) - is that the case,
and is this a known issue?  Is there anything we can do to work around this?

Disabling LTO would be highly undesirable as a workaround in this case, as
the project is a game where performance is very important, and LTO makes a
noticeable difference.

We haven't encountered this problem building the same project with the same
settings natively on GCC under Linux or on MacOS.

Any help would be much appreciated!



Regards,
Riot

--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] DirectWrite additions

[Ruben Van Boxem]

Friendly ping!

2016-10-04 21:50 GMT+02:00 Ruben Van Boxem <vanboxem.ru...@gmail.com>:

> Hi Jacek,
>
> I got delayed doing other stuff like painting doors and partying etc. but
> I still have to patch the MinGW-w64 master version to work with Skia.
> Attached is the patch I need to apply. I tried to match your previous
> comments about the interface copy paste. Hope it's OK now.
>
> Please apply if OK.
>
> Cheers,
>
> Ruben
>
> 2016-08-26 14:37 GMT+02:00 Jacek Caban <ja...@codeweavers.com>:
>
>> Hi David,
>>
>> It looks like I committed more than intended. I'm sorry about that. Yes,
>> please commit your patch.
>>
>> Thanks,
>> Jacek
>>
>> On 26.08.2016 03:01, David Wohlferd wrote:
>> > So what happened here?  The winerror.h that got checked in still has
>> > the duplicate defines?
>> >
>> > Is there some reason I can't remove the dupes (attached)?
>> >
>> > dw
>> >
>> >
>> > On 8/24/2016 9:46 AM, Jacek Caban wrote:
>> >> Hi Ruben,
>> >>
>> >> I'm sorry I didn't look at this earlier.
>> >>
>> >> I committed winerror.h (it seems that you included the same defines in
>> >> two different places in those patches, so please retest with committed
>> >> version) and wincodec.idl parts.
>> >>
>> >> However, dwrite_2.h needs some more work. We try to provide dwrite APIs
>> >> for plain C, which makes things a bit more painful than that. You need
>> >> to add THIS (for functions with no arguments) or THIS_ macros in the
>> >> beginning of declaration of each functions. Also to preserve proper
>> vtbl
>> >> layout, declaration of parent interface needs to be copied inside
>> >> __cplusplus guard. See other declarations for an example. Also we try
>> to
>> >> avoid using things like _In_, _Out_ macros in our headers.
>> >>
>> >> Thanks,
>> >> Jacek
>> >>
>> >> On 24.08.2016 18:25, Ruben Van Boxem wrote:
>> >>> I would like to reiterate my request to include the following the
>> >>> changes
>> >>> in MinGW-w64. I have no commit rights, and Kai half-OKed them, so
>> input
>> >>> from someone in the team that can commit them directly would be
>> greatly
>> >>> appreciated!
>> >>>
>> >>> I'll attach both patches (which are required to build Skia with
>> >>> MinGW-w64)
>> >>> to this email for convenience. Note there were duplicate GUID's in the
>> >>> previous patch, those were removed here.
>> >>>
>> >>> Please OK and apply so I can stop keeing my custom builds of MinGW-w64
>> >>> around, thanks :)
>> >>>
>> >>> Cheers!
>> >>>
>> >>> Ruben
>> >>>
>> >>> 2016-08-09 19:44 GMT+02:00 Ruben Van Boxem <vanboxem.ru...@gmail.com
>> >:
>> >>>
>> >>>> Hi Kai (and Jacek),
>> >>>>
>> >>>> Thanks for taking a look.
>> >>>>
>> >>>> Note there are two patches: one I linked to in the body of my
>> >>>> email, the
>> >>>> other was attached. Both would need to be applied by someone (I
>> >>>> don't have
>> >>>> commit rights).
>> >>>>
>> >>>> Cheers,
>> >>>>
>> >>>> Ruben
>> >>>>
>> >>>> 2016-08-09 10:58 GMT+02:00 Kai Tietz <ktiet...@googlemail.com>:
>> >>>>
>> >>>>> Hi Ruben,
>> >>>>>
>> >>>>> patch looks fine to me.  As long as there are no objections
>> >>>>> (Jacek  do
>> >>>>> you?), go ahead and apply.
>> >>>>>
>> >>>>> Thanks,
>> >>>>> Kai
>> >>>>>
>> >>>>> 2016-08-08 20:57 GMT+02:00 Ruben Van Boxem
>> >>>>> <vanboxem.ru...@gmail.com>:
>> >>>>>> Hi guys,
>> >>>>>>
>> >>>>>> it would be nice to keep up to date with new APIs that gain real
>> >>>>>> world
>> >>>>> use,
>> >>>>>> like this little patch:
>> >>>>>> https://github.com/Alexpux/mingw-w64/pull/1/commits/6c0efe37
>> >>

Re: [Mingw-w64-public] DirectWrite additions

[Ruben Van Boxem]

I would like to reiterate my request to include the following the changes
in MinGW-w64. I have no commit rights, and Kai half-OKed them, so input
from someone in the team that can commit them directly would be greatly
appreciated!

I'll attach both patches (which are required to build Skia with MinGW-w64)
to this email for convenience. Note there were duplicate GUID's in the
previous patch, those were removed here.

Please OK and apply so I can stop keeing my custom builds of MinGW-w64
around, thanks :)

Cheers!

Ruben

2016-08-09 19:44 GMT+02:00 Ruben Van Boxem <vanboxem.ru...@gmail.com>:

> Hi Kai (and Jacek),
>
> Thanks for taking a look.
>
> Note there are two patches: one I linked to in the body of my email, the
> other was attached. Both would need to be applied by someone (I don't have
> commit rights).
>
> Cheers,
>
> Ruben
>
> 2016-08-09 10:58 GMT+02:00 Kai Tietz <ktiet...@googlemail.com>:
>
>> Hi Ruben,
>>
>> patch looks fine to me.  As long as there are no objections (Jacek  do
>> you?), go ahead and apply.
>>
>> Thanks,
>> Kai
>>
>> 2016-08-08 20:57 GMT+02:00 Ruben Van Boxem <vanboxem.ru...@gmail.com>:
>> > Hi guys,
>> >
>> > it would be nice to keep up to date with new APIs that gain real world
>> use,
>> > like this little patch:
>> > https://github.com/Alexpux/mingw-w64/pull/1/commits/6c0efe37
>> b32510f72020e38726c7a84690a926fd
>> >
>> > Which is now needed for Qt 5.7 (and skia).
>> >
>> > I would also like to point out attached patch that adds various GUIDs
>> > missing I ran into when compiling skia.
>> >
>> > Cheers,
>> >
>> > Ruben
>> >
>> > 
>> --
>> > What NetFlow Analyzer can do for you? Monitors network bandwidth and
>> traffic
>> > patterns at an interface-level. Reveals which users, apps, and
>> protocols are
>> > consuming the most bandwidth. Provides multi-vendor support for NetFlow,
>> > J-Flow, sFlow and other flows. Make informed decisions using capacity
>> > planning reports. http://sdm.link/zohodev2dev
>> > ___
>> > Mingw-w64-public mailing list
>> > Mingw-w64-public@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>> >
>>
>> 
>> --
>> What NetFlow Analyzer can do for you? Monitors network bandwidth and
>> traffic
>> patterns at an interface-level. Reveals which users, apps, and protocols
>> are
>> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
>> J-Flow, sFlow and other flows. Make informed decisions using capacity
>> planning reports. http://sdm.link/zohodev2dev
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>
>
diff --git a/mingw-w64-headers/include/wincodec.h 
b/mingw-w64-headers/include/wincodec.h
index a863a6c..f853407 100644
--- a/mingw-w64-headers/include/wincodec.h
+++ b/mingw-w64-headers/include/wincodec.h
@@ -319,6 +319,30 @@ DEFINE_GUID(GUID_WICPixelFormat48bppRGB, 
0x6fddc324,0x4e03,0x4bfe,0xb1,0x85,0x3d
 DEFINE_GUID(GUID_WICPixelFormat64bppRGBA, 
0x6fddc324,0x4e03,0x4bfe,0xb1,0x85,0x3d,0x77,0x76,0x8d,0xc9,0x16);
 DEFINE_GUID(GUID_WICPixelFormat64bppPRGBA, 
0x6fddc324,0x4e03,0x4bfe,0xb1,0x85,0x3d,0x77,0x76,0x8d,0xc9,0x17);
 DEFINE_GUID(GUID_WICPixelFormat32bppCMYK, 
0x6fddc324,0x4e03,0x4fbe,0xb1,0x85,0x3d,0x77,0x76,0x8d,0xc9,0x1c);
+
+DEFINE_GUID(GUID_WICPixelFormat32bppBGR101010, 0x6fddc324, 0x4e03, 0x4bfe, 
0xb1, 0x85, 0x3d, 0x77, 0x76, 0x8d, 0xc9, 0x14);
+DEFINE_GUID(GUID_WICPixelFormat16bppGrayFixedPoint, 0x6fddc324, 0x4e03, 
0x4bfe, 0xb1, 0x85, 0x3d, 0x77, 0x76, 0x8d, 0xc9, 0x13);
+DEFINE_GUID(GUID_WICPixelFormat16bppGrayHalf, 0x6fddc324, 0x4e03, 0x4bfe, 
0xb1, 0x85, 0x3d, 0x77, 0x76, 0x8d, 0xc9, 0x3e);
+DEFINE_GUID(GUID_WICPixelFormat32bppGrayFloat,  0x6fddc324, 0x4e03, 0x4bfe, 
0xb1, 0x85, 0x3d, 0x77, 0x76, 0x8d, 0xc9, 0x11);
+DEFINE_GUID(GUID_WICPixelFormat32bppGrayFixedPoint, 0x6fddc324, 0x4e03, 
0x4bfe, 0xb1, 0x85, 0x3d, 0x77, 0x76, 0x8d, 0xc9, 0x3f);
+DEFINE_GUID(GUID_WICPixelFormat32bppRGBE, 0x6fddc324, 0x4e03, 0x4bfe, 0xb1, 
0x85, 0x3d, 0x77, 0x76, 0x8d, 0xc9, 0x3d);
+DEFINE_GUID(GUID_WICPixelFormat48bppBGR, 0xe605a384, 0xb468, 0x46ce, 0xbb, 
0x2e, 0x36, 0xf1, 0x80, 0xe6, 0x43, 0x13);
+DEFINE_GUID(GUID_WICPixelFormat48bppRGBFixedPoint, 0x6fddc324, 0x4e03, 0x4bfe, 
0xb1, 0x85, 0x3

Re: [Mingw-w64-public] Clean build of mingw-w64 (ie no more warning)

[Ruben Van Boxem]

2016-08-17 22:08 GMT+02:00 David Wohlferd :

> I'm reluctant to get too far ahead when creating patches.  My skills
> with git just aren't up to it.
>
>
I can strongly suggest Sourcetree. With it, you can go line by line through
source files and add only the bits and pieces you want to a commit. It's
possible from the commandline, but extremely painful. Note you'll need an
Atlassian account. But for the rest it's a free tool. I use it daily to
split up my work in bits and pieces.

Cheers,

Ruben


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

[Mingw-w64-public] Compiling skia, part 2: xpsobjectmodel.h

[Ruben Van Boxem]

Hi guys,

I'm compiling skia with MinGW-w64 GCC, and after the stuff in my previous
mail and some other small things, I came across this:

In file included from C:/Development/skia/src/xps/SkDocument_XPS.cpp:12:0:
C:/Development/skia/src/xps/SkXPSDevice.h:187:15: error: 'XPS_SIZE' does
not name a type
 const XPS_SIZE& pageSize,
   ^~~~
C:/Development/skia/src/xps/SkXPSDevice.h:259:9: error: 'XPS_GLYPH_INDEX'
has not been declared
 XPS_GLYPH_INDEX* xpsGlyphs,
 ^~~
C:/Development/skia/src/xps/SkXPSDevice.h:261:9: error: 'XPS_POINT' has not
been declared
 XPS_POINT *origin,
 ^
C:/Development/skia/src/xps/SkXPSDevice.h:263:9: error:
'XPS_STYLE_SIMULATION' has not been declared
 XPS_STYLE_SIMULATION sims,
 ^~~~
C:/Development/skia/src/xps/SkXPSDevice.h:277:41: error: 'XPS_RECT' does
not name a type
 const SkRect& leftPoints, const XPS_RECT& left,
 ^~~~
C:/Development/skia/src/xps/SkXPSDevice.h:292:9: error: 'XPS_FILL_RULE' has
not been declared
 XPS_FILL_RULE fillRule);
 ^

Now, looking into xpsobjectmodel.h, I see the typedef for e.g. XPS_SIZE
like so:
typedef struct __WIDL_xpsobjectmodel_generated_name_0037 {
FLOAT width;
FLOAT height;
} XPS_SIZE;

along with all the other symbols in the error message. But this doesn't
look right, and well, the compiler agrees. Did something go wrong here in
the widl step or what is this construct?

I'm using MSYS2's MinGW-w64, which is 5.0.0.4680.362c947-1, so git rev
362c947 I guess.

How do I fix this?

Thanks!

Ruben
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Exceptions broken on vanilla GCC build, why?

[Ruben Van Boxem]

Hi everyone,

Since I am morally compelled to provide a GCCC 6.1 toolchain (even though
Microsoft's S.T.L. has already had one since like, GCC 6.1 was released), I
blew the dust off my old build scripts to see what they are still worth.

Aside from most of the issues that made me put them aside I don't know  how
many years ago, they still provide me with a toolchain with slight
modifications.

I have one problem though: when built without any patches, the GCC 6.1
release fails to provide working exceptions.

This program:

#include 

int main()
try
{
  throw 42;
}
catch(int i)
{
  std::cout << i << '\n';
}

compiles, but crashes. GDB provides the following backtrace:

#0  0x6fc58caf in libstdc++-6!_ZGTtNSt16invalid_argumentD2Ev ()
from M:\VirtualBox\mingw64\bin\libstdc++-6.dll
#1  0x6fc59966 in
libstdc++-6!_ZN10__cxxabiv129__pointer_to_member_type_infoD2Ev () from
M:\VirtualBox\mingw64\bin\libstdc++-6.dll
#2  0x6144d411 in libgcc_s_seh-1!_GCC_specific_handler () from
M:\VirtualBox\mingw64\bin\libgcc_s_seh-1.dll
#3  0x6fd20805 in libstdc++-6!.gxx_personality_seh0 () from
M:\VirtualBox\mingw64\bin\libstdc++-6.dll
#4  0x7fffbef09afd in ntdll!.chkstk () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#5  0x7fffbee94fe9 in ntdll!RtlImageNtHeaderEx () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#6  0x7fffbef08c0a in ntdll!KiUserExceptionDispatcher () from
C:\WINDOWS\SYSTEM32\ntdll.dll
#7  0x7fffbbbd1f28 in RaiseException () from
C:\WINDOWS\system32\KernelBase.dll
#8  0x6144d506 in libgcc_s_seh-1!_Unwind_RaiseException () from
M:\VirtualBox\mingw64\bin\libgcc_s_seh-1.dll
#9  0x6fd1f92e in libstdc++-6!.cxa_throw () from
M:\VirtualBox\mingw64\bin\libstdc++-6.dll
#10 0x004015e8 in main ()

So I'm wondering what is wrong. I seem to remember GCC 4.8's libstdc++
needing an additional export for exceptions to work, but I doubt the same
fix is still valid. The program crashes regardless if I compile it with the
cross-compiler or native toolchain it produced.

Can anyone please shed some light on this?

Thanks a bunch!

Ruben
--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Autotools & git

[Ruben Van Boxem]

I for one am grateful for the configure script. I’m sure I’m not alone.

Ruben

Van: Jean-Baptiste Kempf
Verzonden: maandag 6 juni 2016 21:49
Aan: mingw-w64-public@lists.sourceforge.net
Onderwerp: Re: [Mingw-w64-public] Autotools & git

On 06 Jun, Ozkan Sezer wrote :
> Not everyone would have the required autofoo installed on their
> systems to generate the configury. To me, it is polite to have the
> generated files as they are intended to be in the repo.

If you don't have autotools, then why are you compiling mingw64? If you
are not compiling, take a tarball.

Sorry, that makes little sense to me.

-- 
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Adding a new thread model to GCC

[Ruben Van Boxem]

I'd really really really suggest just using --enable-threads=windows or
something, and implement them using somthing compatible to the windows
runtime if at all possible. This is available on Windows 7+ and seems as
reasonable as anything.

If there are better routines in e.g. Windows 8 or 10, it would be better to
make the decision at runtime if at all possible IMHO, so that newer GCC
versions can also be extended without yet another ABI breaking change like
this.

But hey, I'm all for a new threading model. This would be a great
opportunity to remove the winpthreads dependeny of C++11's std::thread
implementation in libstdc++.

Ruben

2016-04-14 12:12 GMT+02:00 Dongsheng Song :

> If we use  --enable-threads=win32-win7 , the result gcc running on and
> target to win7 or later looks reasonable.
>
> On Thu, Apr 14, 2016 at 2:34 PM, Martin Mitáš  wrote:
> >
> >
> > Dne 14. 4. 2016 v 5:02 Dongsheng Song napsal(a):
> >> Currently, --enable-threads=win32 map to gthr-win32.{h|c}, could we map
> >>
> >> --enable-threads=win32-vista
> >> --enable-threads=win32-win7   // Windows 7 and Windows Server 2008 R2
> >> --enable-threads=win32-win8   // Windows 8 and Windows Server 2012
> >> --enable-threads=win32-win8.1 // Windows 8.1 and Windows Server 2012 R2
> >> --enable-threads=win32-win10  // Windows 10 and Windows Server 2016
> >>
> >> to gthr-windows.{h|c} with the corresponding _WIN32_WINNT macros ?
> >
> > Please don't.
> >
> > Consider that something like -D_WIN32_WINNT=xy -DWINVER=_WIN32_WINNT
> > is often used by projects to see newer Win32API structures and #defines,
> > but the project often still supports older windows in run time. A lot
> > of code out there plays with GetProcAddress() but doesn't want to
> redefine
> > all the new types and constants.
> >
> > Best regards,
> > Martin
> >
> >
> >
> --
> > Find and fix application performance issues faster with Applications
> Manager
> > Applications Manager provides deep performance insights into multiple
> tiers of
> > your business applications. It resolves application problems quickly and
> > reduces your MTTR. Get your free trial!
> > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> > ___
> > Mingw-w64-public mailing list
> > Mingw-w64-public@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
> --
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] improper errors on what should be valid code syntax

[Ruben Van Boxem]

Hi Jim,

I still find it quite astounding that after so many years on this list you
still fail to provide a small, self-contained, compilable example source
code fragment to show the problems you send multiple incomprehensible
emails about.

Show the code or don't get help. I'm quite close to leaving your emails in
my spam folder, where gmail puts them because Google has developed a
totally unrelated hatred for Yahoo.

Give me/us a coliru.stacked-crooked.com link or some other means to
actually show the error you're getting, on a real piece of code. Right now
you're just ranting about you being unable to understand what you're doing
wrong, providing no means whatsoever for other people to actually see what
it is you're doing wrong.

Let this be your last warning from my side. I've helped you fix these
things before, and will continue to do so only if you start showing some
respect by not wasting my time by omitting the actual code causing the
problem.

Ruben

2016-03-31 23:53 GMT+02:00 Jim Michaels :

> I am seeing an example of ostream& operator<<(std::ostream& os, Loc& lc)
> that should work. did something change between now and 30 years ago?
>  -
>  Jim Michaels j...@renewalcomputerservices.com
>  http://www.RenewalComputerServices.com
>  http://www.JesusnJim.com (computer repair info, programming)
>
>
>   From: lh_mouse 
>  To: mingw-w64-public 
>  Sent: Thursday, March 31, 2016 10:04 AM
>  Subject: Re: [Mingw-w64-public] improper errors on what should be valid
> code syntax
>
> I have no idea what you are trying to do by putting stuff into the
> namespace std.
>
> Again, you should attach your source file and let me have a look.
>
> --
> Best regards,
> lh_mouse
> 2016-04-01
>
> -
> 发件人：Jim Michaels 
> 发送日期：2016-04-01 01:00
> 收件人：mingw-w64-public@lists.sourceforge.net
> 抄送：
> 主题：Re: [Mingw-w64-public] improper errors on what should be
> validcodesyntax
>
> excuse me again. the compiler has been thrown into some strange state
> where it's wildly tossing errors. I don't know what caused it. first error
> was overloading not allowed for at. probably at and erase for #3.
> #3.1 didn't change anything, but I changed T to _T.
> 2 If a program declares or defines a name in a context where it is
> reserved, other than as explicitly allowed by
> this Clause, its behavior is undefined meaning what? how would I
> specifically use "this"?
> thanks for the tips.
>
> namespace std {template
> class tree {//outline or N-ary Tree
>
>
>
>   From: lh_mouse 
>  To: mingw-w64-public 
>  Sent: Thursday, March 31, 2016 9:37 AM
>  Subject: Re: [Mingw-w64-public] improper errors on what should be valid
> code syntax
>
> Your code is NOT valid.
> You are using the reserved identifier '_T'. Your code results in undefined
> behavior.
>
> Attach the source file and let us see how to fix it.
>
> 
> WG21 (ISO/IEC C++) N4582
>
> 2.10 Identifiers [lex.name]
> 3 In addition, some identifiers are reserved for use by C++
> implementations and shall not be used otherwise; no
> diagnostic is required.
> (3.1) — Each identifier that contains a double underscore __ or begins
> with an underscore followed by an
> uppercase letter is reserved to the implementation for any use.
> (3.2) — Each identifier that begins with an underscore is reserved to the
> implementation for use as a name in
> the global namespace.
>
> 17.6.4.3 Reserved names [reserved.names]
> 2 If a program declares or defines a name in a context where it is
> reserved, other than as explicitly allowed by
> this Clause, its behavior is undefined.
>
> --
> Best regards,
> lh_mouse
> 2016-04-01
>
> -
> 发件人：Jim Michaels 
> 发送日期：2016-04-01 00:30
> 收件人：mingw64 users
> 抄送：
> 主题：[Mingw-w64-public] improper errors on what should be valid code
> syntax
>
>
>
> c:\jim\tree>g++ -std=c++11 -W -Wall -otree2.o tree2.cpp  2>tree2.err.txt
> c:\jim\tree>gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
>
> COLLECT_LTO_WRAPPER=c:/gcc-5-win32/bin/../libexec/gcc/i686-w64-mingw32/5.3.1/lto-wrapper.exe
> Target: i686-w64-mingw32
> Configured with: /home/cauchy/vcs/svn/gcc/branches/gcc-5-branch/configure
> --prefix=/home/cauchy/native/gcc-5-win32
> --with-sysroot=/home/cauchy/native/gcc-5
> -win32 --build=x86_64-unknown-linux-gnu --host=i686-w64-mingw32
> --target=i686-w64-mingw32 --disable-multilib --disable-nls
> --disable-win32-registry --disab
> le-gcov-tool --enable-checking=release --enable-languages=c,c++,fortran
> --enable-fully-dynamic-string --with-arch=core2 --with-tune=generic
> Thread model: win32
> gcc version 5.3.1 20160318 (GCC)
>
> c:\jim\tree>
>
>
>
>
>
> 

Re: [Mingw-w64-public] problem compiling QT: where to report?

[Ruben Van Boxem]

Hi Mario,

I'd say, prefer the mingw variant, but this is a delicate recommendation. I
haven't tried to build Qt5 myself since the script exists, so I'm not able
to give you any info.

I do know that Qt configure generates MSYS makefiles so you'll need MSYS
make, not mingw32-make to actually build it.

Ruben

2016-03-24 11:03 GMT+01:00 Mario Emmenlauer <ma...@emmenlauer.de>:

>
> Hi Ruben,
>
> thanks for this very very good pointer!! I did not dare look behind
> the scenes of the MinnGW packages, but it turns out that was my
> mistake, they are indeed readable, and helpful! :-)
>
> One more question, if I may: in the PKGBUILD you pointed out, there
> seems to be a "wild" :-) mix of recommended packages from mingw and msys.
> Is there an easy beginners guideline which package to prefer if both
> exist, something like: always prefer mingw-package over msys-package?
> Should I use python2 from msys or mingw? Or install both? For another
> build, I tried cmake from msys and miserably failed, whereas cmake from
> mingw worked out of the box. Is mingw usually "preferable"?
>
> Thanks for your help, and all the best,
>
> Mario
>
>
>
>
> On 24.03.2016 10:47, Ruben Van Boxem wrote:
> > Hi Mario,
> >
> >
> > A thing as large as Qt is quite daunting to get to work, often because
> each little thing you try requires a full rebuild to make sure the change
> was actually
> > propagated through all the layers of the build system.
> >
> > I would suggest starting from the PKGBUILD for the binary package, which
> includes the exact commands, dependencies, and options used to build the Qt
> package you
> > already found. It is located here:
> >
> https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-qt5/PKGBUILD
> >
> > It's quite a monster, but most of that is to suppor the static build and
> making it work with the other MSYS2 libraries instead of those included
> with Qt.
> >
> > Make sure you have all the prerequisite libraries (the "depends" and
> "makedepends" arrays) and try to figure out a sane set of configure
> options. In the worst
> > case just add an "echo" in front of line 541 <
> https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-qt5/PKGBUILD#L541>,
> so you can see what is used
> > for the MSYS2 package.
> >
> > Hope this helps!
> >
> > Qt 4 was simpler, but also less configurable.
> >
> > Good luck!
> >
> > Ruben
> >
> > 2016-03-24 9:56 GMT+01:00 Mario Emmenlauer <ma...@emmenlauer.de  ma...@emmenlauer.de>>:
> >
> >
> > Dear All,
> >
> > thanks for the awesome mingw64, and for the equally awesome msys2.
> > Installation has been almost trivial, very nice work!
> >
> > For the learning experience, I'm trying to compile Qt 5.5.1 for
> x86_64,
> > but I fail. It goes quite a while, but then it fails with:
> > g++ -c -include .pch/release/qt_pch.h -pipe
> -fno-keep-inline-dllexport -O2 -std=c++0x -fno-exceptions -frtti -Wall
> -Wextra -DUNICODE -DQT_NO_MTDEV
> > -DQT_NO_LIBUDEV -DQT_NO_EVDEV -DQT_NO_TSLIB -DQT_NO_LIBINPUT
> -DQT_NO_CAST_FROM_ASCII -DQT_BUILD_PLATFORMSUPPORT_LIB -DQT_BUILDING_QT
> -D_CRT_SECURE_NO_WARNINGS
> > -D_USE_MATH_DEFINES -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS
> -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS
> > -DQT_DISABLE_DEPRECATED_BEFORE=0x040800 -DQT_NO_EXCEPTIONS
> -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_DBUS_LIB -DQT_CORE_LIB -I. -Iaccessibility
> -Idbusmenu -I../gui/kernel
> > -Idbustray -I../gui/kernel -I../../include
> -I../../include/QtPlatformSupport -I../../include/QtPlatformSupport/5.5.1
> > -I../../include/QtPlatformSupport/5.5.1/QtPlatformSupport -Itmp
> -I../../include/QtCore/5.5.1 -I../../include/QtCore/5.5.1/QtCore
> -I../../include/QtGui/5.5.1
> > -I../../include/QtGui/5.5.1/QtGui -I../../include/QtGui
> -I../../include/QtDBus -I../../include/QtCore -I.moc/release
> -I../../mkspecs/win32-g++  -o
> > .obj/release/qdbusmenuconnection.o dbusmenu/qdbusmenuconnection.cpp
> >
> > In file included from dbustray/qdbustrayicon_p.h:55:0,
> >
> >  from dbusmenu/qdbusmenuconnection.cpp:35:
> >
> >
>  
> ../../include/QtPlatformSupport/5.5.1/QtPlatformSupport/private/qdbusmenuconnection_p.h:1:79:
> fatal error:
> > ../../../../../src/platformsupport/dbusmenu/qdbusmenuconnection_p.h:
> No such file or directory
> >
> > compilation terminated.
> >
> >
> >
> > When I follow all the relative paths, the he

Re: [Mingw-w64-public] problem compiling QT: where to report?

[Ruben Van Boxem]

Hi Mario,


A thing as large as Qt is quite daunting to get to work, often because each
little thing you try requires a full rebuild to make sure the change was
actually propagated through all the layers of the build system.

I would suggest starting from the PKGBUILD for the binary package, which
includes the exact commands, dependencies, and options used to build the Qt
package you already found. It is located here:
https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-qt5/PKGBUILD

It's quite a monster, but most of that is to suppor the static build and
making it work with the other MSYS2 libraries instead of those included
with Qt.

Make sure you have all the prerequisite libraries (the "depends" and
"makedepends" arrays) and try to figure out a sane set of configure
options. In the worst case just add an "echo" in front of line 541
,
so you can see what is used for the MSYS2 package.

Hope this helps!

Qt 4 was simpler, but also less configurable.

Good luck!

Ruben

2016-03-24 9:56 GMT+01:00 Mario Emmenlauer :

>
> Dear All,
>
> thanks for the awesome mingw64, and for the equally awesome msys2.
> Installation has been almost trivial, very nice work!
>
> For the learning experience, I'm trying to compile Qt 5.5.1 for x86_64,
> but I fail. It goes quite a while, but then it fails with:
> g++ -c -include .pch/release/qt_pch.h -pipe -fno-keep-inline-dllexport -O2
> -std=c++0x -fno-exceptions -frtti -Wall -Wextra -DUNICODE -DQT_NO_MTDEV
> -DQT_NO_LIBUDEV -DQT_NO_EVDEV -DQT_NO_TSLIB -DQT_NO_LIBINPUT
> -DQT_NO_CAST_FROM_ASCII -DQT_BUILD_PLATFORMSUPPORT_LIB -DQT_BUILDING_QT
> -D_CRT_SECURE_NO_WARNINGS
> -D_USE_MATH_DEFINES -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS
> -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS
> -DQT_DISABLE_DEPRECATED_BEFORE=0x040800 -DQT_NO_EXCEPTIONS -DQT_NO_DEBUG
> -DQT_GUI_LIB -DQT_DBUS_LIB -DQT_CORE_LIB -I. -Iaccessibility -Idbusmenu
> -I../gui/kernel
> -Idbustray -I../gui/kernel -I../../include
> -I../../include/QtPlatformSupport -I../../include/QtPlatformSupport/5.5.1
> -I../../include/QtPlatformSupport/5.5.1/QtPlatformSupport -Itmp
> -I../../include/QtCore/5.5.1 -I../../include/QtCore/5.5.1/QtCore
> -I../../include/QtGui/5.5.1
> -I../../include/QtGui/5.5.1/QtGui -I../../include/QtGui
> -I../../include/QtDBus -I../../include/QtCore -I.moc/release
> -I../../mkspecs/win32-g++  -o
> .obj/release/qdbusmenuconnection.o dbusmenu/qdbusmenuconnection.cpp
>
> In file included from dbustray/qdbustrayicon_p.h:55:0,
>
>  from dbusmenu/qdbusmenuconnection.cpp:35:
>
> ../../include/QtPlatformSupport/5.5.1/QtPlatformSupport/private/qdbusmenuconnection_p.h:1:79:
> fatal error:
> ../../../../../src/platformsupport/dbusmenu/qdbusmenuconnection_p.h: No
> such file or directory
>
> compilation terminated.
>
>
>
> When I follow all the relative paths, the header is there:
>
> ../../include/QtPlatformSupport/5.5.1/QtPlatformSupport/private/../../../../../src/platformsupport/dbusmenu/qdbusmenuconnection_p.h
>
> But I could not find out if g++ is supposed to resolve the relative path
> relative to the included header? Strangely enough, I can not find any-
> thing related to this error on the web, so it must be something I'm
> doing wrong? I'm a bit lost where to report this. Is it Qt related, or
> something g++ should do (differently), or an msys2-setting I did wrong?
>
> Thanks for any pointers, and all the best,
>
> Mario
>
>
>
> PS: I've seen that Qt is also packaged with msys2, but I was hoping to
> have a good learning experience by compiling it myself. Does someone
> have experience how hard it is to get basic functionality working?
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Order of -ladvapi32 versus -lkernel32

[Ruben Van Boxem]

2016-03-18 17:22 GMT+01:00 Vitaly Kruglikov :

>
>
>
> >
> >
> >
> >--
> >
> >Message: 3
> >Date: Fri, 18 Mar 2016 04:37:25 +0100
> >From: Vincent Torri 
> >Subject: Re: [Mingw-w64-public] Order of -ladvapi32 versus -lkernel32
> >To: "mingw-w64-public@lists.sourceforge.net"
> >   
> >Message-ID:
> >    dqw5kx-ocdr06jme...@mail.gmail.com>
> >Content-Type: text/plain; charset=UTF-8
> >
> >hello
> >
> >On Fri, Mar 18, 2016 at 2:48 AM, Vitaly Kruglikov
> > wrote:
> >>
> >> Carl of mingwpy suggested that I re-post this question here (originally
> >>posted on https://groups.google.com/forum/#!topic/mingwpy/kHhGl3mBNfo)
> >>
> >>
> >> My project's CMAKE_CXX_STANDARD_LIBRARIES originally contained by
> >>default: "-lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32
> >>-loleaut32 -luuid -lcomdlg32 -ladvapi32" (without the quotes).
> >>
> >> I used mingwpy (based on mingw-w64) running on Windows Server 2008
> >>32-bit to build my python extension DLL. The apr (apache portable
> >>runtime) library that's linked as a static library into my extension DLL
> >>makes a call to "CreateProcessAsUserW". When testing, I would get this
> >>error: "The procedure entry point CreateProcessAsUserW could not be
> >>located in the dynamic link library KERNEL32.dll". I found this error
> >>surprising, because CreateProcessAsUserW is in advapi32, and
> >>"-ladvapi32" was listed at the end of CMAKE_CXX_STANDARD_LIBRARIES, so
> >>it should have been picked up by mingwpy's linker/loader. I was able to
> >>fix this failure by moving
> >> "-ladvapi32" to the beginning so that it was in front of "-lkernel32"
> >>like so: "-ladvapi32 -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32
> >>-lole32 -loleaut32 -luuid -lcomdlg32".
> >>
> >> However, I don't understand why it was necessary to place -ladvapi32 in
> >>front of -lkernel32 to make the CreateProcessAsUserW problem go away.
> >>Does someone know why this would be necessary? Is there a better way to
> >>avoid this problem?
> >
> >advapi32.dll depends on kernel32.dll (you can see that with dependency
> >walker for example), and the order of the -l flags is important : from
> >right to left : the "less dependent" to the "more dependant". So pass
> >to the linker "-ladvapi32 -lkernel32" because advapi32.dll depends on
> >kernel32.dll
> >
> >Vincent Torri
>
> Many thanks Vincent. I guess that the haphazard order that CMake used to
> add libraries to CMAKE_CXX_STANDARD_LIBRARIES should not be relied upon,
> and should be set explicitly instead!
>

No, you should report this to CMake so that they can fix it!
https://public.kitware.com/Bug/my_view_page.php

Point them to this discussion to prove your point :)

Ruben
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Differentiate on MinGW-w64 and TDM-gcc

[Ruben Van Boxem]

2016-03-17 16:23 GMT+01:00 LRN :

>
> Why would you do that? What are you hoping to achieve by telling the
> difference between TDM mingw-w64-based toolchain and non-TDM
> mingw-w64-based toolchain?
>
>
There are ABI differences, but those shouldn't matter inside the code. This
difference should only be important on the level of a build system and
packaging.

There is, as far as I know, no special define you can check to
differentiate TDM's GCC from vanilla GCC. If I remember correctly, there's
no extra defines added into the compiler in the patches applied in a TDM
build.

Ruben
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Floating-Point Operations Not Deterministic When Excecuted Asynchronously

[Ruben Van Boxem]

2016-03-01 16:58 GMT+01:00 Daniel Franzini :

> I think that comparing floating point numbers this way is wrong (well, at
> least in C it is) because you can't never know how is the precision of this
> comparison. It might be the case that in C++ the == operator is overloaded
> and it performs correctly using some pre-defined precision constant. I'm
> note sure about that.
>
> if (b == c)
> continue;
>

That is true in general, but here, it is used to compare the output of
identical code.

The fact that this produces different outcomes on different threads has to
do with Windows' floating point settings on thread creation and the way
MinGW-w64 handles it (C++ threads are handled through pthread):
https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/CAGGsPMz%3D5w-2X_7bGSgWjEzyQFuwtBVCR%2BOm%3Dr-OA_zp8E2KdQ%40mail.gmail.com/#msg3303
more precisely:
https://sourceforge.net/p/mingw-w64/mailman/message/33080317/

I don't remember what the wanted behaviour is. I do know this is probably
the cause for your inconsistency.

Ruben


> On Tue, Mar 1, 2016 at 9:04 AM, Benjamin Bihler <
> benjamin.bih...@compositence.de> wrote:
>
>> Hello,
>>
>> I have found a behaviour of MinGW-W64 5.3.0 that disturbs me very much:
>> the results of floating-point operations may differ, if they are run on
>> different threads. This does not happen with Visual Studio 2015 and not
>> with g++ 4.9.2 on my Debian Linux.
>>
>> Please consider the following program:
>>
>> -
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>>
>> std::string getResult()
>> {
>> std::cout << "Thread id: " << std::this_thread::get_id() <<
>> std::endl;
>> std::string result = "Result:\n";
>>
>> double a, b, c;
>> int i;
>> for (i = 0, a = 1.0; i < 1000; i++)
>> {
>> a *= 1.0001;
>> b = sqrt(a);
>> c = pow(a, 0.5);
>> if (b == c)
>> continue;
>> result += std::string("a: ") + std::to_string(a) + " b: "
>> + std::to_string(b) + " c: " +
>> std::to_string(c) + "\n";
>> }
>>
>> return result;
>> }
>>
>> int main()
>> {
>> std::string string1 = getResult();
>>
>> std::future result = std::async(std::launch::async,
>> getResult);
>>
>> std::string string2 = result.get();
>>
>> if (string1 != string2)
>> {
>> std::cout << "String 1 is: " << std::endl << string1 <<
>> std::endl
>> << " and string 2 is: " << std::endl <<
>> string2 << std::endl;
>> }
>> else
>> {
>> std::cout << "The results are the same." << std::endl;
>> }
>>
>> return 0;
>> }
>> -
>>
>> If I compile it with g++ -O0 -std=gnu++11 Main.cpp the output is
>>
>> -
>> Thread id: 1
>> Thread id: 2
>> The results are the same.
>> -
>>
>> If I compile it with g++ -O1 -std=gnu++11 Main.cpp the output is
>> -
>> Thread id: 1
>> Thread id: 2
>> String 1 is: ...
>> -
>>
>> The same happens with "-O2".
>>
>> If I change the line
>> std::future result = std::async(std::launch::async,
>> getResult);
>> to
>> std::future result = std::async(getResult);
>> then the result is independent from the optimization flag the following:
>>
>> -
>> Thread id: 1
>> Thread id: 1
>> The results are the same.
>> -
>>
>> What actually disturbs me, is that the results differ with asynchronous
>> execution and optimization turned on. I tried parameters like -ffloat-store
>> -msse2 -mfpmath=sse to have consistent floating-point operation results,
>> but this won't help.
>>
>> Is this a bug? Or are there compiler flags that force the floating-point
>> operation results to be consistent?
>>
>> Any help is greatly appreciated!
>>
>> Regards,
>> Benjamin
>>
>>
>> --
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>
>
>
> --
> Daniel
>
> "Let us 

Re: [Mingw-w64-public] Fix mkstemp implementation

[Ruben Van Boxem]

2016-03-01 15:25 GMT+01:00 Dongsheng Song :

>
> On Tue, Mar 1, 2016 at 8:42 PM, Ismail Donmez  wrote:
>
>> Hi,
>>
>> mingw-w64's current mkstemp implementation wrongly uses _O_TEMPORARY which
>> doesn't make sense. Here is a patch from openSUSE we apply to fix it:
>>
>> From: Jan Engelhardt 
>> Date: 2015-03-31 18:57:45.887248277 +0200
>> References: https://sourceforge.net/p/mingw-w64/bugs/471/
>>
>> When closing the file handle obtained from mkstemp(), the file
>> ought _not_ to be deleted.
>>
>
> Why did you make such assertion ?
>
> I can not see such statement in POSIX, Linux, FreeBSD or OpenBSD:
>
> http://pubs.opengroup.org/onlinepubs/009695399/functions/mkstemp.html
> http://man7.org/linux/man-pages/man3/mkstemp.3.html
> https://www.freebsd.org/cgi/man.cgi?query=mkstemp
> http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/mkdtemp.3
>

There is also no a priori reason to delete it. POSIX also gives an as-if
clause in the latest version of the document you linked:
http://pubs.opengroup.org/onlinepubs/9699919799/

open(pathname, O_RDWR|O_CREAT|O_EXCL, S_IRUSR|S_IWUSR)

Which does not include the Windows-specific _O_TEMPORARY as in MinGW-w64.

Why do you think deleting it is an added value? This function can therefore
also used to create a file that will later be moved, see e.g.
http://stackoverflow.com/a/12008368/256138

So, IMHO, the patch is correct.

Ruben


>
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Should i686 compilers allow the -m64 switch ?

[Ruben Van Boxem]

2016-01-20 13:55 GMT+01:00 :

> Hi,
>
> Probably 2 dumb questions - my only excuse is that I haven't been forced to
> consider them before. And that's not a very good excuse.
>

There are no dumb questions, only dumb answers.


> My other sin is that this post pretty much repeats the question I've asked
> in:
> http://sourceforge.net/p/mingw-w64/mailman/message/34780084/
>
> With all of the mingw-w64 4.x.x i686 compilers that I have used (and there
> have been a few), any attempt to use the -m64 switch has been a fatal
> error:
> sorry, unimplemented: 64-bit mode not compiled in
>
> But then I downloaded the 5.3.0 i686-posix-sjlj toolchain from:
>
> http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/5.3.0/threads-posix/sjlj/i686-5.3.0-release-posix-sjlj-rt_v4-rev0.7z/download
>
> It *does* allow the -m64 switch to be used.
>
> So:
>
> Question 1:
> Given that the 4.x.x i686 compilers do not allow the -m64 switch, why
> should
> a 5.3.0 i686 compiler allow the -m64 switch to work ?
>
> Question 2:
> Conversely, given that the 5.3.0 i686 compiler allows the -m64 switch, why
> do the 4.x.x i686 compilers *not*  allow it ?
>
> I may have follow-up questions, depending upon the answers to those two
> questions.
>

I would say the 4.X.x behaviour is the expected one and GCC 5.3.0 is in
error. Could be that there is a reason for this though, so I'll leave it to
the experts.

If no one here gives a sufficient answer, and you still care, just submit a
bug report with the GMP story. They'll probably say GMP checks the wrong
behaviour blabla but it's still a legitimate bug IMHO.

Ruben


>
> Cheers,
> Rob
>
>
>
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] i686-posix-sjlj and gmp

[Ruben Van Boxem]

2016-01-19 7:07 GMT+01:00 :

> Hi,
>
> On Windows 7, when I build gmp-6.1.0 in the msys shell using gcc-4.9.2
> (i686-posix-sjlj), ABI is set to 32 and the created gmp.h contains entries
> such as:
>
> #define GMP_LIMB_BITS  32
> and
> #define __GMP_CFLAGS
> "-m32 -O2 -pedantic -fomit-frame-pointer -mtune=sandybridge
> -march=sandybridge"
>
> (And the same holds for previous 4.x.x i686 compilers that I've used.)
>
> A couple of days ago I grabbed gcc version 5.3.0 (i686-posix-sjlj-rev0,
> Built by MinGW-W64 project) from:
>
> http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/5.3.0/threads-posix/sjlj/i686-5.3.0-release-posix-sjlj-rt_v4-rev0.7z/download
>
> When I use that compiler to build gmp-6.1.0, ABI is set to 64 and the
> created gmp.h contains entries such as:
>
> #define GMP_LIMB_BITS  64
> and
> #define __GMP_CFLAGS
> "-O2 -pedantic -fomit-frame-pointer -m64 -mtune=sandybridge
> -march=sandybridge"
>
> Is this as expected with the i686-posix-sjlj compiler when moving from
> 4.x.x
> to 5.x.x ? (It's not something I was expecting.)
>

I would say it's a bug in GMP's configure magic. If I remember correctly,
it was horrendously bad in detecting compiler target architecture around
the 4.x-5.x era.
I solved it then by explicitly setting --host and --build, as well as
passing in CC and CXX, although I'm not sure these will be necessary for
the configure step to get the right results.

I can try to take a look tonight if it's still a problem for you.

I'm assuming here there was no mixup in compiler packaging and the 5.3.0
toolchain does indeed target i686 like it should (I have no reason to doubt
this).

Ruben


>
> Cheers,
> Rob
>
>
>
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Strange linker error with gcc-5.1 32-bit involving 'virtual thunk'

[Ruben Van Boxem]

2015-07-28 14:44 GMT+02:00 Edward Diener eldlistmaili...@tropicsoft.com:

 On 7/28/2015 8:27 AM, Edward Diener wrote:
  Without trying immediately to give specific code for what is a large
  project, I am getting linker errors when trying to link a second shared
  library which depends on a first shared library that has linked
  successfully. The errors are:
 
 
 xml_wgrammar.o:xml_wgrammar.cpp:(.rdata$_ZTVN5boost7archive21xml_archive_exceptionE[__ZTVN5boost7archive21xml_archive_exceptionE]+0x20):
  undefined reference to `virtual thunk to
  boost::archive::archive_exception::what() const'
 
 xml_wgrammar.o:xml_wgrammar.cpp:(.rdata$_ZTCN5boost7archive21xml_archive_exceptionE4_NS0_17archive_exceptionE[__ZTCN5boost7archive21xml_archive_exceptionE4_NS0_17archive_exceptionE]+0x38):
  undefined reference to `virtual thunk to
  boost::archive::archive_exception::what() const'
  collect2.exe: error: ld returned 1 exit status
 
  The xml_wgrammar.o file is being linked into the second shared library.
  The xml_wgrammar.cpp file includes xml_archive_exception.hpp. The
  xml_archive_exception.hpp includes and derives from
  archive_exception.hpp. Both xml_archive_exception and archive_exception
  have their implementation in the first shared library and have their
  necessary implementations exported. The implementation of
  archive_exception::what() is exported in the first shared library and is
  imported when seen by xml_wgrammar.cpp.
 
  What is so strange is that there is no call to archive_exception::what()
  in the preprocessed output of xml_wgrammar.cpp.
 
  Does anybody have any idea what might be going on here before I take the
  time to reduce this situation into a short enough fragment to show in a
  subsequent thread in this post ?

 After adding an xml_archive_exception::what() implementation which just
 calls its base class archive_exception::what() implementation I now
 receive the linker errors:

 xml_wgrammar.o: In function `ZN5boost7archive21xml_archive_exceptionD1Ev':
 xml_archive_exception.hpp:34: undefined reference to `vtable for
 boost::archive::xml_archive_exception'
 xml_archive_exception.hpp:34: undefined reference to `vtable for
 boost::archive::xml_archive_exception'
 xml_archive_exception.hpp:34: undefined reference to `vtable for
 boost::archive::xml_archive_exception'
 xml_archive_exception.hpp:34: undefined reference to `VTT for
 boost::archive::xml_archive_exception'
 collect2.exe: error: ld returned 1 exit status

 Perhaps this will give someone an idea of what might be happening.


You're not linking to the boost_serialization library. At least on my
system (Linux) boost::archive::{xml_,}archive_exception::what() is defined
there.

Add -lboost_serialization to your linker command or do the same through
your build system.
Note that Boost has #pragma lib ... to tell MSVC to link the required
libraries. GCC does not have such a functionality.

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

Re: [Mingw-w64-public] Linker problem with i686-5.1.0-posix-dwarf-rt_v4-rev0 version

[Ruben Van Boxem]

2015-07-27 8:54 GMT+02:00 Edward Diener eldlistmaili...@tropicsoft.com:

 On 7/24/2015 11:13 AM, Ruben Van Boxem wrote:
  2015-07-24 17:03 GMT+02:00 Edward Diener eldlistmaili...@tropicsoft.com
  mailto:eldlistmaili...@tropicsoft.com:
 
  On 7/24/2015 8:54 AM, Riot wrote:
   Where are you defining your template, in the header or the source?
 You
   may need to explicitly instantiate.
 
  The template is being defined in the YY.cpp source file.
 
 
  Could you send example files displaying the issue? It makes it easier to
  reproduce and debug the issue.

 Here are the files and the command lines. All files should be placed in
 the same source directory with a 'debug' sub-directory where everything
 will be built. You need to have the mingw-64 gcc-5.1 32-bit bin
 directory in your PATH and you need to be in the source directory when
 executing the commands. I am only concerned with problems linking and
 not with running the result.

 First the header and source file to be built into a shared library:

 Header file exception_cl.hpp

 #ifndef EXCEPTION_CL_HPP
 #define EXCEPTION_CL_HPP

 #include exception

 #if defined(BUILD_SL)
  #define CLASS_DECL __attribute__((__dllexport__))
 #else
 #define CLASS_DECL __attribute__((__dllimport__))
 #endif

 class __attribute__((__visibility__(default))) exception_cl :
  public virtual std::exception
 {
 private:
  char m_buffer[128];
 public:
  int code;

  CLASS_DECL exception_cl(int) ;
  virtual CLASS_DECL ~exception_cl() throw() ;
  virtual CLASS_DECL const char * what() const throw() ;
 };

 #endif // EXCEPTION_CL_HPP

 Source file exception_cl.cpp

 #define BUILD_SL
 #include exception_cl.hpp

 CLASS_DECL
 exception_cl::exception_cl(int i) :
  code(i)
 {
  m_buffer[0] = '\0';
 }

 CLASS_DECL
 exception_cl::~exception_cl() throw() {}

 CLASS_DECL const char *
 exception_cl::what( ) const throw() {
  return m_buffer;
 }

 The command for compiling the source file is:

 g++ -ftemplate-depth-128 -Wno-unused-local-typedefs
 -ftrack-macro-expansion=0 -O0 -fno-inline -Wall -g -march=i686 -m32
 -fvisibility-inlines-hidden -fvisibility=hidden -c -o
 .\debug\exception_cl.o exception_cl.cpp

 The command for linking the object file to a shared library called
 lib-excl-mgw51 is:

 g++ -Wl,--out-implib,.\debug\lib-excl-mgw51.dll.a -o
 .\debug\lib-excl-mgw51.dll -shared -Wl,--start-group
 .\debug\exception_cl.o  -Wl,-Bstatic  -Wl,-Bdynamic  -Wl,--end-group
 -g -march=i686 -m32

 These commands succeed without problems in creating the shared library
 and the import library in the 'debug' subdirectory.

 Now the source file to be built into an executable, which uses the
 exception_cl class from the shared library. I call the source file
 'throw_exception_cl.cpp':

 #include exception_cl.hpp
 templateclass E void throw_exception(E const  e) { throw e; }
 int main(int argc,char * argv[])
 {
 if (argc  1)
 {
 #if 1
  throw_exception(exception_cl(0));
 #else
 throw exception_cl(0);
 #endif
  }
 return 0;
 }

 The command for compiling the file is:

 g++  -ftemplate-depth-128 -Wno-unused-local-typedefs
 -ftrack-macro-expansion=0 -O0 -fno-inline -Wall -g -march=i686 -m32 -c
 -o .\debug\throw_exception_cl.o throw_exception_cl.cpp

 This command succeeds in creating the object file in the 'debug'
 subdirectory.

 Now the command to link the source file's object file into an executable:

 g++  -Wl,-R -Wl,.\debug -Wl,-rpath-link -Wl,.\debug -o
 .\debug\te.exe -Wl,--start-group .\debug\throw_exception_cl.o
 .\debug\lib-excl-mgw51.dll.a  -Wl,-Bstatic  -Wl,-Bdynamic
 -Wl,--end-group -g -march=i686 -m32

 This command fails with the messages:

 .\debug\throw_exception_cl.o: In function `ZN12exception_clC1ERKS_':

 C:\Programming\VersionControl\modular-boost\libs\serialization\src/exception_cl.hpp:12:
 undefined reference to `vtable for exception_cl'

 C:\Programming\VersionControl\modular-boost\libs\serialization\src/exception_cl.hpp:12:
 undefined reference to `vtable for exception_cl'
 collect2.exe: error: ld returned 1 exit status

 If in the source file immediately above, the #if 1 line is changed to
 if 0, the link command succeeds without error. But I need it to
 succeed as is.

 Please realize that this is all a much boiled down example of the actual
 problem that is occurring with mingw-64 gcc-5.1 32-bit compile, but it
 shows the problem itself that is occurring in the actual code. The
 problem also occurs in the other latest mingw-64 gcc-4.9.2 and 4.8.5 32
 bit releases.


This is exactly what is necessary to fix any problem: a smallest compilable
source code example that shows the problem. Thanks for this.

The issue is that you are (or GCC is) using an implicitly defined copy
constructor, which is not exported. There are two fixes:
1. Make the whole class CLASS_DECL, instead of each function separately
(and remove the visibility attribute which

Re: [Mingw-w64-public] Linker problem with i686-5.1.0-posix-dwarf-rt_v4-rev0 version

[Ruben Van Boxem]

2015-07-24 17:03 GMT+02:00 Edward Diener eldlistmaili...@tropicsoft.com:

 On 7/24/2015 8:54 AM, Riot wrote:
  Where are you defining your template, in the header or the source? You
  may need to explicitly instantiate.

 The template is being defined in the YY.cpp source file.


Could you send example files displaying the issue? It makes it easier to
reproduce and debug the issue.

Thanks,

Ruben



 
  On 24 Jul 2015 13:31, Edward Diener eldlistmaili...@tropicsoft.com
  mailto:eldlistmaili...@tropicsoft.com wrote:
 
  Before attempting to reduce my code to a small enough example to post
  here in its entirety I will give a description of the problem to see
 if
  anyone has encountered it in general. The problem is purely a linker
  problem.
 
  I have an exported class in a shared library, called it XX in header
  file XX.hpp. From an executable's source file, called it YY.cpp I
  include the class's header file where the class will show as imported
  and in the code in the source file I throw an exception with an
 instance
  of the class, as in:
 
throw XX(some_constructor_parameters);
 
  This compiles and links without error.
 
  If instead I use a template to throw an exception, such as:
 
templateclass E void throw_exception(E const  e) { throw e;
 }
 
  and then invoke it from my executable as:
 
throw_exception(XX(some_constructor_parameters));
 
  I receive a linker error of the form:
 
YY.o: In function `SomeDecoratedName':
XX.hpp:27: undefined reference to `vtable for XX'
XX.hpp:27: undefined reference to `vtable for XX'
 
  I realize that this is not a complete example but before reducing my
  code to the least possible example which will reproduce this problem
 I
  thought I would ask if anyone has encountered anything like it, or
 has
  any idea why using a template causes a linker error whereas not using
  the template links would link without any problems.




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

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

Re: [Mingw-w64-public] std::locale

[Ruben Van Boxem]

2015-07-01 12:15 GMT+02:00 p...@arbolone.ca:

 In this web page:
 http://en.cppreference.com/w/cpp/locale/toupper

 I got this code:
 #include iostream
 #include cwctype
 #include locale

 int main()
 {
 wchar_t c = L'\u017f'; // Latin small letter Long S ('ſ')
 std::cout  std::hex  std::showbase;
 std::cout  in the default locale, toupper(  (std::wint_t)c  )
 =
 
std::toupper(c, std::locale())  '\n';
 std::cout  in Unicode locale, toupper(  (std::wint_t)c  ) = 
std::toupper(c, std::locale(en_US.utf8))  '\n';
 }

 Which compiles like this:
 g++.exe -Wall -fexceptions -g -m64 -std=gnu++14 -D_UNICODE -D_WIN32
 -march=core2
  -pedantic -std=c++11 -m64 -std=gnu++14 -D_UNICODE -D_WIN32 -IC:\dev\jme -c
 C:\tmp\localetest01\main.cpp -o obj\Debug\main.o
 g++.exe  -o bin\Debug\localetest01.exe obj\Debug\main.o  -lwinmm -lwinmm
 Output file is bin\Debug\localetest01.exe with size 108.41 KB
 Process terminated with status 0 (0 minute(s), 0 second(s))
 0 error(s), 0 warning(s) (0 minute(s), 0 second(s))

 Then I get a popup box with this message
 ---
 localetest01.exe - System Error
 ---
 The program can't start because libgcc_s_seh-1.dll is missing from your
 computer. Try reinstalling the program to fix this problem.
 ---
 OK
 ---

 Which does not make sense since my compiler's exceptions are 'sjlj', go
 figure!
 I click OK, and then a cmd terminal comes saying:
 int he default locale. touppor(0x17f) = 0x17f
 terminate called after throwing an instance of 'std::runtime_error'
what(): locase::facet::_S_reate_c_locale name not valid


That's because the C++ std::locale objects use the C locale names, which
are different on Windows:
https://msdn.microsoft.com/en-us/library/dd373814.aspx
Locales are one of those things that lie in the implementation-defined
space of the library. The standard only mandates the presence of a C and
a default  locale. All the rest is up to the implementation.

Yes that page is convoluted and illegible. I strongly suggest you do not
rely on C++ locales and instead use a full blown unicode library such as
ICU:
see e.g. http://userguide.icu-project.org/transforms/casemappings

And please stop sending these emails to gcc-help. These are C++ on
Windows questions, which can often be answered by googling or searching
for similar issues on e.g. stackoverflow.com. gcc-help is for help with
GCC, the compilers.

If I can, I will still help you on mingw-w64-public though.

Ruben
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] no function forstd::ifstreamwchar_t::open(const wchar_t*)?

[Ruben Van Boxem]

2015-06-29 19:16 GMT+02:00 p...@arbolone.ca:

   The standard C++ has major, and I mean MAJOR draw-back!!
 It cannot handle any other stream format that ASCII. 1988 standards in
 2015? I cannot believe it!!
 I am sure that there are 3rd or 4th party libraries that can handle this
 issue, but than again, that is that... a 3rd || 4th party library.
 I am sure that the Win64 API has a way to handle this, if not, those guys
 at boost seem to be very smart and provably have solved the problem in a
 way that is portable.

 Thanks for the help Ruben.


Well, what you're saying isn't entirely true, although the C++ Standard
library is indeed somewhat archaic in some aspects.
Let me set all this straight:
1. C++ nor any standard algorithm/function/class/...  (except of course the
locale related things) has no idea about character encoding whatsoever.
This means that any C++ iostream or string (be it with char or wchar_t) can
handle unicode just fine; it just doesn't do anything for you. Which might
be the same as saying it doesn't handle it at all. Well, the standard
classes are certainly not useless for unicode (nor do they prevent you from
using them for this purpose). Just not very useful...
2. This missing function (open an ifstream with a Windows native wchar_t
pathname) is stupid for two reasons: a) Windows is stupid in not
implementing a UTF-8 interface to its C and C++ standard library. All other
(modern) OSes work just fine with the 8-bit char and UTF-8. And b) C++ is
stupid in not making things easier. Work is being done in the form of the
Filesystem library that has been implemented in Boost (mostly like the
proposal) and the most recent Visual Studio 2015 (VS2013 has Filesystem v2,
which is slightly different).
3. There is no such thing as the Win64 API. It's still the Win32 API. And
yes, these C-style functions can handle all of this just fine, if you use
the proper encodings yourself. (small footnote: a valid Win32 filename is
not per se a valid UTF-16 string, but the reverse is true. And as far as I
know, the Unicode normalization isn't specified, so it's a can of worms any
way you want to put it)
4. Boost indeed has the aforementioned Filesystem library, which gives you
an interface to interact with files and filenames in a portable way.
5. There are only 3rd party (not even Boost) Unicode solutions. Make sure
you really need this before going into this. Full Unicode correctness is
expensive and hard.
6. wchar_t does not solve the unicode problem. It has the exact same
drawbacks UTF-8 has. UTF-32 has most of those drawbacks as well. Unicode is
hard.

Yes C++ sucks. You haven't even seen half of it. It is also quite good at
doing things you didn't know it could do.
Enjoy learning it, think about platform compatibility before you start
writing code.
Compile with several compilers.
st don't mind MSVC too much, it tends to not get C++ well, although the
newest versions are significant improvements with each step.

Cheers,

Ruben


  *From:* p...@arbolone.ca
 *Sent:* Monday, June 29, 2015 5:20 AM
 *To:* mingw-w64-public@lists.sourceforge.net
 *Subject:* [Mingw-w64-public] no function
 forstd::ifstreamwchar_t::open(const wchar_t*)?

   Nice, thank you, I took your advice. I have now modify the code. I have
 other problems, though.
 This code:
 *std::wifstream infile;*
 *infile.open( getFileName().c_str() );*

 error: no matching function for call to
 'std::basic_ifstreamwchar_t::open(const wchar_t*)'


 I found this discussion

 http://stackoverflow.com/questions/821873/how-to-open-an-stdfstream-ofstream-or-ifstream-with-a-unicode-filename

 It is a bit old, but I think it's still concurrent with today's reality
 and although the answers are very much correct I am left with the same
 question as the OP - are there no any options if MinGw compiler is used?


 I have changed the subject of this email to better reflect my predicament

  *From:* Ruben Van Boxem vanboxem.ru...@gmail.com
 *Sent:* Monday, June 29, 2015 4:10 AM
 *To:* mingw-w64-public@lists.sourceforge.net
 *Subject:* Re: [Mingw-w64-public] throw(...) in MinGW

   2015-06-29 9:54 GMT+02:00 p...@arbolone.ca:

   Thanks Ruben for the help.
 To answer your question, yes, I am.
 I was also using -std=gnu++14. However, I am now compiling only with
 –std::c++11, but to no avail. [image: Sad smile]


 This is a microsoft extension, as Clang informs us:
 http://coliru.stacked-crooked.com/a/49f77148f1e54ba7

 There is probably no way to convert this, other than to just remove it.
 Reading the Microsoft documentation
 https://msdn.microsoft.com/en-us/library/vstudio/wfa0edys.aspx, it
 seems all this construct does is inform the compiler the function in
 question can throw an exception.
 That sounds quite useless to me IMHO.
 Just remove it, or ifdef a THROWS macro or some such.

 Cheers,

 Ruben



  *From:* Ruben Van Boxem vanboxem.ru...@gmail.com
 *Sent:* Monday, June 29, 2015 2:27 AM
 *To:* mingw-w64-public@lists.sourceforge.net
 *Subject:* Re: [Mingw

Re: [Mingw-w64-public] Include and lib search paths for mingw-64

[Ruben Van Boxem]

2015-06-23 2:17 GMT+02:00 Óscar Fuentes o...@wanadoo.es:


 So moving cc1plus.exe to `bin' makes the toolchain self contained, but
 it is no solution as soon as you try to execute the programs you created
 with that toolchain.




Let me just jump in here and add an extra data point to the discussion: I
had a user once ask me about Eclipse and my toolchains, where Eclipse was
calling the compiler with a fully qualified path and didn't add th
toolchain directory to PATH. To solve this, I built the toolchain with
-static, as to make sure all compiler executables were self-contained. To
do this, I added LDFLAGS=-static to GCC configure. This worked great.

I cannot seem to find this flag in MinGW-builds' scripts though. Perhaps it
is worth adding to solve this issue in a graceful way.

Ruben
--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical  virtual servers, alerts via email  sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Include and lib search paths for mingw-64

[Ruben Van Boxem]

2015-06-23 9:31 GMT+02:00 Alexpux alex...@gmail.com:


 23 июня 2015 г., в 10:22, Ruben Van Boxem vanboxem.ru...@gmail.com
 написал(а):



 2015-06-23 2:17 GMT+02:00 Óscar Fuentes o...@wanadoo.es:


 So moving cc1plus.exe to `bin' makes the toolchain self contained, but
 it is no solution as soon as you try to execute the programs you created
 with that toolchain.




 Let me just jump in here and add an extra data point to the discussion: I
 had a user once ask me about Eclipse and my toolchains, where Eclipse was
 calling the compiler with a fully qualified path and didn't add th
 toolchain directory to PATH. To solve this, I built the toolchain with
 -static, as to make sure all compiler executables were self-contained. To
 do this, I added LDFLAGS=-static to GCC configure. This worked great.

 I cannot seem to find this flag in MinGW-builds' scripts though. Perhaps
 it is worth adding to solve this issue in a graceful way.


 I’m not build GCC using ming-builds scripts for a year, but as I remember
 this option can build static GCC:
 https://github.com/niXman/mingw-builds/blob/master/build#L64


That builds the GCC runtime statically, not the compiler executables:
https://github.com/niXman/mingw-builds/blob/develop/library/config.sh#L80

There doesn't seem to be an option to add -static to GCC's LDFLAGS
currently.

Ruben
--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical  virtual servers, alerts via email  sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Opening unicode filenames with MinGW-w64

[Ruben Van Boxem]

Op 22-jun.-2015 19:48 schreef LRN lrn1...@gmail.com:

 On 22.06.2015 19:09, Etienne Sandré-Chardonnal wrote:
  On 2015-06-22 17:21 GMT+02:00 LRN wrote:
  On 22.06.2015 17:25, Etienne Sandré-Chardonnal wrote:
  Hi,
 
  Without eof, it still returns 262 bytes which is wrong.
  That's a very arbitrary number. Is the file opened in binary mode?
Anything
  significant around the 262th byte in the file contents?
 
  No, that's a zlib compressed binary.
 
  Starting from offset 0x100 (256):
  f7 ce 21 7c 5b b1 1a d7 a6 67 a2 55 e2 22 4e 88
 
  Byte 262 is 0x1a (26)

Can you send the file or a similar one that displays the issue?

Ruben


 Sorry, i've got nothing.

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


--
 Monitor 25 network devices or servers for free with OpManager!
 OpManager is web-based network management software that monitors
 network devices and physical  virtual servers, alerts via email  sms
 for fault. Monitor 25 devices for free with no restriction. Download now
 http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical  virtual servers, alerts via email  sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Opening unicode filenames with MinGW-w64

[Ruben Van Boxem]

2015-06-22 13:21 GMT+02:00 Etienne Sandré-Chardonnal etienne.san...@m4x.org
:

 Hi,

 I have tried to open the file with _wfopen(), pass it to  __gnu_cxx::
 stdio_filebufchar, and set it as the buffer of an std::istream.
 The file is open properly, first bytes are OK, but after 263 read bytes I
 get an eof(), while the file is 39MB large.

 Reading works well with a standard std::ifstream and a non-unicode file
 name, and I am testing the simplest way possible:

   int i = 0;

   while(!stream.eof())

   {

   char a;

   stream.read(a, 1);

   i++;

   }

   info(%d,i);


 If nobody has an idea, I will give up for a Qt-based solution but I was 
 hoping making a source code that would compile without any external library 
 (with some preprocessing for detecting the Windows case)


That is not the right way to read from a C++ istream. Do something like
this:

std::size_t i = 0;
char a;
while(stream.read(a, 1))
{
  ++i;
}
info(%d, i);

I.e. put the read action in the condition of the loop. Checking eof doesn't
get you what you want, see here:
http://stackoverflow.com/questions/5605125/why-is-iostreameof-inside-a-loop-condition-considered-wrong

Also, if you're using Qt anyways, it is indeed much preferred to use its
I/O system, so that you don't rely on a libstdc++ extension.

Cheers,

Ruben
--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical  virtual servers, alerts via email  sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] finding the data file

[Ruben Van Boxem]

2015-06-19 0:32 GMT+02:00 Jose Alf. jose...@rocketmail.com:

 You can get rid of the environment variable using a win32 api call as
 explained here:


 http://stackoverflow.com/questions/2647429/c-windows-path-to-the-folder-where-the-executable-is-located



   On Thursday, June 18, 2015 4:45 PM, Hotmail (ArbolOne) 
 arbol...@hotmail.ca wrote:


 I found the solution, the answer to my problem is
 getenv(ARBOLONE)


If this is a necessary application sound, it should really be included as a
resource (unless you know, cross-platformness makes that awkward).
If it is something a user needs to pass in, you might want to opt for this
being a commandline argument to your application.

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

Re: [Mingw-w64-public] Opening unicode filenames with MinGW-w64

[Ruben Van Boxem]

2015-06-19 16:45 GMT+02:00 Etienne Sandré-Chardonnal etienne.san...@m4x.org
:

 Dear all

 I have found this old gcc discussion from Ruben :
 http://gcc.gnu.org/ml/libstdc++/2011-06/msg00066.html

 Is this available in recent mingw releases? I cannot find any of these
 extensions in 4.9.2 headers (and it does not work)


No, unfortunately, it is not. You must manually work around this
shortcoming by e.g. using the libstdc++ extension:
https://gcc.gnu.org/onlinedocs/libstdc++/manual/ext_io.html
Note that proper memory management is kind of tricky (you need to take care
of the file descriptor or FILE* yourself)

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

Re: [Mingw-w64-public] Opening unicode filenames with MinGW-w64

[Ruben Van Boxem]

2015-06-19 16:56 GMT+02:00 Ruben Van Boxem vanboxem.ru...@gmail.com:

 2015-06-19 16:45 GMT+02:00 Etienne Sandré-Chardonnal 
 etienne.san...@m4x.org:

 Dear all

 I have found this old gcc discussion from Ruben :
 http://gcc.gnu.org/ml/libstdc++/2011-06/msg00066.html

 Is this available in recent mingw releases? I cannot find any of these
 extensions in 4.9.2 headers (and it does not work)


 No, unfortunately, it is not. You must manually work around this
 shortcoming by e.g. using the libstdc++ extension:
 https://gcc.gnu.org/onlinedocs/libstdc++/manual/ext_io.html
 Note that proper memory management is kind of tricky (you need to take
 care of the file descriptor or FILE* yourself)


Correction: onl the FILE* if you use that constructor. File descriptors are
handled by the stdio_filebuf destructor.
See: https://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a00070.html


 Ruben

--
___
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-64 and MSVC x64 ABI

[Ruben Van Boxem]

2015-06-17 18:21 GMT+02:00 lh_mouse lh_mo...@126.com:

 g++ and clang++ use Itanium ABI while MSVC uses some M$ specific,
 unpublished ABI. Hence it is not surprising that they are incompatible with
 each other.


Clang actually aspires to use MSVC's ABI on Windows, and they're close, if
not already in a useful state right now.

Ruben
--
___
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-64 and MSVC x64 ABI

[Ruben Van Boxem]

2015-06-17 17:44 GMT+02:00 Etienne Sandré-Chardonnal etienne.san...@m4x.org
:

 Dear all,

 I have a plugin system in my app based on interfaces (classes with only
 pure virtual functions). The app is compiled with mingw-w64 4.9.2 and works
 well with plugin dlls compiled with the same compiler.

 Now I am trying to support MSVC compiled plugins.

 This works partially : the app can call the methods from interface objects
 provided by the DLL. However, if I pass a pointer on an interface class to
 one of the DLL methods, it does a segmentation fault.

 After debugging, I have seen this:

 *A is a pointer to an object deriving from InterfaceA , and created by the
 app.
 *B is a pointer to an object deriving from InterfaceB, and created by the
 dll

 From the app, I call B-someMethod(A);
 and someMethod calls A-someOtherMethod()

 When I debug inside someOtherMethod (which is an app side method), this
 should point on *A, but it points on *B. Which causes the segmentation
 fault afterwards.

 Can this be an ABI issue?


This is most likely an ABI issue yes, because you are relying on the binary
interface of the app and dll to be the same (i.e. the objects are assumed
to have the same memory layout and alignment and padding and whatnot).
Unfortunately, different compilers generate different class layout and
contents (think vptr) so they can be incompatible.

A way to solve this is to have only a C-style interface (no class types as
parameters) and have the plugin handle all the class creation and memory
management so that the user code only sees an opaque pointer (void*) to
something the plugin created and manages the memory for. This requires
quite some changes in the code most likely, but I don't know of another way
to work around this incompatibility.

Maybe someone else here has another idea :)

Cheers,

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

Re: [Mingw-w64-public] About the recent sourceforge events

[Ruben Van Boxem]

2015-06-10 23:24 GMT+02:00 Adrien Nader adr...@notk.org:

 My initial notes for possible other service providers:

 http://librelist.com/ for mailing-lists
 - activity status unknown (not asked)
 - dispute resolution process unknown (not asked)
 - only mailing-lists

 http://www.tuxfamily.org/en/about for everything but bug tracker; but
   bug tracker software can be installed without trouble
 - not terribly active but definitely maintained
 - admins are known and are free software activists, makes it possible to
   take over in case some more admin is needed

 http://github.com for code hosting, web pages hosting (not binaries),
   light bug tracker, not mailing-lists nor forums
 - possible network effect (although I have some doubts considering the
   difficulty of most tasks)
 - hosting of large binaries is not guaranteed at all
 - hosting of binaries is couple to actual releases

 https://notabug.org/ only code hosting?
 - the gogs software is fairly new and doesn't have all features
   needed as far as I know

 http://codingteam.net everything but forum and mailing-lists
 - has a fairly nice look
 - the website warns that their current resources are not enough for
   livecd-style downloads and it's probably the same with large binaries
   that are currently in the file release system

 http://savannah.nongnu.org or http://gna.org everything but forums
 - mailing-lists!
 - well-known
 - need to check the current mingw-w64 usage of file downloads matches
   well
 - need to check how much graphical communication can be done on the
   project page (remember there is already a website to serve as
   frontend)


Here's another two to add to the list:
http://www.codeplex.com/ (see http://www.codeplex.com/)
 - mailing lists
 - source code
 - downloads
 - issue tracker
 - wiki
 - continuous integration
bitbucket.org
 - might be limited to 5 users collaborating on a project
 - source code,
 - downloads,
 - issue tracker
 - wiki
 - no mailing lists
and of course the always available option:
Private server/hosting
 - costs money
 - needs someone maintaining the guts
 - can do everything at once
 - can it handle the load?

I think it is a good idea to at least have project names taken on the large
hosting sites (codeplex, github, savannah) so that the name is not taken by
anyone else. The project can then link to the main site and mirror the git
repository.

If Sourceforge continues its actions like this, MinGW-w64 needs to keep its
options open. No action is required now, but at least opening some doors
never hurts, and reserving a project name with other hosting sites only
spreads MinGW-w64 availability and fame.

Cheers,

Ruben


 --
 Adrien Nader


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

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

Re: [Mingw-w64-public] Set a larger pch file size limit? was : can anyone supply a debug version of cc1plus.exe?

[Ruben Van Boxem]

2015-06-02 7:26 GMT+02:00 asmwarrior asmwarr...@gmail.com:

 On 2015-5-31 16:22, asmwarrior wrote:
  On 2015-5-23 9:39, asmwarrior wrote:
  I just want to hunt the GCC bug: (big pch file will crash cc1plus.exe)
  56926 – Crash (without ICE) while compiling Boost.Math -
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926
 
  It turns out that build the GCC and G++ myself is too complex for me,
 so I would like to see if someone can supply a debug version of tool chain,
 so that I can run them under gdb to see where it crashed.
 
  BTW: I see that the latest LD can have separate debug file generated,
 so maybe, we can use it.
 
  Thanks.
 
  Hi, with Kai's suggestion: https://sourceforge.net/p/mingw-w64/bugs/382/
  I guess that the hard limit value is 128M, and I would suggest a larger
 value for this variable. See here:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926#c16
  Any one would like to try a new build of gcc?
 
  There are some similar related discussion, see:
  1, mingw - cc1plus.exe crash when using large precompiled header file
 
 http://stackoverflow.com/questions/10841306/cc1plus-exe-crash-when-using-large-precompiled-header-file
  2, MinGW-w64 - for 32 and 64 bit Windows / Mailing Lists
  https://sourceforge.net/p/mingw-w64/mailman/message/30846624/
 
  Thanks.
 

 Hi, good news, since I don't see any one rebuild a gcc chain by a larger
 pch_VA_max_size value recently.
 Today, I do it myself by modify the cc1plus.exe in a binary editor, just
 changed the values in the three referenced instructions.
 I changed the value from 128M to 512M.
 See details here:
 Comment 17 - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926#c17
 Now, the modified cc1plus.exe never crash with a 200M pch file.
 So, the crash issue can to solved now!!!


This is great news. I'm just (greatly) curious as to why a magic number is
necessary here at all. Fixed size buffers are so 80's!

Let's hope the fix is commited soon!

Ruben



 asmwarrior



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

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

Re: [Mingw-w64-public] Multiple definition issue with -flto, MinGW-w64 4.9.1

[Ruben Van Boxem]

2015-05-29 13:36 GMT+02:00 Riot rain.back...@gmail.com:

 I have to disagree. I use lto in large production builds with great
 success. My use case is performance critical (games) and I build with
 -Ofast as well as lto and other heavy optimisations without problems,
 generating executable binaries of over a hundred megabytes in size when
 stripped and consisting of hundreds of translation units.

 Prior to 4.8 lto was incomplete and problematic but most bugs seem to have
 been eradicated by gcc 5.0.


Interesting, because lto, even on Linux, causes quite some grievances up to
te point distributions are refusing to enable it for their packages by
default.

Would you have any performance numbers (and I guess file sizes) comparing
lto vs no-lto builds (all the other options remaining unchanged of course)?
It'd be very interesting to see how lto actually changes things.

Thanks!

Ruben

 In my experience RTTI problems are more likely related to linking objects
 that were built with a different version of gcc using lto. Try rebuilding
 all your libraries and any linked objects with the same gcc version and
 settings. It may also be worth it to try static linking.

 Riot
 On 29 May 2015 12:21, Etienne Sandré-Chardonnal etienne.san...@m4x.org
 wrote:

 That's difficult to know, since the debugger seems to miss some
 information.
 The current function where the crash occurs is unknown :?? in the level 1
 stack view
 For levels 2,3 and 4 I have the function name, but I have no access to
 the location in the code.
 Only level 5 of the stack is fully working in the debugger (all symbols +
 location in code)

 Level 2 is an default assignment operator of my ImageBuffer class. The
 class only contains basic types and std:: containers, no user defined
 pointers, so it likely crashes when copying one of the containers.

 The -flto is clearly not fully usable yet. I was trying it to see if it
 increases performance in a speed-critical app, which has a complex code and
 a lot of function calls between non-virtual classes. This seemed to be a
 good candidate for LTO.

 What did your debugger say? Was the segfault caused by dereferencing a 
 pointer returned by a failed dynamic_cast?

 To my knowledge flto has never been working perfectly since g++ 4.8 on 
 Windows: multiple definitions, undefined references, pointer-to-function 
 referring garbage memory, valid pointers becoming null, random segment 
 faults, etc...
 I strongly suggest you not use flto in production builds.


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

Re: [Mingw-w64-public] Contributing a package

[Ruben Van Boxem]

2015-05-26 9:05 GMT+02:00 Pavel Fedin p.fe...@samsung.com:

  Hi!

  What is your sourceforge ID?

  It's sonic_amiga. And it's still operational, to my great surprise :)


IMHO, no project is too small for a separate project page and repository.
And I don't see how this could ever belong inside the mingw-w64 project,
honestly, as it is not related to the Windows runtime in any way (unless
I'm missing something, which is very well possible).

If you find Sourceforge too daunting, there's also the now more popular
platform github, and numerous other alternatives where you can dump your
source code. I believe that github will give it the greatest visibility
though in the current open source world of hosting new projects.

See also the MSYS2 packages for libvirt and portablexdr which you may
consider contributing the changes to:
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-libvirt
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-portablexdr

Cheers,

Ruben


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




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

--
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] Contributing a package

[Ruben Van Boxem]

2015-05-26 10:57 GMT+02:00 Pavel Fedin p.fe...@samsung.com:

  Hello!

  IMHO, no project is too small for a separate project page and
 repository. And I don't see how this could ever belong inside the mingw-w64
 project, honestly, as it is not related to the Windows runtime in any way
 (unless I'm missing something, which is very well possible).

  Is mingw-w64 strictly limited to compiler and runtime only? I thought
 it's not, i've seen some ported packages in External binary packages and
 3rd party development tools. I thought portablexdr would perfectly fit
 there.


It has some useful additions in the area of tooling and low-level toolchain
libraries. Plus winpthreads, which is required for features of GCC and its
runtime libraries to function correctly.

The External binary packages was a haphazard attempt to set up something
like a package repository. It's a historical artifact and should be
removed. If anything, it has been completely superceded by the MSYS2
mingw-packages effort. That being said, all the packages there have their
source code available in a proper separate place, not anywhere near the
mingw-w64 source tree.


  If you find Sourceforge too daunting, there's also the now more popular
 platform github, and numerous other alternatives where you can dump your
 source code. I believe that github will give it the greatest visibility
 though in the current open source world of hosting new projects.

  No, i don't. I would not like to set up a separate project only because
 the actual scope of portablexdr improvement is limited. There will be some
 bug fixes and code upgrades to fix warnings, but that's all. After this it
 will be frozen.


Hiding it in some other (mainly unrelated) project where it is not
distributed by default and can rot isn't any better. I have no say in
accepting the code or not, it just seems out of scope for a project
enabling GCC on Windows.


  See also the MSYS2 packages for libvirt and portablexdr which you may
 consider contributing the changes to:
  https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-libvirt
 
 https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-portablexdr

  Ok, i can check with Alex about that. I just thought that gathering the
 complete set of various tools and useful packages (like MinGW32 and Cygwin
 projects do) is a good idea.


That's exactly what the MSYS2 project does. Mingw-w64 itself currently does
not do this, and for a long time, didn't even provide official builds.
Now of course there are official builds, but the 3rd party libraries
repository has been picked up by MSYS2 and the Linux distributions which
provide cross-compilers themselves.

But this is all just my 2 cents.

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

Re: [Mingw-w64-public] Universal CRT and Python support

[Ruben Van Boxem]

2015-05-19 9:22 GMT+02:00 Alexpux alex...@gmail.com:


 19 мая 2015 г., в 10:09, Ruben Van Boxem vanboxem.ru...@gmail.com
 написал(а):

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

 Hi, Ruben!

 I’m always backport patches for Python 2/3 from MSYS2 to mingw-builds
 toolchains.
 From my point of view our Python patches will work with most mingw-w64
 toolchains without changes.


Hi Alexey!

How applicable are these patches to upstream Python? Would they break MSVC
compatibility or do you think these can be merged quite cleanly?

I've posted a quick write-up reply to his understanding of the GCC on
Windows situation:
http://bugs.python.org/issue4709?@template=item#msg243563

Let's hope this boost of momentum can be maintained :)

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

[Mingw-w64-public] Universal CRT and Python support

[Ruben Van Boxem]

Hi guys,

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

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

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

Cheers,

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

Re: [Mingw-w64-public] Universal CRT and Python support

[Ruben Van Boxem]

Now without zip...

015-05-19 10:17 GMT+02:00 Ruben Van Boxem vanboxem.ru...@gmail.com:

 2015-05-19 10:03 GMT+02:00 LRN lrn1...@gmail.com:

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

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


 Yes, that seems to be indeed the case, plus it will be available on older
 OS versions through Windows update:

 http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx

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

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

 /ImustbeonsomethingI'llgotakeawalknow

 Cheers,

 Ruben



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


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





x64_msvcrt.def
Description: Binary data


x64_ucrtbase.def
Description: Binary data


x86_msvcrt.def
Description: Binary data


x86_ucrtbase.def
Description: Binary data
--
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] fork: can't reserve memory for stack 0xA0000 - 0x2A0000, Win32

[Ruben Van Boxem]

2015-05-08 2:19 GMT+02:00 James Franco mjfranc...@gmail.com:

 Just FYI after i hit continue the installation does go on.

 On Thu, May 7, 2015 at 5:11 PM, David Macek david.mace...@gmail.com
 wrote:

 On 7. 5. 2015 22:03, James Franco wrote:
  When I attempt to install Msys2 from the download link you suggested
  http://sourceforge.net/projects/msys2/?source=directory
 
  I get the error message
 
  The program cant start because MSVCR90.dll is missing from your
 computer. Try reinstalling the program to fix this problem
 
  After pressing ok i am prompted to the installation menu. Is this
 something that I should be concerned about ?

 I wonder what program is that. Nothing in MSYS2 should depend on
 msvcr90.dll and I can't think of a good hypothesis why the installer would
 start any program that does depend on msvcr90.dll.


My guess? Some antivirus program or something that tries to start up, and
fails due to a missing DLL. Might want to check that.

Ruben



 --
 David Macek



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




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


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

[Mingw-w64-public] repository.txt not found

[Ruben Van Boxem]

Guys,

this issue is popping up from time to time. I can understand it might be
hard to solve, but this is not good advertising for the project:

http://stackoverflow.com/questions/30069830/how-to-install-mingw-w64-and-msys2

Maybe storing the repository.txt in some other location might be a
workaround...

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

Re: [Mingw-w64-public] cc1plus.exe with SHIFS-JIS encoding

[Ruben Van Boxem]

2015-04-23 23:07 GMT+02:00 James Franco mjfranc...@gmail.com:

 Are there any known issues of cc1plus.exe crashing with shift-jis.
 Apparent I have a code base that  uses shift-jis (japanese) encoding in
 some source files and cc1plus.exe was crashing. After converting the
 encoding to ascii cc1plus is not crashing. Is there a known issues of
 cc1plus.exe crashing with shift-jis encoding?


Can you reproduce on other platforms (e.g. Linux)? If so, it's worth
reporting upstream, otherwise it might be a limitation of your GCC build.
Could you try and see if other MinGW-w64 builds (like TDM, MinGW-builds,
MSYS2, winbuilds, maybe even my old rubenvb builds :P...) show this issue?

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

Re: [Mingw-w64-public] Is there a way to figure out why - cc1plus.exe has stopped working

[Ruben Van Boxem]

2015-04-14 19:13 GMT+02:00 James Franco mjfranc...@gmail.com:

 I am attempting to port a project from Visual Studio to Mingw 64 bit GCC.
 During the port when I attempt to build a certain component using Mingw g++
 through CodeBlocks I get the error
 cc1plus.exe has stopped working. Is there a way for me to figure out
 what might be the cause of this crash ? Could it be a certain flag ? or
 something else ? The details of My Mingw64 are as follows

 c:\mingw64\bingcc --version
 gcc (x86_64-win32-seh-rev3, Built by MinGW-W64 project) 4.8.2
 Copyright (C) 2013 Free Software Foundation, Inc.
 This is free software; see the source for copying conditions.  There is NO
 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 Any suggestions are welcome.


Could you provide the source file that triggers the crash together with the
compiler invocation?

Does the crash also happen with GCC 4.9 and/or 4.7, if it will compile your
code at all?

Cheers,

Ruben
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [ANN] Website changes

[Ruben Van Boxem]

2015-03-24 21:20 GMT+01:00 Adrien Nader adr...@notk.org:

 Hi,

 On Tue, Mar 24, 2015, David Macek wrote:
  On 20. 3. 2015 22:51, Adrien Nader wrote:
   Hi,
  
   I've just pushed a redirect from http://mingw-w64.sourceforge.net to
   http://mingw-w64.yaxm.org in order to serve a new website.
  
   [snip]
  
   Any constructive criticism is welcome; don't hesitate.
 
  Hi. I took a look on the website and I've got some notes which may or
 may not be applicable to other visitors:
 
  === Downloads/Others:
 
  The first paragraph in the tab talks about OS X builds straight away, as
 if Others == OSX. This also led to an impression that Rubenv's builds are
 also for OS X. Also most of the contents of the tab seems to belong to
 other tabs. I imagine that if a visitor was interested only in toolchains
 for Windows, he/she could be led to believe that the three options in the
 first tab were the only one, because he/she would never even look at the
 Others tab and discovered the link to SF.net file repository.
 
  The following organisation would make more sense to me: I propose 1)
 moving Rubenv's builds to the Windows tab, moving the mention of OpenSUSE
 to the Linux tab, 3) copying the link to SF.net to all relevant tabs (or
 completely outside of them), and 4) renaming the tab from Other to OS X. I
 don't think moving these mentions from the Others tab to the other tabs
 will confuse users as to which one to download, as the gray boxes with
 logos serve well to make their contents seem as more trust-worthy than the
 plain text around.

 The Others tab has not received much love and that dates back to the
 creation of the download page on the previous website.
 When I put rubenvb and opensuse toolchains back when I created the
 download page (it's been some time already), the reactions I had
 received from both upstreams were at best meh and without many more
 details so I couldn't do a lot. I really wanted to put them somewhere
 though (I think Opensuse's effort started at least 7 years ago and
 rubenvb toolchains were widespread). Ideally they'd be in a proper
 place: the others section would ideally only contain the link to
 Sourceforge's FRS. That requires the corresponding toolchain creator to
 provide information about their releases.


I think I sent you an email with the required info as you asked for way
back when. If I didn't, my fault, but I'm not too worried about my
toolchains. They are dated now and should really be retired from the
download page.


 Following Vincent Torri's mail, I did some changes this morning and I
 just noticed I had not done these changes for every block but only for
 the ones that fell under Windows and Linux tabs. I've now corrected it.
 Basically I've removed title elements and added blue-colored blocks
 instead. They should make it easier to tell each block apart. Can you
 check the page again and tell me if it looks better?

 Also, the OS X situation currently is not very good as there is
 toolchain provider and the toolchains that are available are old,
 experimental and unsupported. I'm not worrying about it at the moment
 since it should change soon (more on that later on).

  === Downloads/Source:
 
  This may be just my profession talking, but links to various stuff on
 SF.net with SourceForge as the title seem misleading.
 
  === Downloads/Linux:
 
  I know Arch Linux users are generally competent, but I'd like to see the
 link point to something actually related to mingw-w64, rather than just to
 AUR homepage. This may be a good link: 
 https://aur.archlinux.org/packages/?SeB=nK=mingw-w64SB=cPP=250

 I'm not an Arch Linux user and the link in place was the only one I had.
 I've updated the page, thanks.

  Also, wouldn't it be better to also mention the packages in official
 Arch repos? https://www.archlinux.org/packages/?q=mingw-w64 They don't
 seem outdated or anything.

 I wasn't aware of these packages (maybe they're newer than the
 arch-linux-related update). I'm not sure how they relate to AUR ones;
 I'm under the impression the toolchain is in the base and non-toolchain
 packages should be built from AUR but I need a confirmation from at
 least one actual user.


I can confirm whatever you need: I made the original AUR packages, these
were absorbed into the binary [Community] repository, and they contain a
complete toolchain (c,c++,objc,obj-c++,fortran,ada) with the latest
released versions and is updated regularly. Development versions naturally
belong in the AUR for which everything is built from source on install. The
[Community] packages are those you want to link to on the MinGW-w64
download page. I'd suggest installing the mingw-w64-gcc package, which
should pull everything else in as a dependency.

Additionally, a couple of users have done the work to provide a bunch of
libraries in the AUR (which are built from source on install). Someone
(ant32 and some other guy) even provides binaries in a binary user
repository:

Re: [Mingw-w64-public] x64 MSVC import librries

[Ruben Van Boxem]

2015-03-18 16:28 GMT+01:00 Derek Buitenhuis derek.buitenh...@gmail.com:

 On 3/17/2015 11:27 PM, Vadim Chugunov wrote:
  I think I am bumping into the issue described here:
 https://sourceware.org/bugzilla/show_bug.cgi?id=16598.  The bug also has
 a patch attached.  What would it take to get someone to merge it?

 This is a patch to binutils, and not MinGW, and thus this is the wrong
 mailing list to ask on.


Not quite, some of the devs working on the MinGW(-w64) side of binutils
read this list, and can help getting a fix like this pushed.

Ruben
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] 1MiB variable size limit in dongsheng daily gcc-5.0-win64_5.0.0-20141105

[Ruben Van Boxem]

2015-02-12 7:41 GMT+01:00 Jim Michaels jmich...@yahoo.com:

 1MiB variable size limit in dongsheng daily gcc-5.0-win64_5.0.0-20141105
 did this get fixed? for example the standard c++ string library.
 I need it much larger.
 one of the things I might do is put a whole file content into a string to
 process. I have plenty of RAM and Virtual Memory to work with.

 just out of curiosity, will mingw-w64 work with Virtual Memory?
 I seem to find that a lot of windows stuff won't use it in win7 (maybe
 that got fixed a while back).


Code or it didn't happen. Preferentially a Short, Self Contained, Correct
(Compilable), Example http://sscce.org/. Unfortunately, describing the
problem as you have is quite unhelpful in actually figuring out what you
are talking about.

Ruben
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] RFE: New stable release

[Ruben Van Boxem]

2015-01-03 20:44 GMT+01:00 Kai Tietz ktiet...@googlemail.com:

 Yeah, the issue about releasing something not really completing a
 feature is ... well ... feeling bad.  Nevertheless I admit that
 already a lot of changes went into master already, and it is obvious
 that our users are eager to get all this in an official released
 version.  Additionally it is getting latest with gcc 5.0 pretty
 mandatory to build it with current trunk version due its new '(n)ftw'
 feature.  So latest March/April we will need to release trunk IMO.
 But this raises some other questions we need to answer. What happens
 to the already existing open branches?  Do we plan do stop maintenance
 at some point for them? Who will tend new branch? Latest thing I
 remember is that JonY agreed to maintain 3.x.  So will he agree to do
 this also for upcoming 4.0?

 The idea of light release sounds interesting.  But what shall we make
 a release criteria then?  Time,  amount of commits, features,  gut
 feeling?


This isn't the first time, and probably won't be the last time that other
projects are in need of features in the master branch of MinGW-w64. Perhaps
it would be helpful to revise how new additions are made so that perhaps a
time-based release scheme can be made more feasible and not just feel bad
because some stuff isn't finished yet. This would allow for timely releases
of whatever features are finished at a certain point in time without
slowing development for maintenance.

It would all depend on how the developers handle this, but here's an idea:
 - keep master stable (even more than it is now), merging finished features
and bugfixes only.
 - create a staging branch which would contain all new features whenever a
feature developer feels his work is ready enough for tessting. This would
take the place of current master, which contains everything from stable to
unstable commits.
 - create true feature branches, which track either staging or master, and
develop each feature in here. Timely merges with staging will allow stuff
like upstream Fedora to keep testing the whole. When finished, a
feature-branch will merge with master, finalizing feature development.

In this scheme, master is dead-stable, and releases are only for
distributors to have some form of latest release. Heck, versioning could
take on a pure incremental scheme (see e.g. systemd), IMHO. I see no reason
why one would want to use an older version anyways. Most native toolchains
are based off of master currently!
The only issue I see right now with my suggestion is that staging and
master could diverge a bit, as the former contains a lot of other changes
not in master due to the different features. This will require quite some
discipline from the developers to keep each commit local to where it
belongs. But a normal staging branch which includes all changes isn't an
option, as that is the state of current master.

Just my 2 cents.

Ruben


 Kai

 2015-01-03 15:29 GMT+01:00 Jacek Caban ja...@codeweavers.com:
  On 01/02/15 14:47, Erik van Pienbroek wrote:
  It would definitely help us when mingw-w64 would do more frequent
  releases.
 
  We had a discussion about that in the past, but there was no follow-up.
  The problem that I can see with past releases that I've been involved in
  is that there was always a lot of development work just before the
  release. How about we do an experiment and do a 'light' stable release
  off the master branch, with no time nor feature pressure. Master branch
  is pretty stable at this point and contains enough changes to be worth
  giving it in hands of users. We could just branch at any point soon and
  release a beta. Depending on how feedback goes, we decide on when to do
  the final release, but we don't push to have any new development done
  for the release nor block development on master branch. This should be
  mostly straightforward.
 
  Jacek
 
 
 --
  Dive into the World of Parallel Programming! The Go Parallel Website,
  sponsored by Intel and developed in partnership with Slashdot Media, is
 your
  hub for all things parallel software development, from weekly thought
  leadership blogs to news, videos, case studies, tutorials and more. Take
 a
  look and join the conversation now. http://goparallel.sourceforge.net
  ___
  Mingw-w64-public mailing list
  Mingw-w64-public@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


 --
 Dive into the World of Parallel Programming! The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is
 your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take a
 look and join the conversation now. http://goparallel.sourceforge.net
 

Re: [Mingw-w64-public] DWORD_PTR implemented as long long unsigned int

[Ruben Van Boxem]

2014-12-16 9:56 GMT+01:00 Jim Michaels jmich...@yahoo.com:

 usually, any microsoft _PTR is a *, but DWORD_PTR is defined as long long
 unsigned int.
 winerrstr.cpp:83:24: error: invalid conversion from 'DWORD* {aka long
 unsigned int*}' to 'DWORD_PTR {aka long long unsigned int}' [-fpermissive]
 DWORD_PTR *dwpArray;
 dwpArray=(DWORD_PTR*)new DWORD_PTR[argc+1];


Please see this link for the definitions of all Windows types:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa383751.aspx

Ruben



 dongsheng daily 20141105
 -
 Jim Michaels
 jmich...@yahoo.com
 j...@renewalcomputerservices.com
 http:#x2F;#x2F;RenewalComputerServices.com
 http:#x2F;#x2F;JesusnJim.com (computer repair info, programming)



 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE

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


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/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] TDM-GCC 4.9.2 released

[Ruben Van Boxem]

2014-12-12 16:04 GMT+01:00 John E. / TDM tdra...@tdragon.net:

 On 12/12/2014 3:13 AM, Massimo Belgrano wrote:
  Nice see tdm reborn
  How many mingw version exist for windows ?
  wich are the differences?

 Too many to list for you here. I'll just stick with the ones you're
 likely to hear about on this mailing list:

 * MinGW-Builds, the official toolchains of the MinGW-w64 project.
 https://sourceforge.net/projects/mingw-w64/files/ (look for
 mingw-builds under Personal builds)

 * Win-builds, a distribution that includes a lot of available library
 packages.
 http://win-builds.org/

 * TDM-GCC, native Windows toolchains with extra patches that make GCC
 more Windows-friendly but in some cases incompatible with other
 distributions.
 http://tdm-gcc.tdragon.net/

 * MinGW, the original 32-bit-only project that MinGW-w64 forked from.
 http://www.mingw.org/

 Again, there are quite a few others out there as well, but you're not
 likely to hear about them on this list.


You forgot about MSYS2, of which the developers read this list as well.
It has an extensive repository linux-style of prebuilt binary packages,
which can easily be installed from a Unix shell commandline. I believe the
toolhchains are quite similar to the MinGW-Builds ones.

Ruben
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/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] MinGW LGPL licensed, header-only std::thread implementation

[Ruben Van Boxem]

Hi guys,

I'd like to draw your attention to a std::thread implementation written
without pthreads.

It seems quite lightweight, and almost too small to be fully compliant.

If it is at all useful or even completely/nearly bug-free, perhaps it would
be worth getting this into GCC/libstdc++ mainline, because well, it's not
that biig really. Not sure how a win32 specific code dump would pass by
libstdc++ people (they're very, very unfriendly to platform specific code
due to maintenance).

Anyways, here it is:
https://github.com/meganz/mingw-std-threads


Ruben
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/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] MSYS2 is violating the GPL again

[Ruben Van Boxem]

2014-12-08 19:32 GMT+01:00 Jim Michaels jmich...@yahoo.com:

 is this msys2 something that applies to mingw-w64? should I be using this
 instead of
 https://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/MSYS%20%2832-bit%29/
 ?


That is a ridiculously outdated all-in-one MSYS package from way back when.

You should really try MSYS2, it's a lot better in pretty much all aspects.

Ruben


 -
 Jim Michaels
 jmich...@yahoo.com
 j...@renewalcomputerservices.com
 http:#x2F;#x2F;RenewalComputerServices.com
 http:#x2F;#x2F;JesusnJim.com (computer repair info, programming)


   --
  *From:* Alexpux alex...@gmail.com
 *To:* mingw-w64-public@lists.sourceforge.net
 *Sent:* Monday, December 8, 2014 3:01 AM
 *Subject:* Re: [Mingw-w64-public] MSYS2 is violating the GPL again


 8 дек. 2014 г., в 13:48, Corinna Vinschen vinsc...@redhat.com
 написал(а):

 Hi,

 I just had a look on the MSYS2 pages at sourceforge.  It turned out that
 the Cygwin sources provided on sourceforge,


 http://sourceforge.net/projects/msys2/files/REPOS/MSYS2/Sources/msys2-runtime-2.0.15816.7257e97-1.src.tar.gz/download

 are very old, from 2014-02-02, while the latest binary packages, for
 instance


 http://sourceforge.net/projects/msys2/files/REPOS/MSYS2/x86_64/msys2-runtime-2.0.16430.e868fe8-1-x86_64.pkg.tar.xz/download

 corresponds to the latest Cygwin source code from 2014-12-06.

 The corresponding source repository at

 http://sourceforge.net/p/msys2/code/ci/master/tree/

 is even older, with the latest sources from late 2013.


 I’m use github as primary source for building packages:
 https://github.com/Alexpux/Cygwin/tree/Cygwin

 PKGBILD:

 https://github.com/Alexpux/MSYS2-packages/blob/master/msys2-runtime/PKGBUILD#L26

 Will update sf.net repo today.


 And this is only for Cygwin.  The situation of the other upstream
 packages isn't better.  About half of the binary packages are younger
 than 6 month, while the latest source archives have been updated
 2014-06-11.

 You're violating the GPL again in a pretty big style.  Yes, not all of
 the affected packages are GPLed, but a lot are.  What is so complicated
 to keep the sources up to date with the binary packages?


 I’m provide git repository with build scripts and patches that applies to
 sources:
 For mingw:
 https://github.com/Alexpux/MINGW-packages

 For msys2:
 https://github.com/Alexpux/MSYS2-packages

 Regards,
 Alexey.




 Please fix this ASAP.


 Corinna

 --
 Corinna Vinschen
 Cygwin Maintainer
 Red Hat




 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE

 http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk

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




 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE

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


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/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] TDM-GCC 4.9.2 released

[Ruben Van Boxem]

2014-12-09 14:24 GMT+01:00 John E. / TDM tdra...@tdragon.net:

 On 12/8/2014 11:29 PM, Greg Jung wrote:
  Hi John,
If you would indulge my questions, I am intrigued by the advice re:
  -fno-keep-inline-dllexport flag
  because it mentions wxWidgets which I am trying to incorporate into an
  already-large program.
  Do you know what problem it addresses, is it needed to unclutter a
  namespace?

 Hi Greg,

 GCC versions before 4.5 didn't emit class member functions into DLLs if
 they were declared with the inline keyword. This tended not to be a
 problem, because their full definition is available and inlinable to any
 user of the class. But as of 4.5 GCC was changed to match Microsoft
 Visual C/C++ behavior by also emitting said functions into the DLL.

 The more inline class member functions, the more memory it takes to link
 the DLL. wxWidgets grew big enough that when the 4.5 change came around,
 suddenly there were too many inline class member functions to fit in
 link-time memory, and the linker would fail.

 The -fno-keep-inline-dllexport option reverts to pre-4.5 behavior by
 not emitting inline class member functions into a DLL, allowing software
 like wxWidgets (monolithic) to link successfully. The only downsides to
 using it are that it breaks Microsoft compatibility (almost always not a
 problem with C++), and that you can't take the address in the DLL of one
 of said functions (which you shouldn't be doing anyway for inlines).


In my never-ending war on misconceptions regarding C++:
1. inline does not tell your compiler to inline. It is merely a hint and
the fact that some compilers take it as a serious hint is a coincidence.
Nothing in the C or C++ language says there is even the slightest
guarantee. The point of inline is to be able to write inline definitions of
functions, and respect the One Definition Rule. But you knew that already I
suppose ;-)
2. There is absolutely no problem in taking the address of an inline
function. It is very legal. See for example
http://stackoverflow.com/q/3318322/256138
3. I do believe this compiler option makes GCC behave in a non-standard
way, but I haven't checked that myself.

Nevertheless, since ld is too inefficient, this option was necessary to
make it work for stuff like wxWidgets (Qt also added the option to its
build).

Cheers,

Ruben


  Also regarding
  TDM, how many hooks into the windows registry does it maintain?  I
  un-installed a TDM from a previous system and was dismayed at what
  seemed like 2,000 entries in the registry wind-down - am I
  hallucinating that?

 You are. The TDM-GCC installer intentionally avoids the registry like
 the plague. All is done through file magic. :)

 -John E. / TDM


 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE

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

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/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] MSYS2 is violating the GPL again

[Ruben Van Boxem]

Hi Corinna,

With fear of my life I stick my head in a hornet's nest, with some remarks:

Archlinux solved this issue some years ago, and the bug report is cause for
an interesting read with some pointers on how to solve this for the MSYS2
folks: https://bugs.archlinux.org/task/5355
Any GPLv3 project does not need the source distributed, only a link
upstream should suffice (as long as it isn't taken offline by upstream of
course, so a better solution would be nice).
Cygwin is GPLv3, so that should be fine already, although technically, if
Cygwin people decide to take the hosting offline, MSYS2 would have a
problem. So that needs to be fixed for the sake of future disasters, not
curent infringement.

Anyways, just my 2 cents, and now I'm going to Run, Forrest Run the hell
out of here.

Ruben


2014-12-08 12:27 GMT+01:00 Corinna Vinschen vinsc...@redhat.com:

 On Dec  8 14:01, Alexpux wrote:
  Will update sf.net http://sf.net/ repo today.

 Ok.

   And this is only for Cygwin.  The situation of the other upstream
   packages isn't better.  About half of the binary packages are younger
   than 6 month, while the latest source archives have been updated
   2014-06-11.
  
   You're violating the GPL again in a pretty big style.  Yes, not all of
   the affected packages are GPLed, but a lot are.  What is so complicated
   to keep the sources up to date with the binary packages?
 
  I’m provide git repository with build scripts and patches that applies
 to sources:
  For mingw:
  https://github.com/Alexpux/MINGW-packages
 
  For msys2:
  https://github.com/Alexpux/MSYS2-packages 
 https://github.com/Alexpux/MSYS2-packages

 In how far does that alleviate the problem of the GPL breach?


 Corinna

 --
 Corinna Vinschen
 Cygwin Maintainer
 Red Hat


 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE

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


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/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] i686-w64-mingw32-gcc-4.9 and -static-libgcc not working as advertise

[Ruben Van Boxem]

2014-11-26 13:04 GMT+01:00 Erik de Castro Lopo mle+...@mega-nerd.com:

 jose...@rocketmail.com wrote:

 
  Did you try adding just -static to the link command?

 Just now. With -static it makes everything static, including the
 library I'm trying to build as a DLL.


That's because you typically link DLLs to DLLs and not to static libraries.
This is a Bad Idea™, but try something like -Wl,-Bstatic -lgcc -lgcc_eh
-Wl,-Bdnamic, which is what options like -static-libgcc will do. Note that
this may result in double defintion errors for libgcc symbols due to any
linking to this DLL will also pull in libgcc_s which conflicts with
libgcc_eh if I'm not mistaken. As expected, and also why this is a bad idea.

Ruben



 Erik
 --
 --
 Erik de Castro Lopo
 http://www.mega-nerd.com/


 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE

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

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/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] getpid issue

[Ruben Van Boxem]

2014-11-07 9:25 GMT+01:00 Ozkan Sezer seze...@gmail.com:

 On 11/7/14, Dongsheng Song dongsheng.s...@gmail.com wrote:
  If we define _POSIX_, then getpid (process.h) was hidden.
  Is it correct ?
 
  PS: MSVC 2012 is the last compiler which use _POSIX_, MSVC 2013 do not
  use _POSIX_ anymore.
  MSVC 2012/2013 guard getpid with !__STDC__.

 I believe (but not necessarily correct about iıt) that MSVC's _POSIX
 symbol is intended for diffrerent purposes, i.e. windows posix subsystem,
 and I believe that we are doing a wrong thing with having those _POSIX
 ifdefs in our headers..  Someone correct me if I'm wrong.


I have no idea, but be aware at least one reference in GCC showed up:
https://gcc.gnu.org/bugzilla/attachment.cgi?id=20034action=edit

But maybe that's there exactly because _POSIX is in the MinGW-w64 headers...

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

Re: [Mingw-w64-public] [PATCH] Copy getpid declaration in process.h to unistd.h

[Ruben Van Boxem]

2014-11-07 14:45 GMT+01:00 Dongsheng Song dongsheng.s...@gmail.com:

 On Fri, Nov 7, 2014 at 4:44 PM, lh_mouse lh_mo...@126.com wrote:
  Minor suggestion: use the word `DECLARED` instead `DEFINED` please.
 

 I don't known which is better:-)
 Here is some stats:

 $ grep -r _DEFINED[^A-Z0-9] . | wc -l
 26145

 $ grep -r _DECLARED[^A-Z0-9] . | wc -l
 15


That bit in your patch is clearly declaring a function. I don't see how a
pop poll helps decide proper wording?

Ruben




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

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

[Ruben Van Boxem]

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.

Cheers,

Ruben
--
___
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]

[Ruben Van Boxem]

2014-11-03 16:45 GMT+01:00 Baruch Burstein bmburst...@gmail.com:

 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?


That's the whole GCC/binutils/autotools ecosystem that does that and uses
that. Don't ask me for the reasons, I did not write the tools way back when.



 b. Is there another way to determine in the makefile if compiling for x64
 or x32 without using the compiler executable name?


First, a makefile shouldn't care if it's building for 32 or 64-bit. That is
a distinction you'd want to make at the code-level, if you need to make it
at all.
If you want to be able to cross-compile, a good way is to have the makefile
accept an option like CROSS_PREFIX, which could be i686-w64-mingw32-,
and passed in like:
make CROSS_PREFIX=i686-w64-mingw32-

And prefixing all calls to the tools with this prefix. For native
toolchains, just make with an empty CROSS_PREFIX would work.


Cheers,

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

Re: [Mingw-w64-public] CMake Toolcahin for linux/clang 3.6

[Ruben Van Boxem]

2014-10-20 15:25 GMT+02:00 Richard Shaw hobbes1...@gmail.com:
 On Mon, Oct 20, 2014 at 8:03 AM, Barnaby Jones simba@schrödingerskatze.de
 wrote:

 SET( CMAKE_CXX_FLAGS  ${CMAKE_CXX_FLAGS}
 -target=--target=i686-w64-mingw32 )
 SET( CMAKE_EXE_LINKER_FLAGS  ${CMAKE_EXE_LINKER_FLAGS}
 -target=--target=i686-w64-mingw32 )


 Complete guess here, but this looks funny. Are you sure it should be
 -target=--target=...

That's definitely wrong. If it's a native Clang, this option shouldn't
be necessary. What used to work for cross-compilation is
--target=i686-w64-mingw32 but recently (I think for 3.5, not sure
though) they changed the target names to some other scheme.

I'd just leave it out and make use of Clang's default target which should be OK.

Also, you can just use the MinGW Makefiles generator and pass
-DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ when invoking
CMake.

Ruben


 Thanks,
 Richard

 --
 Comprehensive Server Monitoring with Site24x7.
 Monitor 10 servers for $9/Month.
 Get alerted through email, SMS, voice calls or mobile push notifications.
 Take corrective actions from your mobile device.
 http://p.sf.net/sfu/Zoho
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] CMake Toolcahin for linux/clang 3.6

[Ruben Van Boxem]

2014-10-20 16:19 GMT+02:00 Óscar Fuentes o...@wanadoo.es:
 Barnaby Jones
 si...@xn--schrdingerskatze-pwb.de
 writes:

 The problems are self-evident:

 and  CMakeError.log --

 Determining if the C compiler works failed with the following output:
 Change Dir:

/home/barnaby/Dokumente/sourceProjects/gnustep/libobjc2/build/CMakeFiles/CMakeTmp

 Run Build Command:/usr/bin/make cmTryCompileExec427134963/fast
 /usr/bin/make -f CMakeFiles/cmTryCompileExec427134963.dir/build.make
 CMakeFiles/cmTryCompileExec427134963.dir/build
 make[1]: Entering directory

'/home/barnaby/Dokumente/sourceProjects/gnustep/libobjc2/build/CMakeFiles/CMakeTmp'
 /usr/bin/cmake -E cmake_progress_report

/home/barnaby/Dokumente/sourceProjects/gnustep/libobjc2/build/CMakeFiles/CMakeTmp/CMakeFiles
 1
 Building C object
 CMakeFiles/cmTryCompileExec427134963.dir/testCCompiler.c.obj
 /usr/local/bin/clang  -D__MINGW64__  -o
 CMakeFiles/cmTryCompileExec427134963.dir/testCCompiler.c.obj   -c

/home/barnaby/Dokumente/sourceProjects/gnustep/libobjc2/build/CMakeFiles/CMakeTmp/testCCompiler.c

 This is invoking clang with default target (no --target= option set.)
 It is not cross-compiling.

 Linking C executable cmTryCompileExec427134963.exe
 /usr/bin/cmake -E cmake_link_script
 CMakeFiles/cmTryCompileExec427134963.dir/link.txt --verbose=1
 /usr/bin/cmake -E remove -f
 CMakeFiles/cmTryCompileExec427134963.dir/objects.a
 /usr/bin/ar cr CMakeFiles/cmTryCompileExec427134963.dir/objects.a
 @CMakeFiles/cmTryCompileExec427134963.dir/objects1.rsp
 /usr/local/bin/clang   -Wl,--whole-archive
 CMakeFiles/cmTryCompileExec427134963.dir/objects.a
 -Wl,--no-whole-archive  -o cmTryCompileExec427134963.exe
 -Wl,--out-implib,libcmTryCompileExec427134963.dll.a
 -Wl,--major-image-version,0,--minor-image-version,0

 Same here.

 /usr/bin/ld: unrecognized option '--out-implib'

 Unsurprisingly, the platform's linker is used. You need to arrange
 things to invoke mingw-w64 cross-compiler. Possibly fixing the previous
 problem also fixes this.

 As stated, the problem is not related to MinGW-w64, it is about how you
 configure the CMake/Clang combo for cross-compiling.

I beg to differ, and it is quite related to using MinGW-w64. It's just not
about GCC.

Currently, Clang as-is cannot cross-compile to the MinGW-w64 targets.

There is a patch that has not landed yet which adds MinGW-w64 support:
http://reviews.llvm.org/D5268

It should work and looks in /usr/{i686,x86_64}-w64-mingw32/{include,lib}
for headers/libraries. Unfortunately, I don't know the exact target names
for Clang's --target option.

Reading here
http://clang.llvm.org/docs/CrossCompilation.html#target-triple it seems
like x86-w64-win32-gnu or x86_64-w64-win32-gnu should work.

Cheers,

Ruben




--
 Comprehensive Server Monitoring with Site24x7.
 Monitor 10 servers for $9/Month.
 Get alerted through email, SMS, voice calls or mobile push notifications.
 Take corrective actions from your mobile device.
 http://p.sf.net/sfu/Zoho
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Debugging with GDB

[Ruben Van Boxem]

2014-10-15 10:05 GMT+02:00 Alexander Shukaev haroo...@gmail.com:

 When the application crashes it shows the following:

   Fault Module Name: StackHash_e7de
   Fault Module Version: 0.0.0.0
   Fault Module Timestamp: 
   Exception Offset: PCH_E1_FROM_ntdll+0x0009B13A
   Exception Code: c005
   Exception Data: 0008

 This resembles exactly what I said about Windows system DLLs. They are not
 built with debugging information and even if they would, it would still
 never be GDB compatible. That's why I assume that in certain cases GDB on
 Windows is useless. Am I wrong?


The only way this can be looked at with more than a brief glimpse, is if
there is some form of reduced code that exhibits this problem (including
compilation commands). If the library/application you used is open source,
that might do as a first approximation.

Cheers,

Ruben




 --
 Comprehensive Server Monitoring with Site24x7.
 Monitor 10 servers for $9/Month.
 Get alerted through email, SMS, voice calls or mobile push notifications.
 Take corrective actions from your mobile device.
 http://p.sf.net/sfu/Zoho
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho___
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-W64 installation fails with 'ERROR res'

[Ruben Van Boxem]

2014-10-14 14:22 GMT+02:00 niXman i.nix...@autistici.org:

 John Threepwood 2014-10-14 16:11:
  Hello,

 Hi,

 Please read this:
 https://sourceforge.net/p/mingw-w64/bugs/413/?page=0


Just a thought: why use a paid-for installer instead of something freely
available like NSIS?

Ruben




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


 --
 Comprehensive Server Monitoring with Site24x7.
 Monitor 10 servers for $9/Month.
 Get alerted through email, SMS, voice calls or mobile push notifications.
 Take corrective actions from your mobile device.
 http://p.sf.net/sfu/Zoho
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho___
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-W64 installation fails with 'ERROR res'

[Ruben Van Boxem]

2014-10-14 14:37 GMT+02:00 niXman i.nix...@autistici.org:

  Just a thought: why use a paid-for installer instead of something
  freely
  available like NSIS?

 Hi,

 Because I use this installer in a few of my commercial projects. Why do
 I need to learn yet another installer?


Well, I honestly don't really care what installer you use as long as it
works (that's why I brought it up now ;-)), but should you leave the
project suddenly for whatever reason (sickness, death, work, etc.), there
would be no installer anymore. It would be logical that any project member
could build such a thing by only downloading some free tools. Additionally:
if it were only an update to the installer software that was needed,
everyone on the project could have updated it. But now the fix takes longer
because it depends on a single person's personal access to commercial
software.

Don't get me wrong: your installer is better than no installer (and worked
well before this issue popped up out of nowhere), but it is still
suboptimal for an open source project run and maintained by various people.

Cheers,

Ruben


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


 --
 Comprehensive Server Monitoring with Site24x7.
 Monitor 10 servers for $9/Month.
 Get alerted through email, SMS, voice calls or mobile push notifications.
 Take corrective actions from your mobile device.
 http://p.sf.net/sfu/Zoho
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho___
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 x86_64-w64-mingw32-gcc in Debian 7?

[Ruben Van Boxem]

2014-09-14 17:23 GMT+02:00 Ralph Gossamer zaza4...@yandex.com:

 So I have installed mingw-w64 components targetting only w64 architecture
 on Debian 7.

 After installation, I couldn't locate x86_64-w64-mingw32-gcc. Or could it
 be called by another name?


When you install the mingw-w64
https://packages.debian.org/wheezy/mingw-w64 package in Debian, you
should have both 32 and 64-bit toolchains. This will pull in the GCC
packages for each architecture and install them.

You can see the list of files contained in e.g. the mingw-w64-gcc-i686
package here:
https://packages.debian.org/wheezy/amd64/gcc-mingw-w64-i686/filelist

And similar for all the other packages installed by the aforementioned
mingw-w64 Debian package.

As you can see, x86_64-w64-mingw32-gcc is installed in /usr/bin.

Ruben



 Thanks in advance for your help.

 Ralph


 --
 Want excitement?
 Manually upgrade your production database.
 When you want reliability, choose Perforce
 Perforce version control. Predictably reliable.

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

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/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] exceptions weirdness

[Ruben Van Boxem]

2014-08-24 23:48 GMT+02:00 Yaron Keren yaron.ke...@gmail.com:

 Hi Tai,

 Thanks for looking into this. You are correct the right frontend should be
 used, however this isn't the root of the problem.
 It works since g++ defaults to -shared-libgcc while gcc defaults to
 -static-libgcc.
 If you force g++ to static link libgcc, the exception is still uncaught:

   g++ -static-libgcc a.cpp -lstdc++  a

 Yaron


If you link to static libgcc, you should also link libstdc++ statically. It
would make no sense to do otherwise. A shortcut for all this would be to
use -static, but this will also force you to use static versions of all
other libraries you link, which may or may not be what you want.

Ruben



 2014-08-25 0:18 GMT+03:00 Kai Tietz ktiet...@googlemail.com:

 Hi Yaron,

 I can't reproduce your reported issue by using proper frontends.  You
 shouldn't use gcc frontend.  Instead use g++.  Later automatically
 adds proper link-libraries for c++ automatically.  So you don't need
 to add -lstdc++ manual.

 By using 'g++ -o a a.cpp  ./a' it works for me as expected.

 Kai


 --
 Slashdot TV.
 Video for Nerds.  Stuff that matters.
 http://tv.slashdot.org/
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public




 --
 Slashdot TV.
 Video for Nerds.  Stuff that matters.
 http://tv.slashdot.org/
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] OpenCL, crosscompiling, rubenvb builds

[Ruben Van Boxem]

2014-08-03 11:56 GMT+02:00 Asiga Nael asigan...@yahoo.com:

 Hi!

 Is there any easy way of adding OpenCL support to rubenvb builds? I'm
 still in an older release (4.6.x) (because I built it myself from source
 and has worked great all these years), but I just downloaded the latest 4.8
 release and didn't find OpenCL headers nor libs either.


Yeah, I didn't include them in my builds.



 I'm using mingw-w64 for cross-compiling only (from either Linux or OSX,
 depending on the day), so installing the NVIDIA or AMD gpu sdk isn't an
 option (well, actually, I've them installed, but for my native builds on
 Linux and OSX, of course, but it's not possible to do so for a
 cross-compiling scenario).

 I tend to believe I just need headers and some sort of lib that makes the
 mingw-w64 linker happy (because the real OpenCL DLL will be in the user
 machine and it depends on the user's gpu, drivers, etc...)


Yes, all you need is some headers and maybe (I would say so) an import
library.


 Can I simply add any headers or libs to the rubenvb 4.6.x toolchains and
 it will magically work? Or is it more complex than that?


It should work: if you take the import library (libopencl.a or
libopencl.dll.a) from a GPU vendor's SDK, it should enable it to work on
all systems (if I understand all the OpenCL magic correctly).

Also: I strongly recommend switching to the mingw-builds toolchains. Mine
are quite old by now and the mingw-builds are better and newer ;-)

Cheers,

Ruben
--
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] internal segfault, errors using basic_ostringstringstream with u16string, u32string

[Ruben Van Boxem]

2014-07-26 1:54 GMT+02:00 Jim Michaels jmich...@yahoo.com:

 this blast of errors is telling me that in 4.9.0 posix sjlj rev2, I have
 no operator+ on my basic_string for std::u16string and std::u32string,
 which are defined in the class. sort of. part of the reason may be because
 std::basic_ostringstream::str() (?) is incompatible with std::u16string and
 std::u32string.
 why is this?

 I don't know if my attachment will cause a bounce.
 compiling atoi64 with -DATOI64TEST will make it a standalone executable
 and enable its main(). you will have to edit the includes.

 segfault may be occurring because of a different file, atoi64.cpp, which
 is including strfuncs.cpp. simple compiling that file alone causes no
 problems. it's a weird bug that this mass of 5 huge number conversion
 functions seems to trigger.

 there is no SCCE whatever for this. I can't reduce the segfault except to
 compiling atoi64.cpp (32-bit compiler internal segfaults with strfuncs.cpp
 also) which needs a string and number unit library I wrote. I

 to show you the problems I would end up attaching my project files, maybe
 through dropbox.
 if I provide my code, does it suddenly become open source?


 std::u32string s;
 std::basic_stringstreamchar32_t out;
 out.width(intMantissaWidth+1+numDigitsPastDecimalPoint);
 out.fill(' ');
 out.precision(numDigitsPastDecimalPoint);
 out.flags(ios::dec|ios::fixed|ios::right|ios::showpoint);
 outd;
 return out.str()+aprSIPrefixesd[i]+suffixStr;
 apparenrtly operator+ disappeared from basic_str...

 there are about 3-4 functions each.


 \prj\lib\siiec\siiec.cpp:60:10: internal compiler error: Segmentation fault
 \prj\lib\prsinum\prsinum.cpp:908:33: error: no match for 'operator+'
 (operand types are 'std::basic_stringstreamchar16_t::__string_type {aka
 std::basic_string
 char16_t}' and
 '__gnu_cxx::__alloc_traitsstd::allocatorstd::basic_stringchar 
 ::value_type {aka std::basic_stringchar}')
 \prj\lib\prsinum\prsinum.cpp:958:33: error: no match for 'operator+'
 (operand types are 'std::basic_stringstreamchar16_t::__string_type {aka
 std::basic_string
 char16_t}' and
 '__gnu_cxx::__alloc_traitsstd::allocatorstd::basic_stringchar 
 ::value_type {aka std::basic_stringchar}')
 \prj\lib\prsinum\prsinum.cpp:1015:34: error: no match for 'operator+'
 (operand types are 'std::basic_stringstreamchar16_t::__string_type {aka
 std::basic_strin
 gchar16_t}' and
 '__gnu_cxx::__alloc_traitsstd::allocatorstd::basic_stringchar 
 ::value_type {aka std::basic_stringchar}')
 \prj\lib\prsinum\prsinum.cpp:1051:37: error: no match for 'operator+'
 (operand types are 'std::basic_stringstreamchar16_t::__string_type {aka
 std::basic_strin
 gchar16_t}' and
 '__gnu_cxx::__alloc_traitsstd::allocatorstd::basic_stringchar 
 ::value_type {aka std::basic_stringchar}')
 \prj\lib\prsinum\prsinum.cpp:1105:33: error: no match for 'operator+'
 (operand types are 'std::basic_stringstreamchar16_t::__string_type {aka
 std::basic_strin
 gchar16_t}' and
 '__gnu_cxx::__alloc_traitsstd::allocatorstd::basic_stringchar 
 ::value_type {aka std::basic_stringchar}')
 \prj\lib\prsinum\prsinum.cpp:1155:39: error: cannot bind
 'std::basic_ostreamchar16_t, std::char_traitschar16_t ' lvalue to
 'std::basic_ostreamchar16_t, std
 ::char_traitschar16_t '
 \prj\lib\prsinum\prsinum.cpp:1209:37: error: no match for 'operator+'
 (operand types are 'std::basic_stringstreamchar16_t::__string_type {aka
 std::basic_strin
 gchar16_t}' and
 '__gnu_cxx::__alloc_traitsstd::allocatorstd::basic_stringchar 
 ::value_type {aka std::basic_stringchar}')
 \prj\lib\prsinum\prsinum.cpp:1245:37: error: no match for 'operator+'
 (operand types are 'std::basic_stringstreamchar16_t::__string_type {aka
 std::basic_strin
 gchar16_t}' and
 '__gnu_cxx::__alloc_traitsstd::allocatorstd::basic_stringchar 
 ::value_type {aka std::basic_stringchar}')
 \prj\lib\prsinum\prsinum.cpp:1290:33: error: no match for 'operator+'
 (operand types are 'std::basic_stringstreamchar16_t::__string_type {aka
 std::basic_strin
 gchar16_t}' and
 '__gnu_cxx::__alloc_traitsstd::allocatorstd::basic_stringchar 
 ::value_type {aka std::basic_stringchar}')
 \prj\lib\prsinum\prsinum.cpp:1321:33: error: no match for 'operator+'
 (operand types are 'std::basic_stringstreamchar16_t::__string_type {aka
 std::basic_strin
 gchar16_t}' and
 '__gnu_cxx::__alloc_traitsstd::allocatorstd::basic_stringchar 
 ::value_type {aka std::basic_stringchar}')
 \prj\lib\prsinum\prsinum.cpp:1354:37: error: no match for 'operator+'
 (operand types are 'std::basic_stringstreamchar16_t::__string_type {aka
 std::basic_strin
 gchar16_t}' and
 '__gnu_cxx::__alloc_traitsstd::allocatorstd::basic_stringchar 
 ::value_type {aka std::basic_stringchar}')
 \prj\lib\prsinum\prsinum.cpp:1374:37: error: no match for 'operator+'
 (operand types are 'std::basic_stringstreamchar16_t::__string_type {aka
 std::basic_strin
 gchar16_t}' and
 

Re: [Mingw-w64-public] possible use seh for 32 bit migw-w63 GCC-4.9.1 :

[Ruben Van Boxem]

2014-07-29 11:47 GMT+02:00 massimo massimo.belgr...@gmail.com:

 Ruben Van Boxem vanboxem.ruben@... writes:

 
 
  2014-07-22 20:01 GMT+02:00 niXman i.nixman-
 gaufno9rbhfsroww+9z...@public.gmane.org:Does anybody know is SEH-32bit
 support already implemented in GCC?
 
  It's not.
 Thanks for info
 Is follow link 4.9.1 with seh?

 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.1/threads-win32/seh/


That's right.
If you also want C++11 thread, mutex and future support, go with

http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.1/threads-posix/seh/
http://sourceforge.net/projects/mingw-

Cheers,

Ruben
--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/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] Frame pointer and Win32 API functions

[Ruben Van Boxem]

Hi guys,

I stumbled upon a strange question on Stackoverflow.com:
http://stackoverflow.com/q/24962205/256138

Is he right to think the generated code is suboptimal? Or is this an ABI
requirement? Can GCC be improved in this regard?

I can point him to this mailing list and ask him to supply reproducible
proof of what he's claiming if you guys think it worthwhile.

Cheers,

Ruben
--
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] __int128 literals don't work

[Ruben Van Boxem]

2014-07-25 13:16 GMT+02:00 Jim Michaels jmich...@yahoo.com:

 __int128.cpp:4:16: warning: integer constant is too large for its type
  __int128 i=170141183460469231731687303715884105727LL;
 ^
 __int128.cpp:5:25: warning: integer constant is too large for its type
  unsigned __int128 u=340282366920938463463374607431768211455ULL;
  ^
 __int128.cpp:4:16: warning: integer constant is too large for its type
  __int128 i=170141183460469231731687303715884105727;
 ^
 __int128.cpp:5:25: warning: integer constant is too large for its type
  unsigned __int128 u=340282366920938463463374607431768211455U;
  ^
 __int128.cpp:4:16: error: unable to find numeric literal operator
 'operatorLLL'
  __int128 i=170141183460469231731687303715884105727LLL;
 ^
 __int128.cpp:4:16: note: use -std=gnu++11 or -fext-numeric-literals to
 enable more built-in suffixes
 __int128.cpp:5:25: error: unable to find numeric literal operator
 'operatorULLL'
  unsigned __int128 u=340282366920938463463374607431768211455ULLL;
  ^

 no way to win with __int128 even though it's supposed to be supported.
 there's not even a stdint.h type for it.


__int128 is a nonstandard type (i.e. not defined in any C++ or C standard).
So you can't expect a C library header to know about it.

If you read the GCC manual on the subject
https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html, you will also
note the following:

 There is no support in GCC for expressing an integer constant of type
__int128 for targets with long long integer less than 128 bits wide.

As on Windows, long long is 64 bits wide, GCC does not support 128-bit
integer literals.

Ruben





 -
 Jim Michaels
 jmich...@yahoo.com
 j...@renewalcomputerservices.com
 http:#x2F;#x2F;RenewalComputerServices.com
 http:#x2F;#x2F;JesusnJim.com (computer repair info, programming)



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


--
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] problem using printf with __int128 in 4.9.0

[Ruben Van Boxem]

2014-07-25 13:10 GMT+02:00 Jim Michaels jmich...@yahoo.com:

 #include stdio.h
 #include _mingw.h
 int main(void) {
 __int128 i=170141183460469231731687303715884105727LLL;
 unsigned __int128 u=340282366920938463463374607431768211455ULLL;
 //printf(i=%I128d\n, i);
 printf(%*d, 128/8, i);
 printf(  170141183460469231731687303715884105727LLL\n);

 //printf(u=%I128u\n, u);
 printf(%*u, 128/8, u);
 printf(%lu, u);
 printf(%llu, u);
 printf(%lllu, u);
 printf(%I128u, u);
 printf(  340282366920938463463374607431768211455ULLL\n);
 return 0;
 }
 /*

 __int128.cpp: In function 'int main()':
 __int128.cpp:4:16: error: unable to find numeric literal operator
 'operatorLLL'
  __int128 i=170141183460469231731687303715884105727LLL;
 ^
 __int128.cpp:4:16: note: use -std=gnu++11 or -fext-numeric-literals to
 enable more built-in suffixes
 __int128.cpp:5:25: error: unable to find numeric literal operator
 'operatorULLL'
  unsigned __int128 u=340282366920938463463374607431768211455ULLL;
  ^
 __int128.cpp:5:25: note: use -std=gnu++11 or -fext-numeric-literals to
 enable more built-in suffixes
 __int128.cpp:7:24: warning: format '%d' expects argument of type 'int',
 but argument 3 has type '__int128' [-Wformat=]
   printf(%*d, 128/8, i);
 ^
 __int128.cpp:11:24: warning: format '%u' expects argument of type
 'unsigned int', but argument 3 has type '__int128 unsigned' [-Wformat=]
   printf(%*u, 128/8, u);
 ^
 __int128.cpp:12:17: warning: format '%lu' expects argument of type 'long
 unsigned int', but argument 2 has type '__int128 unsigned' [-Wformat=]
   printf(%lu, u);
  ^
 __int128.cpp:13:18: warning: unknown conversion type character 'l' in
 format [-Wformat=]
   printf(%llu, u);
   ^
 __int128.cpp:13:18: warning: too many arguments for format
 [-Wformat-extra-args]
 __int128.cpp:14:19: warning: unknown conversion type character 'l' in
 format [-Wformat=]
   printf(%lllu, u);
^
 __int128.cpp:14:19: warning: too many arguments for format
 [-Wformat-extra-args]
 __int128.cpp:15:20: warning: unknown conversion type character '1' in
 format [-Wformat=]
   printf(%I128u, u);
 ^
 __int128.cpp:15:20: warning: too many arguments for format
 [-Wformat-extra-args]

 Fri 07/25/2014  4:07:36.01|d:\prj\test\mingw-w64\__int128|call
 beepifexists.cmd __int128.exe
 EXISTS: __int128.exe
 -failure-


The fact that the compiler has a type does not mean the C library can
handle it.

This stackoverflow question
http://stackoverflow.com/questions/11656241/how-to-print-uint128-t-number-using-gcc
has a link https://gist.github.com/zed/7f7e7451b60aff301fe0 to the
following code you can try:

#define P(n) do {   \
print_hex(n);   \
print_uint128(n);   \
print(n);   \
  } while(0)

typedef __uint128_t uint128_t;

int print_hex(uint128_t n) {
  uint64_t lo = n;
  uint64_t hi = (n  64);
  if (hi)  {
printf(% PRIX64, hi);
return printf(%016 PRIX64 \n, lo);
  }
  return printf(% PRIX64 \n, lo);
}

int print(uint128_t n) {

  if (n == 0)  return printf(0\n);


  uint64_t factor = 10; // 3*13 == 39: 2**128  10**39
  const int size = 3;
  uint64_t parts[size];


  uint64_t *p = parts + size; // start at the end
  while (p != parts) {
*--p = n % factor; // get last part
n /= factor;   // drop it
  }


  for (p = parts; p != parts[size]; ++p)
if (*p) {
  printf(% PRIu64, *p);
  break; // found nonzero part
}

  for ( ++p; p != parts[size]; ++p)
printf(%013 PRIu64, *p);


  return printf(\n);
}


int
print_uint128(uint128_t n) {
  if (n == 0)  return printf(0\n);

  char str[40] = {0}; // log10(1  128) + '\0'
  char *s = str + sizeof(str) - 1; // start at the end
  while (n != 0) {
if (s == str) return -1; // never happens

*--s = 0123456789[n % 10]; // save last digit
n /= 10; // drop it
  }
  return printf(%s\n, s);
}

Cheers, and please learn to google first. These are all top answers when
searching for keywords in your question.

Ruben
--
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] problem using printf with __int128 in 4.9.0

[Ruben Van Boxem]

2014-07-25 17:06 GMT+02:00 JonY jo...@users.sourceforge.net:

 On 7/25/2014 19:40, Ruben Van Boxem wrote:
 
  The fact that the compiler has a type does not mean the C library can
  handle it.
 

 Rebuild mingw-w64-crt with --enable-experimental=printf128 to enable
 experimental integer handling in __mingw* family of printf. Use
 %I128[u,d,x].


That's good to know MinGW-w64 is on top of it :-)

Ruben








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


--
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] fork is an inbuilt function?

[Ruben Van Boxem]

2014-07-22 23:37 GMT+02:00 Ray Donnelly mingw.andr...@gmail.com:

 Hello,

 While porting msysGit to MSYS2/MinGW-w64 we ran into this:

 $ PATH=/mingw64/bin:$PATH gcc --version
 gcc.exe (Rev1, Built by MSYS2 project) 4.9.1

 $ cat test.c
 #include unistd.h
 static inline pid_t fork(void);
 void main() {}

 $ PATH=/mingw64/bin:$PATH gcc test.c
 test.c:2:21: warning: conflicting types for built-in function 'fork'
  static inline pid_t fork(void);
  ^

 Anyone got any ideas about this?


GCC has a number of builtin functions like printf, memcpy, and a bunch of
math functions as well. This is mostly for optimization  It seems it also
has a builtin fork, which it really should disable for Windows targets,
but doesn't. I'd file a bug report, GCC shouldn't have a builtin fork on
Windows.

Also note that main should return int, not void. The latter is technically
undefined behavior.

Cheers,

Ruben


 Best regards,

 Ray.


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

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

[Ruben Van Boxem]

2014-07-23 11:21 GMT+02:00 Jim Michaels jmich...@yahoo.com:

 you can rename the compiler's make.exe to make.ex, that will make it go
 away without deleting it, if you need it back, you can always rename it.
 another option is to simply change your PATH environment variable so that
 the compiler is last and MSYS path is before that. since searching for
 executables looks through the PATH to find the dir that a given executable
 is in to execute it,  it only makes sense to put the compiler last.


The compiler doesn't come with make.exe. No decent native Windows
toolchain should even contain a make.exe, it should be named
mingw32-make.exe, and this is exactly the reason why the naming has to be
the way it is. The toolchain in the OP's email does it right, so I don't
see why you would need to make make.exe go away.


 in \msys\etc\profile put:
 if [ $MSYSTEM == MINGW32 ]; then
   export PATH=.:/usr/local/bin:/mingw64h64t/bin:/bin:$PATH
 else
   export PATH=.:/usr/local/bin:/bin:/mingw64h64t/bin:$PATH
 fi

 I have my compiler path identified in /etc/fstab by /mingw64h64t as the
 compiler which is 64-bit host, 64-bit target.
 I have 2 installations of MSYS2, one for 32-bit target, and one for 64-bit
 target.


No need to mess with MSYS2 PATH or configuration fiel. And also no need to
have to seperate installations of MSYS2 for the two targets. You have
shortcuts that add /mingw64/bin or /mingw32/bin to PATH automatically, or
you can do it manually when you need a quick switch.

Don't underestimate MSYS2, it's quite brilliant in its relative simplicity
;-)

Cheers,

Ruben




   --
  *From:* Baruch Burstein bmburst...@gmail.com
 *To:* mingw-w64-public@lists.sourceforge.net
 *Sent:* Tuesday, July 22, 2014 5:31 AM
 *Subject:* [Mingw-w64-public] MSYS2 issues

 Hi,

 I (think I) found a bug in msys2. Here is a simple demo case:

 main.c:
 int main() { return 42; }

 Makefile:
 CC = gcc
 CC2 = $(shell which $(CC))
 out_1: clean main.c
 $(CC) main.c -o /home/username/out.exe
 out_2: clean main.c
 $(CC) /home/username/main.c -o out.exe
 out_3: clean main.c
 $(CC) 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




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


--
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] fork is an inbuilt function?

[Ruben Van Boxem]

2014-07-23 13:32 GMT+02:00 Óscar Fuentes o...@wanadoo.es:

 Ray Donnelly mingw.andr...@gmail.com
 writes:

  Hi Ruben,
 
  Please take this in the friendly/jokey manner it is intended.
 
  This isn't the first time you corrected me on the return value from
  main when I'm making a test-case to demonstrate a compiler issue; I
  honestly couldn't care less and my goal is to use the minimum amount
  of characters and so following the standards doesn't come into it,

 `int' is one character less than `void' ;-)


I was just about to write that :-P


  but
  if you feel you must point this out each time, I'll just consider it a
  quirk and ignore it.

 I would do the same as Ruben. When I contribute help on a public mailing
 list, my message is not directed at the individual who asked, but to
 every potential reader, current or future.

 Whenever you post an incorrect piece of code, think that all sorts of
 users will read your message, including newbies that can learn by
 reading your posts. Hence, Ruben is counterbalancing your misinformation
 :-)


Yeah, it's a positive side effect of me spending too much time on
stackoverflow.com. I start spotting mistakes all over the place :-)

(Thanks for the backup!)

Ruben



 [snip]



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

--
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] r212448 - in /trunk: gcc/ChangeLog gcc/Makefile...

[Ruben Van Boxem]

2014-07-16 11:44 GMT+02:00 Dongsheng Song dongsheng.s...@gmail.com:

 On Wed, Jul 16, 2014 at 12:37 AM, Rong Xu x...@google.com wrote:
  On Mon, Jul 14, 2014 at 11:02 PM, Dongsheng Song
  dongsheng.s...@gmail.com wrote:
  Hi Rong,
 
  Your commit r212448 broken Windows target 4 days.
  Since windows target no ftw.h, this caused the following errors:
 
  Sorry for this. Do you know if there is a similar API in windows?
  If the answer is no, I will have to disable gcov-tool in windows.
 

 Windows have FindFirstFile/FindNextFile/FindClose.

 PS: The ftw() function is marked obsolescent.
 http://pubs.opengroup.org/onlinepubs/9699919799/functions/ftw.html


Just use nftw() instead, which is the recommended replacement.



  Thanks,
 
  -Rong
 
 
  make[2]: Entering directory
  `/home/cauchy/obj/native/gcc-4.10-win64/gcc/libdecnumber'
  make[2]: Nothing to be done for `all'.
  make[2]: Leaving directory
  `/home/cauchy/obj/native/gcc-4.10-win64/gcc/libdecnumber'
  make[2]: Entering directory
 `/home/cauchy/obj/native/gcc-4.10-win64/gcc/gcc'
  x86_64-w64-mingw32-g++ -c   -g -O2 -DIN_GCC-fno-exceptions
  -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
  -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
  -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
  -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I.
  -I/home/cauchy/vcs/svn/gcc/trunk/gcc
  -I/home/cauchy/vcs/svn/gcc/trunk/gcc/.
  -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../include
  -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libcpp/include
  -I/home/cauchy/obj/native/gcc-4.10-win64/gcc/./gmp
  -I/home/cauchy/vcs/svn/gcc/trunk/gmp
  -I/home/cauchy/obj/native/gcc-4.10-win64/gcc/./mpfr/src
  -I/home/cauchy/vcs/svn/gcc/trunk/mpfr/src
  -I/home/cauchy/vcs/svn/gcc/trunk/mpc/src
  -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libdecnumber
  -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libdecnumber/bid
  -I../libdecnumber -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libbacktrace
  -DCLOOG_INT_GMP
  -I/home/cauchy/obj/native/gcc-4.10-win64/gcc/./cloog/include
  -I/home/cauchy/vcs/svn/gcc/trunk/cloog/include
  -I/home/cauchy/obj/native/gcc-4.10-win64/gcc/./isl/include
  -I/home/cauchy/vcs/svn/gcc/trunk/isl/include  -o gcov-tool.o -MT
  gcov-tool.o -MMD -MP -MF ./.deps/gcov-tool.TPo
  /home/cauchy/vcs/svn/gcc/trunk/gcc/gcov-tool.c
  /home/cauchy/vcs/svn/gcc/trunk/gcc/gcov-tool.c:38:17: fatal error:
  ftw.h: No such file or directory
   #include ftw.h
   ^
  compilation terminated.
  make[2]: *** [gcov-tool.o] Error 1
  make[2]: Leaving directory
 `/home/cauchy/obj/native/gcc-4.10-win64/gcc/gcc'
  make[1]: *** [all-gcc] Error 2
  make[1]: Leaving directory `/home/cauchy/obj/native/gcc-4.10-win64/gcc'
  make: *** [all] Error 2
 
  Regards,
  Dongsheng
 
  On Fri, Jul 11, 2014 at 1:48 PM,  x...@gcc.gnu.org wrote:
  Author: xur
  Date: Fri Jul 11 05:48:07 2014
  New Revision: 212448
 
  URL: https://gcc.gnu.org/viewcvs?rev=212448root=gccview=rev
  Log:
  2014-07-10  Rong Xu  x...@google.com
 
  Add gcov-tool: an offline gcda profile processing tool
  Support.
  * gcc/gcov-io.c (gcov_position): Make avaialble to gcov-tool.
  (gcov_is_error): Ditto.
  (gcov_read_string): Ditto.
  (gcov_read_sync): Ditto.
  * gcc/gcov-io.h: Move counter defines to gcov-counter.def.
  * gcc/gcov-dump.c (tag_counters): Use gcov-counter.def.
  * gcc/coverage.c: Ditto.
  * gcc/gcov-tool.c: Offline gcda profile processing tool.
  (unlink_gcda_file): Remove one gcda file.
  (unlink_profile_dir): Remove gcda files from the profile path.
  (gcov_output_files): Output gcda files to an output dir.
  (profile_merge): Merge two profiles in directory.
  (print_merge_usage_message): Print merge usage.
  (merge_usage): Print merge usage and exit.
  (do_merge): Driver for profile merge sub-command.
  (profile_rewrite): Rewrite profile.
  (print_rewrite_usage_message): Print rewrite usage.
  (rewrite_usage): Print rewrite usage and exit.
  (do_rewrite): Driver for profile rewrite sub-command.
  (print_usage): Print gcov-info usage and exit.
  (print_version): Print gcov-info version.
  (process_args): Process arguments.
  (main): Main routine for gcov-tool.
  * gcc/Makefile.in: Build and install gcov-tool.
  * gcc/gcov-counter.def: New file split from gcov-io.h.
  * libgcc/libgcov-driver.c (gcov_max_filename): Make available
  to gcov-tool.
  * libgcc/libgcov-merge.c (__gcov_merge_add): Replace
  gcov_read_counter() with a Macro.
  (__gcov_merge_ior): Ditto.
  (__gcov_merge_time_profile): Ditto.
  (__gcov_merge_single): Ditto.
  (__gcov_merge_delta): Ditto.
  * libgcc/libgcov-util.c (void gcov_set_verbose): Set the
 verbose flag
  in the utility functions.
  (set_fn_ctrs):