-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/30/2010 11:44, Xiaofan Chen wrote:
On Thu, Sep 30, 2010 at 9:43 AM, Dongsheng Song
dongsheng.s...@gmail.com wrote:
Maybe there have another solution:
S1: the intersection of XP and 2k3 symbols in msvcrt.dll
S2: the intersection of VISTA and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/27/2010 21:10, Simon Josefsson wrote:
Simon Josefsson si...@josefsson.org writes:
I have been using the makebuildroot-test.mk script from the experimental
branch, and it works fine for me (32+64 bit GCC 4.5.1) if I do
touch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/1/2010 07:31, Xiaofan Chen wrote:
On Wed, Sep 29, 2010 at 9:52 PM, JonY jo...@users.sourceforge.net wrote:
On 9/29/2010 21:39, Dongsheng Song wrote:
But we can not ensure third party software DO NOT call those functions,
so we must drop them
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/23/2010 23:39, Luis Lavena wrote:
Hello,
I was attempting to port a program from Linux to Windows where certain
functions are exported and used by plugin/extensions. Since the
program is not a shared object, there is no import library to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/28/2010 08:12, Sven Köhler wrote:
Hi,
the current bluetooth headers don't compile. Duplicate definitions,
structs references structs later in the file, obvious mistakes that were
presumably copied from the MSDN site, etc.
(see
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/4/2010 06:57, Larry Robinson wrote:
I'm trying to install the w64 compiler on a Ubuntu Linux machine,
following the instructions at:
http://sourceforge.net/apps/trac/mingw-w64/wiki/Cross Win32 and Win64
compiler
I am unable to build the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/15/2010 00:55, Andy Koppe wrote:
On 14 December 2010 16:41, Dmitrijs Ledkovs wrote:
On 14 December 2010 13:20, Andy Koppe wrote:
What is GNU triplet for MSYS then? How different it is from the MinGW
tripplet? Is it just a different ABI then?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/16/2010 00:08, Dmitrijs Ledkovs wrote:
On 15 December 2010 13:36, NightStrike nightstr...@gmail.com wrote:
On 12/14/10, Dmitrijs Ledkovs dmitrij.led...@ubuntu.com wrote:
$ cat dpkg/ostable
# This file contains the table of known operating
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/6/2011 22:30, Vladimir Simonov wrote:
On 01/06/2011 05:21 PM, Nick Clifton wrote:
2. replace off_t, stat, fstat with bn_off_t, bn_stat,
bn_fstat (bn - means binutils) in all sources and define
them as stat64, fstat64 in config.h (or some
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/6/2011 23:08, JonY wrote:
On 1/6/2011 22:30, Vladimir Simonov wrote:
On 01/06/2011 05:21 PM, Nick Clifton wrote:
2. replace off_t, stat, fstat with bn_off_t, bn_stat,
bn_fstat (bn - means binutils) in all sources and define
them as stat64
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/20/2011 10:35, Martin Mitáš wrote:
Hi all,
please note there is a project using mingw-w64 as its primary
development platform: mCtrl.
It's a library of Windows user interface controls. It's still relatively
young but (as I hope)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/20/2011 23:22, Andrei Pozolotin wrote:
Hello;
please add to your list:
Projects successfully using MinGW-w64
http://mingw-w64.sourceforge.net/
my project also: barchart-udt
Barchart-UDT is a Java wrapper
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/25/2011 03:15, Luis Lavena wrote:
Hello,
Recently I've started to work on compiling FreeTDS library with MinGW
(and mingw-w64):
http://freetds.org/
Thanks to autoconf tools and the amazing work of FreeTDS developers,
this pretty much
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/28/2011 09:29, Dock, Dion wrote:
I've searched and searched for an answer but maybe my Google-fu is weak.
We produce a library with VS 2005. When I try to link it into a test program
using g++, I get lots of messages like
...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/28/2011 22:49, Georgi Petrov wrote:
Hi,
I had a conversation with JonY yesterday and he invited me to will
help you to create better working and tested EVR (Enhanced Video
Renderer) evr.h header file. As I look at the Windows SDK headers, I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/28/2011 23:23, Andrew Dunstan wrote:
On 01/28/2011 08:09 AM, JonY wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/28/2011 18:19, Andrew Dunstan wrote:
configure:7071: checking for zic
configure:7104: result: no
configure
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/28/2011 23:05, JonY wrote:
On 1/28/2011 22:49, Georgi Petrov wrote:
Hi,
I had a conversation with JonY yesterday and he invited me to will
help you to create better working and tested EVR (Enhanced Video
Renderer) evr.h header file. As I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/30/2011 10:39, Dongsheng Song wrote:
Hi JonY,
In r4001, you add 'misc/mbwc.c' to mingw-w64-crt/Makefile.am, but I can not
find mbwc.c, only
found misc/mingw_mbwc_convert.c.
Thanks. Trunk is now fixed.
-BEGIN PGP SIGNATURE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/6/2011 21:27, Chris Sutcliffe wrote:
Hi All,
I've run in to a crash issue in my app when compiled with
i686-w64-mingw32, yet it works fine when compiled with x64-w64-mingw32
or MSVC++ (both as 32-bit and 64-bit). I'm using the mingw-w64
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/9/2011 05:53, Paul Leder wrote:
Sorry if this is slightly off-topic - I'm trying to build a standard
Linux autoconf project for Windows using mingw-w32-1.0-bin_i686-linux.
Does anyone happen to know what 'configure' invocation I should use
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/10/2011 22:27, Andrew Dunstan wrote:
The PostgreSQL project http://www.postgresql.org/ recently added
support for building with MinGW-w64.
cheers
andrew
Thanks, PostgreSQL added.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/16/2011 00:18, K. Frank wrote:
Hi Ben!
On Tue, Feb 15, 2011 at 10:57 AM, Ben Key bke...@gmail.com wrote:
Hello K. Frank,
Thanks for your response. I asked if Cygwin was required because it is not
clear what I should download. In the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/23/2011 03:40, GABRIELE FERRERI wrote:
Hi all,
can anyone add YafaRay in the list of projects succefully using MinGW-W64?
Here the official link:
http://www.yafaray.org/
Cheers,
Gabriele
Hi,
Yafaray now added.
-BEGIN PGP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/23/2011 18:04, GABRIELE FERRERI wrote:
Hi all,
I'm trying to build Blender project with MinGW-W64 and I recently experience
some issues:
..\..\lib\libbf_intern_ghost.a(GHOST_WindowWin32.cpp.obj):GHOST_WindowWin32.cpp:(.text+0x179b):
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/27/2011 01:04, Nick Echidna wrote:
Hello all,
I am trying to use the windows filtering platform on mingw but I can't find
where on the mingw's Win32 API it is. Is it there at all or do I have to use
the windows SDK? The bad think is that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/1/2011 08:19, Dock, Dion wrote:
-Original Message-
From: Jon [mailto:10wa...@gmail.com] On Behalf Of JonY
Sent: Monday, February 14, 2011 4:36 PM
To: Dock, Dion
Cc: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/1/2011 08:27, Dock, Dion wrote:
Why doesn't MinGW-64, etc. provide equivalents to Microsoft's secure
functions, for example, strcat_s, strncpy_s, etc.? I understand they're not
part of the C standard, but the distribution includes various
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/10/2011 23:18, K Shen wrote:
Hi,
I posted messages earlier about the problem I had with a binary MinGW-w64
(for cross-compiling to Win64 on Linux), I assume this binary is built from
the trunk branch of MinGW, and Kai Tietz suggested that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/4/2011 12:39, James K Beard wrote:
I've put up a Wiki page on how I used downloads of the binaries for both
the 1.0 daily builds and the bleeding edge daily builds to successfully
generate Windows 32-bit and 64-bit binaries:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/23/2011 22:06, James K Beard wrote:
Jon: The simplest and quite possibly the most efficient way to implement a
standard function library in BCD decimal arithmetic is to convert to IEEE
standard double precision (or, if necessary, quad
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/30/2011 23:21, Earnie wrote:
Marcin M. wrote:
hi
i want to build the 64 bit (x86_64-pc-mingw64) mingw on linux
but it wants the package mingwrt-3.18-mingw64.tar.gz which has 404 error
while downloading and i can't find it anywhere
could you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/3/2011 22:07, James K Beard wrote:
A quick glance through the document seems to tell us that the decimal
arithmetic will incorporate checks to ensure that any rounding in binary
floating point does not compromise the accuracy of the final
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/6/2011 03:23, Marcin M. wrote:
so which triplet should i type?
--
Pozdrawiam,
Marcin Mielniczuk
If possible, use x86_64-w64-mingw64 when using mingw-w64 headers/crt,
note the w64 vendor key.
You still haven't explained where or what
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/9/2011 23:03, K. Frank wrote:
What, then, would be the advantage of using decimal floating-point?
I don't really know the history or what people were thinking when
they built those early decimal floating-point systems, but there is
a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/10/2011 01:54, James K Beard wrote:
I think the long term solution is to implement the decimal arithmetic
keywords with an open mind. Special requirements, like extremely long
decimal words (DECIMAL128 == 128 digits?) may require
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/11/2011 01:47, Jason wrote:
Hi
MPIR a fork of GMP now fully runs under MinGW64 see
http://www.mpir.org/
Thanks
Jason
Thanks, now added.
I am curious, how much does it inherit from GMP? Particularly the build
system. Is it also
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/11/2011 20:20, Jason wrote:
On Monday 11 April 2011 11:27:08 JonY wrote:
On 4/11/2011 01:47, Jason wrote:
Hi
MPIR a fork of GMP now fully runs under MinGW64 see
http://www.mpir.org/
Thanks
Jason
Thanks, now added.
I am curious, how
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/16/2011 15:23, Jim Michaels wrote:
Could the compiler writes for personal builds and auto builds please redesign
the compilers so that the 64-bit compilers use different library names for
their
dll's than the 32-bit counterparts? you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/18/2011 17:04, Ruben Van Boxem wrote:
Hi,
It seems on my setup (MSYS+sezero 64-bit GCC 4.5.2), GMP 5.0.1 fails
to run the C++ tests when --enable-cxx is passed to configure and I
run make check from the main build directory. I ran them
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/22/2011 08:22, Dock, Dion wrote:
Is it possible to create a library with MinGW64's gcc and use Cygwin's gcc to
link it into a binary? Or is this breaking the use the same compiler for
all parts rule of thumb?
I've created a 32 bit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/22/2011 00:38, Ruben Van Boxem wrote:
Hi,
I know this is a long shot, but how difficult would it be to set up a basic
Cmake build system for the mingw-w64 headers and crt? I'd like to know, so I
can test self-hosting Clang and see how I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/22/2011 16:05, Ruben Van Boxem wrote:
I'd like to rid the whole thing of bash, so I can build from windows cmd,
just like clang. It should also speed things up (MSYS is very slow)
Ruben
That is hardly a reason to make and maintain two
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/22/2011 19:58, NightStrike wrote:
I think you misunderstand my intention (and are bound to not answer my
question, it seems). All I need is a description of what is done by the
build system (ie what files are compiled into what and which
On 4/22/2011 22:33, Ruben Van Boxem wrote:
Op 22 apr. 2011 16:25 schreef Mario Emmenlauer ma...@emmenlauer.de het
volgende:
Hi,
On 04/22/2011 11:15 AM, JonY wrote:
You'll likely see an improvement by running make in parallel.
Is that possible with MinGW? I have tried various guides
On 4/23/2011 15:34, fka...@googlemail.com wrote:
Hi,
My 32 bit mingw cross compiler works, but the 64 version
fails when linking system libraries.
I've set up a x86_64-pc-mingw32 64 bit cross compiler (under
gentoo linux with paludis packet manager).
I can compile 64 bit code, however,
On 4/26/2011 02:11, Jon wrote:
I've started evaluating mingw-w32-1.0-bin_i686-mingw_20110422.zip as a
toolchain where I typically use the 32-bit 4.5.2 version from
http://tdm-gcc.tdragon.net/
The build environment uses LIBRARY_PATH and works fine with tdm-gcc 4.5.2 but
fails with the
On 4/26/2011 22:20, Jon wrote:
I've read the
https://sourceforge.net/mailarchive/message.php?msg_id=25062006 thread and
would like to know the latest mingw-w64 recommendations for using
LIBRARY_PATH. While I would like to be able to use LIBRARY_PATH as I do
with other MinGW-based
On 4/28/2011 03:26, Jon wrote:
Is LIBRARY_PATH ignored in my case because i686-w64-mingw32-gcc.exe thinks
it's cross-compiling between i686-w64-mingw32 and i686-pc-mingw32? My
understanding is LIBRARY_PATH is ignored when cross-compiling but not other
cases, and I want to make sure I get
On 4/28/2011 22:56, Jon wrote:
Is LIBRARY_PATH ignored in my case because i686-w64-mingw32-gcc.exe
thinks it's cross-compiling between i686-w64-mingw32 and i686-pc-mingw32?
My understanding is LIBRARY_PATH is ignored when cross-compiling but not
other cases, and I want to make sure I get
On 5/1/2011 22:03, James K Beard wrote:
Now, about that math library problem -- it seems to me that asking full
mantissa accuracy and agreement for 32-bit and 64-bit floating point is
reasonable. Differences between FPUs makes full mantissa accuracy and
agreement at 80 bits a bit of a
On 5/2/2011 22:48, Ruben Van Boxem wrote:
I never implied your ears were defective. And I meant no offence, but I did
not get any reaction so I thought I'd stir things up a bit. You pursued a
better solution, which is great of course! Thanks for that.
Still leaves the /mingw directory and
On 5/3/2011 04:05, Kai Tietz wrote:
2011/5/2 Peter Rockett p.rock...@sheffield.ac.uk:
On 02/05/2011 17:00, Keith Marshall wrote:
On 02/05/11 16:30, Charles Wilson wrote:
So, we would like sqrt (x) and pow (x, 0.5) to agree.
The point below about off-topic diversions into precision is valid
On 5/4/2011 00:06, Bj Raz wrote:
I am trying to build a cross compiler to build Windows exes on linux,
I have looked for help and found this:
http://gcc.gnu.org/ml/gcc-bugs/2009-04/msg01029.html
this messages gives a document on mingw-w64-howto-build that no
longer exists on
On 5/8/2011 06:39, Jonas noLastName wrote:
Can you tell us which mingw64 compiler you used?
x86_64-w64-mingw32-gcc.exe (GCC)
4.5.2Using:https://mingw-w64.svn.sourceforge.net/svnroot/mingw-w64/branches/releases/v1.0revision
4166Need anything else just ask.
I have send another message
On 5/16/2011 15:35, Simon de Graaf wrote:
Hi,
Recently, i downloaded new versions of Windows 32 and 64 bit
cross-compilers (automatic builds mingw-w32-bin_i686-linux_20110501 and
mingw-w64-bin_i686-linux_20110423) and found that include file
unistd.h now contains function usleep. Thus,
On 5/17/2011 09:54, JonY wrote:
On 5/16/2011 15:35, Simon de Graaf wrote:
Hi,
Recently, i downloaded new versions of Windows 32 and 64 bit
cross-compilers (automatic builds mingw-w32-bin_i686-linux_20110501 and
mingw-w64-bin_i686-linux_20110423) and found that include file
unistd.h now
On 5/18/2011 16:20, Jean-Claude Beaudoin wrote:
Hello MinGW-w64 folks,
ManKai Common Lisp (MKCL) http://common-lisp.net/project/mkcl/ has been
using MinGW-w64 as the basis of its Windows 7 64 bits version for more than
a year now and has yet to report its first MinGW-w64 related bug. Great
On 5/24/2011 23:54, Ozkan Sezer wrote:
Hi all:
What makes the User Access Control thing of vista or w7 to trigger?
If I compile my program for x64 using mingw-w64, the program runs
just fine. If I compile it for x86 either by mingw or mingw-w64 and
run it on vista or w7 x64 version,
On 6/1/2011 13:53, Kai Tietz wrote:
Patch is ok.
Thanks,
Kai
Anybody planning to apply this patch or should I do it?
0xED74C077.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
On 6/9/2011 07:24, NightStrike wrote:
On 5/21/11, Ozkan Sezer seze...@gmail.com wrote:
On Sat, May 21, 2011 at 10:09 AM, Kai Tietz ktiet...@googlemail.com wrote:
2011/5/21 Ozkan Sezer seze...@gmail.com:
On Sat, May 21, 2011 at 9:56 AM, Kai Tietz ktiet...@googlemail.com
wrote:
2011/5/21
On 6/22/2011 23:26, Farkas Levente wrote:
On 06/22/2011 03:44 PM, Kai Tietz wrote:
2011/6/22 Farkas Levente lfar...@lfarkas.org:
On 06/22/2011 03:33 PM, Ozkan Sezer wrote:
On Wed, Jun 22, 2011 at 4:22 PM, Farkas Levente lfar...@lfarkas.org
wrote:
On 06/22/2011 03:07 AM, JonY wrote:
On 6/21
On 6/26/2011 20:27, Farkas Levente wrote:
On 06/26/2011 01:53 PM, JonY wrote:
On 6/26/2011 19:41, Farkas Levente wrote:
yes it seem the headers are finally good, but now i've got some
problem during link:
CCLD
On 7/4/2011 08:49, Bj Raz wrote:
/tools/x86_64-w64-mingw32/bin/ld cannot find dllcrt2.o: No such file
or directory
/tools/x86_64-w64-mingw32/bin/ld cannot find crtbegin.o: No such file
or directory
/tools/x86_64-w64-mingw32/bin/ld cannot find crtend.o: No such file or
directory
collect2:
On 7/5/2011 10:51, Sisyphus wrote:
During make check:
libtool: link:
x86_64-w64-mingw32-gcc -O2 -pedantic -m64 -std=gnu99 -mtune=k8 -march=k8 -o
t-locale.exe t-locale.o ../../tests/.libs/libtests.a
/c/_64/comp/gmp-5.0.90-20110704/.libs/libgmp.a
On 7/5/2011 17:29, Bj Raz wrote:
On Tue, Jul 5, 2011 at 5:05 AM, Bj Raz whitequill...@gmail.com wrote:
On Tue, Jul 5, 2011 at 4:58 AM, Bj Raz whitequill...@gmail.com wrote:
On Tue, Jul 5, 2011 at 4:03 AM, JonY jo...@users.sourceforge.net wrote:
On 7/5/2011 15:04, Bj Raz wrote:
On Mon, Jul
On 7/6/2011 01:25, Bj Raz wrote:
No, I'm on linux, building an environment that will make a another
envronment that I will use on Windows.
In that case, try strace to see why it isn't starting. I thought you
don't have Linux running because its too new.
One would assume you already have a
On 7/6/2011 14:45, Torbjorn Granlund wrote:
JonY writes:
GMP is misusing the --host option for detecting CPU optimization levels
I don't think it is doing that. It used -O2 for all CPUs, I think.
I mean for ASM codes, adding -O2 implicitly isn't an issue.
(Why not just use
On 7/6/2011 16:57, Bj Raz wrote:
I'm not building with glibc, I'm using msvc in my build. So I can
compiler
Windows '.exe's' on linux.
Which regardless of the ranlib error the c compiler works fine when I use
it. though I'd prefer not having the ranlib error.
Cause when I start to try and
On 7/6/2011 21:02, Alen Skondro wrote:
I'm having problems creating a cross compiler (host=i686-pc-mingw32
--target=i686-w64-mingw32)
I use the mingw console on windows.
The following error occures while building ./i686-w64-mingw32/libgcc
(config.log):
configure:3039: $? = 1
On 7/8/2011 04:56, Alen Skondro wrote:
Hello,
I'm stuck again.
After successfully building gcc 4.6 targeting only i686-w64-mingw32 I'm
getting errors while creating a cross compiler for multilib target
(i686-w64-mingw32 + x86_64-w64-mingw32).
binutils is configure like this:
On 7/8/2011 07:49, Geoff Hilton wrote:
Where exactly would I place the mingw32 directory located inside your
i686-w64-mingw32-gcc-4.6.2_rubenvb.7z file? Those folders structures
feel so repetitious that it gets confusing (possibly because I can't
remember whether or not the current install
On 7/8/2011 13:26, Kai Tietz wrote:
2011/7/8 JonY jo...@users.sourceforge.net:
On 7/8/2011 04:56, Alen Skondro wrote:
Hello,
I'm stuck again.
After successfully building gcc 4.6 targeting only i686-w64-mingw32 I'm
getting errors while creating a cross compiler for multilib target
(i686
On 7/11/2011 14:08, Maxime Lecourt wrote:
Hello,
I want to install mingw64 on my windows seven computer.
I don't have autotools, but I have cmake installed.
Is there somewhere a version of Mingw64 with CMake scripts ?
And can I compile mingw64 using mingw32 compiler ?
Regards,
Maxime
On 8/8/2011 21:54, Jon wrote:
2) Add prefix-stripped (eg - gcc) exes to the download to accompany the
prefixed (eg - i686-w64-mingw32-gcc) exes.
Why?
Not all downstream packages or users play well with the prefixing
On 8/8/2011 22:43, Ozkan Sezer wrote:
On Mon, Aug 8, 2011 at 5:40 PM, Kai Tietz ktiet...@googlemail.com wrote:
Hello everybody,
I am pleased to be able to tell you, that we could convience Ruben to
become our new packager-maintainer for pre-build toolchains for
releases. Please give him a
On 8/9/2011 22:19, Ruben Van Boxem wrote:
2011/8/9 Earnie ear...@users.sourceforge.net:
Ruben Van Boxem wrote:
Heh, the solution is to use autotools, all the way, never
compromise on quality. There are a lot of packages too pretentious
to use autotools...
Bull shit. Hardly a solution.
On 8/10/2011 01:12, Jon wrote:
On 8/9/2011 22:19, Ruben Van Boxem wrote:
2011/8/9 Earnie ear...@users.sourceforge.net:
Ruben Van Boxem wrote:
Heh, the solution is to use autotools, all the way, never
compromise on quality. There are a lot of packages too pretentious
to use autotools...
On 8/16/2011 20:57, Ruben Van Boxem wrote:
Hi,
Since Kai fixed the winpthreads/libgomp problem (Kai, you are a
hero!), I have been trying to finalize the winpthreads build stuff in
my scripts and testing, which lead to two issues:
1. I can't link to winpthreads statically, better said, if
wrote:
Op 16 aug. 2011 16:13 schreef JonY jo...@users.sourceforge.net het
volgende:
On 8/16/2011 20:57, Ruben Van Boxem wrote:
Hi,
Since Kai fixed the winpthreads/libgomp problem (Kai, you are a
hero!), I have been trying to finalize the winpthreads build stuff in
my scripts and testing
On 8/18/2011 23:44, Sam Steingold wrote:
Hi,
I cannot
#include ddk/ntifs.h
because /usr/i686-w64-mingw32/sys-root/mingw/include/ddk/ntifs.h contains
#include ntddk.h
and ntddk.h actually lives in ddk, i.e., it should be
#include ddk/ntddk.h
after I aplly these two patches:
---
On 8/19/2011 03:10, Frédéric Bron wrote:
If you are using a mingw* compiler, then you're not using Boost on
Cygwin.
I am. Up to now, I have a dual cygwin installation 1.5/1.7 because I
was unable to use boost nor wxwidgets with 1.7.
I recently decided to make another effort to build boost
On 8/19/2011 07:37, Sam Steingold wrote:
* JonY wb...@hfref.fbheprsbetr.arg [2011-08-19 06:39:03 +0800]:
You are supposed to use -I to add the ddk path to gcc.
how?
I mean, -Iddk does not work because I do not have ddk directory in my
build directory.
how do I ask i686-w64-mingw32-gcc
On 8/19/2011 20:00, Corinna Vinschen wrote:
On Aug 19 18:19, JonY wrote:
On 8/19/2011 07:37, Sam Steingold wrote:
* JonY wb...@hfref.fbheprsbetr.arg [2011-08-19 06:39:03 +0800]:
You are supposed to use -I to add the ddk path to gcc.
how?
I mean, -Iddk does not work because I do not have
On 8/22/2011 09:26, Sam Steingold wrote:
* Kai Tietz xgvrgm70-tZ/lr1r23zja+odd9eo...@choyvp.tznar.bet [2011-08-20
09:31:47 +0200]:
2011/8/20 JonY jon_y-rn4veauk+akrv+lv9mx5uipxlwaov...@public.gmane.org:
/usr/i686-w64-mingw32/sys-root/mingw/include/ddk/ntddk.h:2922:26:
error: redeclaration
On 8/23/2011 06:18, Charles Wilson wrote:
On 8/22/2011 5:13 PM, Sam Steingold wrote:
PS. Why are cygwin/mingw and msys/mingw so different?
They are not different. In fact, 'cygwin/mingw.org' and 'msys/mingw.org'
are identical (except for the emulation environment under which they
run: msys
On 9/2/2011 12:33, Dongsheng Song wrote:
On Fri, Sep 2, 2011 at 11:56, Dongsheng Song dongsheng.s...@gmail.com wrote:
On Thu, Sep 1, 2011 at 19:08, niXman i.nix...@gmail.com wrote:
Hi all!
Any ideas about the nanosleep() function?
Maybe it shoul be implemented into mingw-w64-crt ?
Same
On 9/3/2011 12:50, Jim Michaels wrote:
I *DO* target for windows 7/8/vista/xp/98 etc for using my windows xp machine
all the time (I am a developer, I target for platforms I don't have,
especially since I don't have 10 machines with varying OS's lying about). it
would be extremely useful
On 9/3/2011 14:26, Dongsheng Song wrote:
Kai, Ozkan, any objections?
From: Dongsheng Song dongsh...@apache.org
---
mingw-w64-crt/Makefile.am |2 +
mingw-w64-crt/misc/nanosleep.c| 67
mingw-w64-crt/testcases/t_nanosleep.c | 92
On 9/4/2011 14:56, Dongsheng Song wrote:
---
mingw-w64-crt/misc/clock.c | 234
+++
mingw-w64-crt/testcases/t_clock_getres.c| 62 +++
mingw-w64-crt/testcases/t_clock_gettime.c | 60 +++
mingw-w64-crt/testcases/t_clock_nanosleep.c |
On 9/8/2011 18:25, C++0X wrote:
For example, executable of the following produced by
i686-w64-mingw32-gcc-4.7.0-stdthread_rubenvb.7z crashes, however,
others are fine.
Moreover, some strange behaviors are observed when using Boost.Filesystem.
--This is a
On 9/18/2011 14:10, Kyle wrote:
On 9/18/2011 1:01 AM, NightStrike wrote:
You're going to have to provide a lot more detail, then, about your
build procedure. We made a script to do it all for you to make the
process easier to understand and troubleshoot. If you are doing it
yourself, you
On 9/19/2011 02:33, Kyle wrote:
On 9/18/2011 7:17 AM, JonY wrote:
Objective C seems to be affecting your issue.
Any chance of a quick fix?
BTW, please use --enable-fully-dynamic-strings for gcc. I can't
emphasize this point enough to anybody rolling their own mingw-w64 gcc
binaries.
I
On 9/19/2011 06:59, xunxun wrote:
于 2011/9/19 2:33, Kyle 写道:
I used to use that option but I believe it was removed. grep -ir
enable-fully-dynamic-strings * on the source dir turns up nothing.
It's a typo.
It should be enable-fully-dynamic-string, and it can be found in
On 9/19/2011 21:25, NightStrike wrote:
On Sun, Sep 18, 2011 at 7:28 PM, JonY jo...@users.sourceforge.net wrote:
On 9/19/2011 06:53, Kyle wrote:
On 9/18/2011 6:43 PM, JonY wrote:
On 9/19/2011 02:33, Kyle wrote:
I used to use that option but I believe it was removed. grep -ir
enable-fully
On 9/21/2011 02:15, niXman wrote:
Hi all!
When i try to build winpthreads from SVN I get errors.
Errors in attached file.
niXman.
Did you try with using trunk headers?
signature.asc
Description: OpenPGP digital signature
On 9/24/2011 00:36, Jon wrote:
Currently the binary archives from mingw.org and the automated builds from
this project that I use put their artifacts in the top level of the archive,
while the rubenvb builds place their artifacts in an intermediate 'mingw32'
directory.
This difference
On 9/24/2011 08:33, Jon wrote:
Currently the binary archives from mingw.org and the automated builds
from this project that I use put their artifacts in the top level of the
archive, while the rubenvb builds place their artifacts in an intermediate
'mingw32' directory.
This difference
On 9/28/2011 05:44, Alen Skondro wrote:
Hello,
I have issues with linking dynamically with libstdc++.
Static linking works.
gcc is configured with ../gcc/configure --disable-multilib
--prefix=/d/pwgcc-native --disable-nls --target=i686-w64-mingw32
--host=i686-w64-mingw32
On 10/2/2011 13:42, Jim Michaels wrote:
checking for gcc... gcc
checking for C compiler default output file name...
configure: error: C compiler cannot create executables
See `config.log' for more details.
Jim Michaels@jim-13l5nom9i4u /c/wxWidgets-2.9.2
$
log says:
gcc version 3.4.5
On 10/3/2011 20:11, Subhasish Ghosh wrote:
Hi,
I am trying to generate windows 64 bit executable from Linux.
I am using mingw64 for the purpose.
But, I first need to compile the mingw64 sources on Linux RHEL6.0.
I cannot use the binaries as I am planning to integrate ming64 into
our
101 - 200 of 1006 matches
Mail list logo
