On 5/29/2019 4:29 PM, maxgacode wrote:
Il 29/05/2019 21:16, Edward Diener ha scritto:
Are you saying I have to build a mingw-w64 toolchain for a particular
version of gcc on Windows in an MSYS2 environment ?
Or are you saying that once MSYS2 is installed and updated, various
gcc version
On 5/29/2019 2:30 PM, maxgacode wrote:
Il 29/05/2019 18:03, Edward Diener ha scritto:
[1] https://www.msys2.org/
Are you saying that MSYS2 provides a series of gcc compiler releases
on Windows that are equivalent in compiler functionality to the
official gcc releases for Linux
On 5/29/2019 12:09 PM, niXman wrote:
Edward Diener 2019-05-28 19:50:
There has not been an update to MingW-W64-builds for over a year while
gcc 6.5, 7.4, 8.2, 8.3, and 9.1 have been released. The mingw-w64
downloads page at https://mingw-w64.org/doku.php/download looks wildly
out of date as far
On 5/29/2019 4:30 AM, Liu Hao wrote:
在 2019/5/29 上午12:50, Edward Diener 写道:
There has not been an update to MingW-W64-builds for over a year while
gcc 6.5, 7.4, 8.2, 8.3, and 9.1 have been released. The mingw-w64
downloads page at https://mingw-w64.org/doku.php/download looks wildly
out of date
There has not been an update to MingW-W64-builds for over a year while
gcc 6.5, 7.4, 8.2, 8.3, and 9.1 have been released. The mingw-w64
downloads page at https://mingw-w64.org/doku.php/download looks wildly
out of date as far as latest releases are concerned.
Does nobody care ?
I realize I
The last version that can be downloaded using mingw-w64-install is gcc
8.1, which was released almost a year ago. In the meantime releases 8.2
and 8.3 of gcc have been released, Can we not get an update so that
mingw-w64-install can download releases 8.2 an 8.3 of gcc on Windows.
Gcc is the
On 11/26/2018 10:06 AM, Earnie via Mingw-w64-public wrote:
On 11/24/2018 5:27 PM, Edward Diener wrote:
On 11/24/2018 5:18 PM, Earnie via Mingw-w64-public wrote:
On 11/24/2018 3:17 PM, Edward Diener wrote:
Is there anywhere a description of the files in a mingw-w64
distribution, with perhaps
patient answers to my questions
about the process of building a mingw package.
sob., 24 lis 2018 o 22:58 Edward Diener
napisał(a):
On 11/24/2018 1:21 AM, Liu Hao wrote:
在 2018/11/24 13:30, Edward Diener 写道:
==> Starting prepare()...
patch: invalid argument 'E:\\Programming\\VersionCont
On 11/24/2018 5:18 PM, Earnie via Mingw-w64-public wrote:
On 11/24/2018 3:17 PM, Edward Diener wrote:
Is there anywhere a description of the files in a mingw-w64
distribution, with perhaps an explanation of whether any given file is
used at compile, link, run-time, and/or for some other
On 11/24/2018 1:21 AM, Liu Hao wrote:
在 2018/11/24 13:30, Edward Diener 写道:
==> Starting prepare()...
patch: invalid argument 'E:\\Programming\\VersionControl' for
'$VERSION_CONTROL'
Valid arguments are:
- 'none', 'off'
- 'simple', 'never'
- 'existing', 'nil'
- 'numbered',
Is there anywhere a description of the files in a mingw-w64
distribution, with perhaps an explanation of whether any given file is
used at compile, link, run-time, and/or for some other purpose ?
___
Mingw-w64-public mailing list
On 11/23/2018 10:04 PM, Liu Hao wrote:
在 2018/11/24 上午9:31, Edward Diener 写道:
On 11/23/2018 5:06 PM, Greg Jung wrote:
You should try "makepkg -g" and paste/copy the results, for the lines
that
are different, into the PKGBUILD.
Then, makepkg --check can be used to test it.
When I r
On 11/23/2018 5:49 PM, Earnie via Mingw-w64-public wrote:
On 11/23/2018 3:12 PM, Edward Diener wrote:
On 11/23/2018 9:06 AM, Liu Hao wrote:
在 2018/11/23 21:55, Edward Diener 写道:
On 11/22/2018 9:07 PM, Liu Hao wrote:
==> Verifying source file signatures with gpg...
binutils-2.30.tar.
es among others:
pkgname=("${MINGW_PACKAGE_PREFIX}-${_realname}")
depends=("${MINGW_PACKAGE_PREFIX}-libiconv" "${MINGW_PACKAGE_PREFIX}-zlib")
makedepends=("${MINGW_PACKAGE_PREFIX}-libiconv"
"${MINGW_PACKAGE_PREFIX}-zlib")
Needless to say I did not c
On 11/23/2018 9:06 AM, Liu Hao wrote:
在 2018/11/23 21:55, Edward Diener 写道:
On 11/22/2018 9:07 PM, Liu Hao wrote:
==> Verifying source file signatures with gpg...
binutils-2.30.tar.bz2 ... FAILED (unknown public key 13FCEF89DD9E3C4F)
==> ERROR: One or more PGP signatures
On 11/22/2018 9:07 PM, Liu Hao wrote:
在 2018/11/23 上午7:50, Edward Diener 写道:
There is a bug which in binutils which causes clang targeting
mingw-64/gcc on Windows to create a bad windows executable. The bug is
explained at https://sourceware.org/bugzilla/show_bug.cgi?id=23872 and
is fixed
ystems to do this, or if it even matters, so I will try the MSYS2
MSYS subsystem.
Once I do this I assume that I have produced Windows executables and
libraries and can copy the ld.exe I produce to the mingw-w64
distribution I have previously installed.
On Thu, Nov 22, 2018 at 6:49 PM Edward Die
On 11/22/2018 9:07 PM, Liu Hao wrote:
在 2018/11/23 上午7:50, Edward Diener 写道:
There is a bug which in binutils which causes clang targeting
mingw-64/gcc on Windows to create a bad windows executable. The bug is
explained at https://sourceware.org/bugzilla/show_bug.cgi?id=23872 and
is fixed
There is a bug which in binutils which causes clang targeting
mingw-64/gcc on Windows to create a bad windows executable. The bug is
explained at https://sourceware.org/bugzilla/show_bug.cgi?id=23872 and
is fixed at
On 11/21/2018 3:47 PM, Martin Storsjö wrote:
On Wed, 21 Nov 2018, Edward Diener wrote:
On 11/21/2018 3:26 PM, Martin Storsjö wrote:
On Wed, 21 Nov 2018, Edward Diener wrote:
On 11/21/2018 9:53 AM, Ozkan Sezer wrote:
On 11/21/18, Edward Diener wrote:
[...]
Unfortunately this did not solve
On 11/21/2018 3:26 PM, Martin Storsjö wrote:
On Wed, 21 Nov 2018, Edward Diener wrote:
On 11/21/2018 9:53 AM, Ozkan Sezer wrote:
On 11/21/18, Edward Diener
wrote:
[...]
Unfortunately this did not solve the problem using clang-7.0 with the
gcc-8.1 backend. Most probably clang is using its
on Windows directly. The fact that it never has is always disappointing,
but of course this is not the fault of mingw-64/gcc.
BTW I do not think you were supposed to top-post.
Edward Diener 于 2018年11月21日周三 23:17写道：
On 11/21/2018 9:53 AM, Ozkan Sezer wrote:
On 11/21/18, Edward Diener wrote
On 11/21/2018 9:53 AM, Ozkan Sezer wrote:
On 11/21/18, Edward Diener wrote:
[...]
Unfortunately this did not solve the problem using clang-7.0 with the
gcc-8.1 backend. Most probably clang is using its own linker, rather
than the mingw-64/gcc linker, and this is causing the problem. In
clang
On 11/21/2018 4:57 AM, Ozkan Sezer wrote:
On 11/21/18, Edward Diener
wrote:
On 11/20/2018 11:55 PM, Ozkan Sezer wrote:
On 11/21/18, Edward Diener
wrote:
On 11/20/2018 10:50 PM, Ozkan Sezer wrote:
On 11/21/18, Edward Diener
wrote:
I am building an application using clang-7.0 targeting gcc
On 11/21/2018 4:57 AM, Ozkan Sezer wrote:
On 11/21/18, Edward Diener wrote:
On 11/20/2018 11:55 PM, Ozkan Sezer wrote:
On 11/21/18, Edward Diener
wrote:
On 11/20/2018 10:50 PM, Ozkan Sezer wrote:
On 11/21/18, Edward Diener
wrote:
I am building an application using clang-7.0 targeting gcc
On 11/20/2018 10:50 PM, Ozkan Sezer wrote:
On 11/21/18, Edward Diener wrote:
I am building an application using clang-7.0 targeting gcc with
mingw-64/gcc-8.1 as the backend. The application shows no errors
compiling or linking. When I try to debug the application I get the
messages from within
I am building an application using clang-7.0 targeting gcc with
mingw-64/gcc-8.1 as the backend. The application shows no errors
compiling or linking. When I try to debug the application I get the
messages from within gdb:
[New Thread 6432.0x1b38]
Mingw-w64 runtime failure:
Unknown pseudo
On 5/31/2017 2:38 PM, niXman wrote:
Edward Diener 2017-05-31 15:06:
When you try this yourself does everything work as
expected ?
Sure.
I have just installed MSYS2 from scratch.
I've installed only git(pacman -S git), cloned the mingw-builds project,
checked out to develop branch, and ran
On 5/31/2017 12:32 AM, niXman wrote:
Edward Diener 2017-05-31 07:26:
Not found level for patch
libiconv/0001-compile-relocatable-in-gnulib.mingw.patch, error=2
I do not understand what's going on...
please exec the 'pacman -S patch' cmd and rerun building again.
Same problem. I do not know
On 5/30/2017 10:59 PM, niXman wrote:
Edward Diener 2017-05-31 02:16:
I now get:
-> Checking for installed packages...
the following packages are not installed:
git,subversion,tar,zip,p7zip,make,patch,automake,autoconf,libtool,flex,bison,gettext,gettext-devel,wget,sshpass,texinfo
but
On 5/30/2017 2:45 PM, niXman wrote:
Edward Diener 2017-05-30 20:43:
My bad, sorry :(
Fixed in the develop branch.
Please pull and rerun.
I now get:
-> Checking for installed packages...
the following packages are not installed:
git,subversion,tar,zip,p7zip,make,patch,automake,autoc
On 5/30/2017 1:14 PM, niXman wrote:
Edward Diener 2017-05-30 19:48:
Yes.
Please remove completely the mingw-builds and the c:\mingw710 directory,
clone the mingw-builds again and checkout to the develop branch, and run
again:
./build --mode=gcc-7.1.0 --bootstrap --buildroot=/c/mingw710
On 5/30/2017 12:25 PM, niXman wrote:
Edward Diener 2017-05-30 18:10:
I pulled the latest but the same error still occurs.
Do you use the develop branch?
Yes.
--
Check out the vibrant tech community on one
On 5/29/2017 6:28 AM, niXman wrote:
Edward Diener 2017-05-29 05:26:
Following instructions I eventually get under MSYS2:
-> libiconv
--> download libiconv-1.14.tar.gz... done
--> unpack libiconv-1.14.tar.gz... done
--> patching...
Not found level for patch
libiconv/0001-compile
On 5/28/2017 5:06 PM, niXman wrote:
Edward Diener 2017-05-28 21:53:
That does not seem very limiting. ELF and PE/COFF covers all popular
object file formats on Linux and Windows respectively and surely just
about everyone not using VC++ uses DWARF rather than sjlj.
As I know, for windows
On 5/28/2017 10:15 AM, niXman wrote:
Edward Diener 2017-05-28 16:32:
2) libbacktrace can be part of a mingw-64 distribution but relies on
other files in that distribution ?
Yes.
Great !
I see in [2] below that there was a discussion of making libbacktrace
standalone, but it appears
On 5/28/2017 3:37 AM, niXman wrote:
Edward Diener 2017-05-27 23:37:
Hi,
Do I use msys2 in order to build libbacktrace ? When building do I
need to use the version of mingw-64/gcc for which I will be using
libbacktrace when I eventually use mingw-64/gcc as my compiler ? If I
need to do that do
On 5/27/2017 12:08 PM, niXman wrote:
Edward Diener 2017-05-27 18:40:
On 5/26/2017 11:03 PM, Vincent Torri wrote:
./configure --host=i686-w64-mingw32
or
./configure --host=i686-w64-mingw32
for respectively 32bits and 64bits support
Your configure commands are the same.
./configure --host
On 5/26/2017 11:03 PM, Vincent Torri wrote:
On Sat, May 27, 2017 at 12:14 AM, Edward Diener
<eldlistmaili...@tropicsoft.com> wrote:
On 5/26/2017 4:13 PM, Vincent Torri wrote:
Hello
On Fri, May 26, 2017 at 9:50 PM, Edward Diener
<eldlistmaili...@tropicsoft.com> wrote:
I would
Carl
2017-05-26 22:13 GMT+02:00 Vincent Torri <vincent.to...@gmail.com>:
Hello
On Fri, May 26, 2017 at 9:50 PM, Edward Diener
<eldlistmaili...@tropicsoft.com> wrote:
I would like to use a libbacktrace library for mingw-64/gcc. This is
used by
a new Boost library called stacktrac
On 5/26/2017 4:13 PM, Vincent Torri wrote:
Hello
On Fri, May 26, 2017 at 9:50 PM, Edward Diener
<eldlistmaili...@tropicsoft.com> wrote:
I would like to use a libbacktrace library for mingw-64/gcc. This is used by
a new Boost library called stacktrace to provide stack traces anywhere i
I would like to use a libbacktrace library for mingw-64/gcc. This is
used by a new Boost library called stacktrace to provide stack traces
anywhere in code in c++ when using GCC/MinGW/Clang on POSIX or Windows.
Does such a library exist for mingw-64/gcc on Windows ? If not can such
a library
On 5/19/2017 8:32 AM, niXman wrote:
> Edward Diener 2017-05-19 04:05:
>> How can I determine which version of libstdc++ corresponds to a
>> particular release of mingw-64/gcc ?
>
> Hi,
>
> Hmm.. at the moment it's impossible...
>
> But you can do this:
>
How can I determine which version of libstdc++ corresponds to a
particular release of mingw-64/gcc ?
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
On 4/9/2017 11:11 AM, Liu Hao wrote:
> On 2017/4/9 22:59, Edward Diener wrote:
>> Are you saying that I have to build gcc-6.3 myself on Windows, rather
>> than juat install it from mingw-w64-install, in order to use your library ?
> Yes. However I also build it constantly, which
On 4/9/2017 2:00 AM, Liu Hao wrote:
> On 2017/4/9 8:12, Edward Diener wrote:
>> 1) if mcfgthread replaces the mingw-64/gcc-6.3 threading library when used.
> It takes the place of winpthreads completely.
>
>> 2) if it replaces the mingw-64/gcc-6.3 threading library even wh
I have been able to build mcfgthread from
https://github.com/lhmouse/mcfgthread as an alternative to the gcc
threading library for mingw-64/gcc-6.3. The reason I want to use
mcfgthread is because the threading library for mingw-64/gcc-6.3 has a
bug as documented at the currently open bug
Please, please consider moving mingw-64 sources from SourceForge to some
better hosting server. SourceForge has morphed into a real disaster
where downloading files from it are met by numerous tactics of delay and
failure to force users to view their ads. Programming end-users should
not have
The mingw-w64-install.exe installer produces an error when trying to
install gcc-5.3. First the installer generates an incorrect default name
for the final directory, using 'rev1' while listing the gcc-5.3 as being
only revision 0 when choosing it. Then during the install a message box
occurs
The latest mingw-w64-install program is broken on all Window versions (
Vista, 7, 8.1 ) in which I tried to use it. Attempting to install any of
the releases listed always gives a ERROR Res message box and no files,
except for ones at the top level, get installed. Uninstalling from
Programs
On 8/5/2015 12:21 PM, K. Frank wrote:
Hello Edward!
On Wed, Aug 5, 2015 at 10:35 AM, Edward Diener
eldlistmaili...@tropicsoft.com wrote:
The latest mingw-w64-install program is broken on all Window versions (
Vista, 7, 8.1 ) in which I tried to use it.
I had a similar problem back
On 7/31/2015 12:27 PM, Óscar Fuentes wrote:
Edward Diener eldlistmaili...@tropicsoft.com
writes:
Calling a virtual member requires an access to the vtable of the class.
The vtable is defined on the dll that contains the class' code. If the
class is not exported, the vtable is not exported
On 7/31/2015 12:27 PM, Óscar Fuentes wrote:
Edward Diener eldlistmaili...@tropicsoft.com
writes:
Calling a virtual member requires an access to the vtable of the class.
The vtable is defined on the dll that contains the class' code. If the
class is not exported, the vtable is not exported
On 7/31/2015 7:45 AM, Óscar Fuentes wrote:
Edward Diener eldlistmaili...@tropicsoft.com
writes:
I'm not sure this is a GCC bug. Does the linker error also occur when
using static libraries, and when you dllexport the whole class as
opposed to the functions you're explicitly defining?
I
On 7/31/2015 8:52 AM, Óscar Fuentes wrote:
Edward Diener eldlistmaili...@tropicsoft.com
writes:
The code is far from being a minimal example, so I didn't look at it
all, but I see that the class ex_exception is not exported (EX_VISIBLE
expands to ... __visibility__(default)... and you set
On 7/31/2015 9:40 AM, Ruben Van Boxem wrote:
2015-07-31 13:07 GMT+02:00 Edward Diener eldlistmaili...@tropicsoft.com
mailto:eldlistmaili...@tropicsoft.com:
On 7/31/2015 6:05 AM, Ruben Van Boxem wrote:
2015-07-31 2:04 GMT+02:00 Edward Diener eldlistmaili...@tropicsoft.com
On 7/30/2015 2:48 AM, Gisle Vanem wrote:
Edward Diener wrote:
If I remove the declaration and definition of ex_xml_exception::what(),
since it is not needed, when linking I get:
throw_exception_ex.o:throw_exception_ex.cpp:(.rdata$_ZTV16ex_xml_exception[__ZTV16ex_xml_exception]+0x20
On 7/30/2015 10:48 AM, Óscar Fuentes wrote:
Edward Diener eldlistmaili...@tropicsoft.com
writes:
Another thing is to get some hints from a .map-file.
Add -Wl,--print-map,--sort-common,--cref file.map at the
of the link-cmd.
I could not find any documentation regarding the linker options
On 7/30/2015 10:48 AM, Óscar Fuentes wrote:
Edward Diener eldlistmaili...@tropicsoft.com
writes:
Another thing is to get some hints from a .map-file.
Add -Wl,--print-map,--sort-common,--cref file.map at the
of the link-cmd.
I could not find any documentation regarding the linker options
On 7/30/2015 2:48 AM, Gisle Vanem wrote:
Edward Diener wrote:
If I remove the declaration and definition of ex_xml_exception::what(),
since it is not needed, when linking I get:
throw_exception_ex.o:throw_exception_ex.cpp:(.rdata$_ZTV16ex_xml_exception[__ZTV16ex_xml_exception]+0x20
On 7/28/2015 8:49 AM, Ruben Van Boxem wrote:
2015-07-28 14:44 GMT+02:00 Edward Diener eldlistmaili...@tropicsoft.com
mailto: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
On 7/28/2015 8:49 AM, Ruben Van Boxem wrote:
2015-07-28 14:44 GMT+02:00 Edward Diener eldlistmaili...@tropicsoft.com
mailto: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
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
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:
On 7/27/2015 5:00 AM, Ruben Van Boxem wrote:
2015-07-27 8:54 GMT+02:00 Edward Diener eldlistmaili...@tropicsoft.com
mailto: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
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
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.
On 24 Jul 2015 13:31, Edward Diener eldlistmaili...@tropicsoft.com
mailto:eldlistmaili
create.
On 24 July 2015 at 16:03, Edward Diener eldlistmaili...@tropicsoft.com
mailto:eldlistmaili...@tropicsoft.com wrote:
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
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
On 7/4/2015 7:42 AM, Edward Diener wrote:
In the intrin.h header there is an include of x86intrin.h whenever
__GNUC__ is defined and we are compiling for x86 or x64.
If you look at the x86intrin.h header file you will see it includes
header files for all intrinsics. This leads to multiple
In the intrin.h header there is an include of x86intrin.h whenever
__GNUC__ is defined and we are compiling for x86 or x64.
If you look at the x86intrin.h header file you will see it includes
header files for all intrinsics regardless of whether the CPU feature
exists or not. This is true for
In the intrin.h header there is an include of x86intrin.h whenever
__GNUC__ is defined and we are compiling for x86 or x64.
If you look at the x86intrin.h header file you will see it includes
header files for all intrinsics. This leads to multiple typedefs using
the same name for __m64,
On 6/21/2015 10:43 PM, Óscar Fuentes wrote:
Edward Diener eldlistmaili...@tropicsoft.com
writes:
At the end, adapting your PATH setting works the best. Just a simple
.bat file solves the problem for those of us that need to constantly
experiment with multiple installs:
@rem mingw-w64-492
On 6/22/2015 4:50 PM, Óscar Fuentes wrote:
Edward Diener eldlistmaili...@tropicsoft.com
writes:
As I mentioned on other message on this thread, you must set PATH
anyways for executing the resulting binaries of your compilation. There
is no possible workaround for this, other than installing
On 6/22/2015 8:17 PM, Óscar Fuentes wrote:
Edward Diener eldlistmaili...@tropicsoft.com
writes:
Maybe your frustration does not allow you to understand what I wrote.
Please read it again. I expect some difficulty with the concept of
having multiple installs of the toolset, with varying
On 6/22/2015 12:02 PM, Óscar Fuentes wrote:
Edward Diener eldlistmaili...@tropicsoft.com
writes:
Apparently those programmers are not so inconvenienced as you are by
having to use methods like the .bat mentioned above. And I can assure
you that some of those programmers have quite a few gcc
On 6/21/2015 7:45 AM, LRN wrote:
On 21.06.2015 5:44, John E. / TDM wrote:
On 6/20/2015 8:25 PM, Edward Diener wrote:
Any timeframe for a gcc 5.1 release ? I noticed the latest mingw-64
install now has gcc-5.1, but it has the same hardcoded to c:\mingw
limitation which my OP is about.
My
.
The correct design of mingw-64 ( or mingw ) would have me only execute
the correct gcc and/or ld in the directory of the distribution to
compile/link a program, without having to do anything further.
2015-06-21 18:28 GMT+03:00 Edward Diener
eldlistmaili...@tropicsoft.com
mailto:eldlistmaili
. / TDM
tdra...@tdragon.net
mailto:tdra...@tdragon.net:
On 6/20/2015 8:25 PM, Edward Diener wrote:
Thanks ! I will look at your toolchains. I assume if all paths are
relative there is no need for any installation to go into or have a
symbolic link from c:\mingw.
Correct
Why does mingw-64, or the original mingw for that matter, consistently
hardcode include and lib search paths in their build for c:\mingw
instead of searching for include files and libraries relative to its
installation structure ?
Hardcoding absolute paths makes it so much harder running
On 6/20/2015 10:50 AM, LRN wrote:
On 20.06.2015 17:43, Edward Diener wrote:
Why does mingw-64, or the original mingw for that matter, consistently
hardcode include and lib search paths in their build for c:\mingw
instead of searching for include files and libraries relative to its
On 6/20/2015 5:08 PM, LRN wrote:
On 20.06.2015 19:21, Edward Diener wrote:
On 6/20/2015 10:50 AM, LRN wrote:
On 20.06.2015 17:43, Edward Diener wrote:
Why does mingw-64, or the original mingw for that matter, consistently
hardcode include and lib search paths in their build for c:\mingw
On 6/20/2015 9:38 PM, John E. / TDM wrote:
On 6/20/2015 7:30 PM, Edward Diener wrote:
But you are creating a product for Windows in which the entire product,
including the gcc compiler, standard C library, standard C++ library,
and whatever other tools are entailed in a mingw-64 release
On 6/20/2015 7:52 PM, JonY wrote:
On 6/21/2015 05:08, LRN wrote:
On 20.06.2015 19:21, Edward Diener wrote:
On 6/20/2015 10:50 AM, LRN wrote:
On 20.06.2015 17:43, Edward Diener wrote:
Why does mingw-64, or the original mingw for that matter, consistently
hardcode include and lib search paths
On 12/24/2014 11:29 PM, Óscar Fuentes wrote:
Edward Diener eldlistmaili...@tropicsoft.com
writes:
I am seeing an out of memory message of:
cc1plus.exe: out of memory allocating 65536 bytes
when compiling code using mingw-64 from gcc-4.8.1, gcc-4.8.2, gcc-4.8.3,
gcc-4.9.0, and gcc-4.9.1
I am seeing an out of memory message of:
cc1plus.exe: out of memory allocating 65536 bytes
when compiling code using mingw-64 from gcc-4.8.1, gcc-4.8.2, gcc-4.8.3,
gcc-4.9.0, and gcc-4.9.1. Nor is this just a mingw-64 problem as I am
seeing the same error when compiling the same code with
How do I debug a command line application built with Mingw64 on Windows
? Is there a gdb debugger that works natively under Windows or do I need
something else ?
--
Slashdot TV.
Video for Nerds. Stuff that matters.
87 matches
Mail list logo
