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 a
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 mos
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
rrectly,
especially Liu Hao. I do appreciate your 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()...
pat
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'
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
Mingw-w64-public@li
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 could
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 could
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 at
ms 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 at
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
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=73af69e74974eaa155ee
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
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 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 with
mingw-64/gcc-8.1 as the backend. The application shows no errors
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 re
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, an
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
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 of
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-re
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 that
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
wrote:
On 5/26/2017 4:13 PM, Vincent Torri wrote:
Hello
On Fri, May 26, 2017 at 9:50 PM, Edward Diener
wrote:
I would like to use a libbacktrace library for mingw-64/gcc. This is used
by
a new
Carl
2017-05-26 22:13 GMT+02:00 Vincent Torri :
Hello
On Fri, May 26, 2017 at 9:50 PM, Edward Diener
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 in
code in c++ when using GCC/MinGW/Cl
On 5/26/2017 4:13 PM, Vincent Torri wrote:
Hello
On Fri, May 26, 2017 at 9:50 PM, Edward Diener
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 in
code in c++ when using GCC/MinGW/Clang
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 be
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! http://sdm.link/s
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 report
When trying to compile a project in MSYS2 using mingw-64/gcc I get this
error:
"Building shared library...
x86_64-w64-mingw32-gcc -x c-header -DHAVE_CONFIG_H -Wall -Wextra
-pedantic -pedantic-errors -Werror -Wwrite-strings -Wconversion
-Wsign-conversion -Wsuggest-attribute=noreturn -Winvalid-pc
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 t
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 w
On 8/5/2015 4:35 PM, niXman wrote:
> x86_64|posix|sjlj |rev0
> |http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.3/threads-posix/sjlj/x86_64-4.9.3-release-posix-sjlj-rt_v4-rev0.7z
> i686 |posix|sjlj |rev0
> |http://sourceforge.net/p
On 8/5/2015 12:21 PM, K. Frank wrote:
> Hello Edward!
>
> On Wed, Aug 5, 2015 at 10:35 AM, Edward Diener
> 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 proble
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 7/31/2015 12:27 PM, Óscar Fuentes wrote:
> Edward Diener
> 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 v
On 7/31/2015 12:27 PM, Óscar Fuentes wrote:
> Edward Diener
> 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 v
On 7/31/2015 9:40 AM, Ruben Van Boxem wrote:
> 2015-07-31 13:07 GMT+02:00 Edward Diener <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 <mailto:eld
On 7/31/2015 8:52 AM, Óscar Fuentes wrote:
> Edward Diener
> 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
On 7/31/2015 7:45 AM, Óscar Fuentes wrote:
> Edward Diener
> 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&#
On 7/31/2015 6:05 AM, Ruben Van Boxem wrote:
> 2015-07-31 2:04 GMT+02:00 Edward Diener <mailto:eldlistmaili...@tropicsoft.com>>:
>
> On 7/30/2015 10:48 AM, Óscar Fuentes wrote:
> > Edward Diener <mailto:eldlistmaili...@tropicsoft.com>>
> >
On 7/30/2015 10:48 AM, Óscar Fuentes wrote:
> Edward Diener
> 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 coul
On 7/30/2015 10:48 AM, Óscar Fuentes wrote:
> Edward Diener
> 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 coul
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
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
On 7/28/2015 8:49 AM, Ruben Van Boxem wrote:
> 2015-07-28 14:44 GMT+02:00 Edward Diener <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
> >
On 7/28/2015 8:49 AM, Ruben Van Boxem wrote:
> 2015-07-28 14:44 GMT+02:00 Edward Diener <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
> >
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. Th
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$_ZTVN5boost7archive2
On 7/27/2015 5:00 AM, Ruben Van Boxem wrote:
> 2015-07-27 8:54 GMT+02:00 Edward Diener <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
> <mailto:
On 7/24/2015 11:13 AM, Ruben Van Boxem wrote:
> 2015-07-24 17:03 GMT+02:00 Edward Diener <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
the instantiation from the
shared library I create.
>
> On 24 July 2015 at 16:03, Edward Diener <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
>
On 7/24/2015 11:13 AM, Ruben Van Boxem wrote:
> 2015-07-24 17:03 GMT+02:00 Edward Diener <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
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" <mailto:eldlistmaili.
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
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 gcc
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
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, __m128,
On 6/22/2015 8:17 PM, Óscar Fuentes wrote:
> Edward Diener
> 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 th
On 6/22/2015 4:50 PM, Óscar Fuentes wrote:
> Edward Diener
> 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,
On 6/22/2015 12:02 PM, Óscar Fuentes wrote:
> Edward Diener
> 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 programm
On 6/21/2015 10:43 PM, Óscar Fuentes wrote:
> Edward Diener
> 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:
>
On 6/21/2015 8:22 PM, Óscar Fuentes wrote:
> Yaron Keren
> writes:
>
>>> Why in the world should I have to put anything in my PATH if these
>>> releases are self-enclosed ? I am executing gcc from the exact same
>>> directory where the libwinpthread-1.dll exists.
>>
>> I misunderstood you, thought
ing to the one I
execute.
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
>
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
&g
ms.
>
> 2015-06-21 5:44 GMT+03:00 John E. / TDM
> <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
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
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 tha
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 inclu
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 libr
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 differ
On 12/24/2014 11:29 PM, Óscar Fuentes wrote:
> Edward Diener
> 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, gc
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 min
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.
h
94 matches
Mail list logo
