On Fri, Aug 14, 2009 at 7:48 PM, Kai Tietzktiet...@googlemail.com wrote:
2009/8/14 NightStrike nightstr...@gmail.com:
On Sat, Jun 27, 2009 at 11:41 PM, David Cournapeaucourn...@gmail.com wrote:
Hi,
I am building a plugin (dll) for a software built with VS 2008, which
linked against the
On Mon, Aug 17, 2009 at 10:49 AM, JonY10wa...@gmail.com wrote:
Hi,
This patch will add warning flags.
There are currently 5 warning levels, which defaults to level 3. It gets
noisier for higher levels. Level 0 is equivalent to no additional flags. Use
--with-warnings[=n] to set the levels.
On Fri, Aug 21, 2009 at 10:42 AM, Ozkan Sezerseze...@gmail.com wrote:
On Fri, Aug 21, 2009 at 10:24 AM, Kai Tietzktiet...@googlemail.com wrote:
2009/8/21 t66...@gmail.com t66...@gmail.com:
Hello,
I filed a bug report at gcc bug tracker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41136
Is
On Fri, Aug 21, 2009 at 10:57 AM, Kai Tietzktiet...@googlemail.com wrote:
2009/8/21 Ozkan Sezer seze...@gmail.com:
On Fri, Aug 21, 2009 at 10:24 AM, Kai Tietzktiet...@googlemail.com wrote:
2009/8/21 t66...@gmail.com t66...@gmail.com:
Hello,
I filed a bug report at gcc bug tracker
http
On Fri, Aug 21, 2009 at 9:58 AM, t66...@gmail.comt66...@gmail.com wrote:
Hello,
I filed a bug report at gcc bug tracker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41136
Is anyone encountering this bug and is there any possible workaround ?
Can you please checkout the latest mingw-w64-crt
I am glad that it fixes your case, and please feel free to report
any further issues. As I said, we're working further on additional
problems related to this.
Cheers.
Hi,
Just to follow up on that native compiler that I cross compiled it from
linux.
It does run but only half way.
On Thu, Sep 17, 2009 at 5:55 AM, Erik de Castro Lopo
mle+...@mega-nerd.com wrote:
Hi all,
I'm using mingw-w64-bin_i686-linux_20090612.tar.bz2 which is the latest
I can find and running into problems compiling stuff like:
printf (Bad file length (% PRId64 should be %zd).\n, retval, sizeof
On Fri, Sep 18, 2009 at 1:14 AM, Erik de Castro Lopo
mle+...@mega-nerd.com wrote:
Ozkan Sezer wrote:
I'm not sure whether msvcrt supports the %z size_t conversion.
I'm pretty damn sure it doesn't :-).
You can, however, use the posix compliant mingw version.
Its not POSIX, its ISO C99
On Sat, Sep 19, 2009 at 1:12 AM, Erik de Castro Lopo
mle+...@mega-nerd.com wrote:
Using built-in specs.
Target: x86_64-w64-mingw32
Configured with: ../../../build/gcc/gcc/configure
--target=x86_64-w64-mingw32
--prefix=/Testing/build/root --with-sysroot=/Testing/build/root
On Sat, Sep 19, 2009 at 9:20 AM, Erik de Castro Lopo
mle+...@mega-nerd.com wrote:
Ozkan Sezer wrote:
- Which svn revision of mingw-w64 headers and crt did you
use in your toolchain ?
Same revision for both :
Path: .
URL: https://mingw-w64.svn.sourceforge.net/svnroot/mingw-w64/trunk
On Sat, Sep 19, 2009 at 11:02 AM, Erik de Castro Lopo
mle+...@mega-nerd.com wrote:
Ozkan Sezer wrote:
Hmm, with my versions gcc-4.4.2 (svn r151768, patched but
nothing that would affect this) and mingw-w64 r1375-r1378,
I get:
x86_64-pc-mingw32-gcc -Wall -std=gnu99 test.c
test.c
On Sat, Sep 19, 2009 at 1:13 PM, Erik de Castro Lopo
mle+...@mega-nerd.com wrote:
Ozkan Sezer wrote:
You need it with both. (Although, if your w32 toolchain is
a mingw.org toolchain and not ours, they may have automatically
defined __USE_MINGW_ANSI_STDIO as 1 upon seeing -std=c99. Kai
it?
If you are referring to the rev. 1377 change, I wouldn't rely
on it being definitely defined as 0 or 1. User may be buggy
and would just do -D__USE_MINGW_ANSI_STDIO without
an =0 or =1, would he not?
Cheers,
Kai
--
Ozkan
2009/9/19 Ozkan Sezer seze...@gmail.com:
On Sat, Sep 19, 2009 at 1:13 PM
On Sun, Sep 20, 2009 at 1:08 AM, Erik de Castro Lopo
mle+...@mega-nerd.com wrote:
Ozkan Sezer wrote:
OK, applied this as rev. 1395:
http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64?view=revrevision=1395
Please test.
Real close!
I get the proper C99 behaviour if I compile
On Sun, Sep 20, 2009 at 3:02 AM, Erik de Castro Lopo
mle+...@mega-nerd.com wrote:
HI all,
I've had a bit of a look at the makebuildroot.mk build script. It
seems like this may be able to make both a win32 and a win64 cross
compiler.
Is that correct?
Cheers,
Erik
--
On Sun, Sep 20, 2009 at 2:55 AM, Erik de Castro Lopo
mle+...@mega-nerd.com wrote:
Please note, I am subscribed to the list. No need to CC me on reply.
Ozkan Sezer wrote:
A question, though: Are you using gcc-3.4.5 or 4.4.0 as the mingw.org
compiler for your w32 builds? I think the warning
On Fri, Oct 9, 2009 at 8:21 PM, NightStrike nightstr...@gmail.com wrote:
On Fri, Oct 9, 2009 at 1:17 PM, Ozkan Sezer seze...@gmail.com wrote:
On Fri, Oct 9, 2009 at 8:00 PM, NightStrike nightstr...@gmail.com wrote:
On Fri, Oct 9, 2009 at 12:54 PM, Ozkan Sezer seze...@gmail.com wrote:
On Fri
when applying gmp-4.3.1-w64.patch, some of entries for configure script
are been rejected due to inconsistance between 20091006 tarball's
configure and patch...
Most rejected entries are just about line echoing, but the last one is
more important and rejected due to context comment
On Sun, Oct 25, 2009 at 5:55 PM, David Cleaver wrai...@morpheus.net wrote:
Hello,
I'm having problems printing out values that are larger than 32 bits. My
usual
printf using %llu only outputs the lower 32 bits of my 64-bit numbers.
Here's an example program that produces incorrect output.
On Mon, Nov 2, 2009 at 11:49 AM, t66...@gmail.com t66...@gmail.com wrote:
/home/slack/gcc/binutils-cvs/libiberty/getopt.c: In function
'_getopt_internal':
/home/slack/gcc/binutils-cvs/libiberty/getopt.c:683: error: called
object '1' is not a function
On Tue, Jan 19, 2010 at 7:29 AM, Sisyphus sisyph...@optusnet.com.au wrote:
Hi,
Has anyone here done this without getting test failures ?
I've tried using mingw-w64-bin_i686-mingw_20091118.zip and
mingw-w64-bin_i686-mingw_20100118.zip binaries, but I get the same 2 test
failures.
Firstly,
On Tue, Jan 19, 2010 at 7:42 AM, Zuxy Meng zuxy.m...@gmail.com wrote:
Hi,
I wonder if the win32api headers from mingw32 can be used directly in
mingw64.
No, they cannot.
If I have already a working msys+mingw32 env installed, can I just
copy binutils, gcc and libraries from mingw64 to have
On Tue, Jan 19, 2010 at 3:50 PM, JonY jo...@users.sourceforge.net wrote:
On 1/19/2010 20:03, Sisyphus wrote:
- Original Message -
From: Ozkan Sezerseze...@gmail.com
Firstly, the command I'm running to build and test gmp-5.0.0 is:
./configure --disable-shared --enable-static
To anyone who might be interested: I updated my custom
w32/w64 native and cross-compiler build with gcc-4.4.3
with several backports and fixes from mainstream and put
them under the mingw-w64 sf.net file release system under
the subdirectories: Toolchain sources - Personal Builds,
Toolchains
On Tue, Jan 19, 2010 at 4:06 PM, JonY jo...@users.sourceforge.net wrote:
On 1/19/2010 21:55, Ozkan Sezer wrote:
On Tue, Jan 19, 2010 at 3:50 PM, JonYjo...@users.sourceforge.net wrote:
On 1/19/2010 20:03, Sisyphus wrote:
- Original Message -
From: Ozkan Sezerseze...@gmail.com
To anyone who might be interested: I updated my custom
w32/w64 native and cross-compiler build with gcc-4.4.3
with several backports and fixes from mainstream and put
them under the mingw-w64 sf.net file release system under
the subdirectories: Toolchain sources - Personal Builds,
Toolchains
it's 32-bit windows 9x code, but the target is 64-bit, so I have to disable
the 9x code.
I found a workaround on the internet (great place to look for solutions):
#if !defined(_WIN64)
...//win9x code
#endif
Yep.
Use DWORD_PTR instead.
I don't think it's going to fit in 32 bits.
It
On Fri, Mar 5, 2010 at 12:20 AM, Jim Michaels jmich...@yahoo.com wrote:
in MSVC,
__int64 x=12345678901234567i64;
point 1: this type __int64 doesn't require me to #include windows to
define it. in mingw and mingw-w64, one must #include basetsd.h. why?
It is enough, I guess.. Include
On Sun, Mar 21, 2010 at 7:21 PM, NightStrike nightstr...@gmail.com wrote:
Well, this is a problem, yes. It only affects the multilib builds,
though, which don't really work anyway without a lot of effort. And
this will all be fixed for 4.6, o we won't need to worry about it.
If users really
On Sun, Mar 21, 2010 at 7:55 PM, Kai Tietz ktiet...@googlemail.com wrote:
2010/3/21 Ozkan Sezer seze...@gmail.com:
On Sun, Mar 21, 2010 at 7:21 PM, NightStrike nightstr...@gmail.com wrote:
Well, this is a problem, yes. It only affects the multilib builds,
though, which don't really work
On Sun, Mar 21, 2010 at 10:42 PM, Dave Camarillo
dave.camari...@gmail.com wrote:
Hello, I'm having a little trouble with the include paths used by mingw-w64
and was hoping for some insight... I have this chunk of code compiling
correctly under the normal mingw system, but have some problems
On Mon, Mar 22, 2010 at 2:51 AM, NightStrike nightstr...@gmail.com wrote:
On Sun, Mar 21, 2010 at 7:41 PM, Doug Semler dougsem...@gmail.com wrote:
On Sun, 21 Mar 2010 19:22:48 NightStrike wrote:
On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer seze...@gmail.com wrote:
For some reason yet unknown
, 2010 at 4:22 PM, NightStrike nightstr...@gmail.com wrote:
On Sun, Mar 21, 2010 at 5:20 PM, Ozkan Sezer seze...@gmail.com wrote:
For some reason yet unknown to me, the gcc-provided headers
have priority over the system provided headers and float.h is
especially problematic: Not installing
On Tue, Mar 23, 2010 at 2:43 PM, Kai Tietz ktiet...@googlemail.com wrote:
2010/3/23 Ozkan Sezer seze...@gmail.com:
On Tue, Mar 23, 2010 at 2:17 PM, NightStrike nightstr...@gmail.com wrote:
On Tue, Mar 23, 2010 at 8:15 AM, Kai Tietz ktiet...@googlemail.com wrote:
2010/3/23 NightStrike nightstr
On Tue, Mar 23, 2010 at 2:52 PM, Kai Tietz ktiet...@googlemail.com wrote:
2010/3/23 Ozkan Sezer seze...@gmail.com:
On Tue, Mar 23, 2010 at 2:43 PM, Kai Tietz ktiet...@googlemail.com wrote:
2010/3/23 Ozkan Sezer seze...@gmail.com:
On Tue, Mar 23, 2010 at 2:17 PM, NightStrike nightstr
On Wed, Mar 24, 2010 at 2:15 PM, Sisyphus sisyph...@optusnet.com.au wrote:
Hi,
I've posted to gsl-bugs about this ... without success. I'm not even sure
that it's a gsl bug - there's a thread at
http://www.mail-archive.com/bug-libt...@gnu.org/msg00374.html where the
error is of a very
On Wed, Mar 31, 2010 at 9:21 PM, NightStrike nightstr...@gmail.com wrote:
You can send them to our patch tracker:
http://sourceforge.net/tracker/?group_id=202880atid=983356
On Wed, Mar 31, 2010 at 2:17 PM, Wiljan Derks wiljan.de...@gmail.com wrote:
I have been trying to build 64 bits drivers
To anyone who might be interested: I updated my custom w32/w64 native
and cross-compiler build with gcc-4.4 with several backports and fixes
from mainstream and put them under the mingw-w64 sf.net file release
system under the subdirectories:
- Toolchain sources - Personal Builds,
- Toolchains
On Wed, Apr 14, 2010 at 10:37 AM, Martin Rubey
martin.ru...@math.uni-hannover.de wrote:
Ozkan Sezer seze...@gmail.com writes:
many thanks for the patch. The gmp configures fine now. Unfortunately,
I'm still having trouble configuring ecl.
The config.log is at
http://sprunge.us/SWHX
On Tue, Apr 20, 2010 at 7:37 AM, Kai Tietz ktiet...@googlemail.com wrote:
Hi Patrick,
2010/4/20 Patrick Galbraith p...@patg.net:
Hi all,
I've stumbled across an issue with gettimeofday() returning an incorrect
value with mingw-w64. A simple code sample:
#include stdio.h
#include
On Wed, Apr 21, 2010 at 11:49 AM, 罗勇刚(Yonggang Luo)
luoyongg...@gmail.com wrote:
Once I compiling cmake, the 101 line of windef.h stop me to continuing.
so recommend.
replace #define BOOL WINBOOL
with typedef WINBOOL BOOL;
for make BOOL to free using in C++ namespace.
Please try using a
On Wed, Apr 21, 2010 at 11:38 AM, 罗勇刚(Yonggang Luo)
luoyongg...@gmail.com wrote:
E:/CI/Tools//phoenix/mingw32/bin\gcc.exe -mno-cygwin -shared -s
build\temp.win32-2.6\Release\dulwich\_objects.o
build\temp.win32-2.6\Release\dulwich\_objects.def
-LE:\CI\tools\Python\libs -LE:\CI\tool
To anyone who might be interested: I updated my custom w32/w64 native
and cross-compiler build with gcc-4.4 with several backports and fixes
from mainstream and put them under the mingw-w64 sf.net file release
system under the subdirectories:
- Toolchain sources - Personal Builds,
- Toolchains
On Tue, May 4, 2010 at 4:00 PM, t66...@gmail.com t66...@gmail.com wrote:
Hello:
Currently I am using the mingw-w64 SVN to build recently released GCC
4.5 4.4 series.
Anyone have have problem with gcc-4.4.4 and 4.5.0 cross compiler with
mingw-w64 trunk CRT and W32API running on Linux ?
I use
By why does this not fail when building native linux compiler? I'm
using same patched source as used by the distribution in that field.
By inspected the said function I fail to see what's wrong with it. Can
you explain what's wrong with:
static char name [UNLEN + 1];
DWORD namelen =
On Tue, May 4, 2010 at 4:27 PM, Ozkan Sezer seze...@gmail.com wrote:
By why does this not fail when building native linux compiler? I'm
using same patched source as used by the distribution in that field.
By inspected the said function I fail to see what's wrong with it. Can
you explain what's
Can you please write s simple Fortran programm which will call this:
60 /* GETLOG (LOGIN), g77 intrinsic for retrieving the login name for the
61 process.
62 CHARACTER(len=*), INTENT(OUT) :: LOGIN */
Program is attached, however it produces the same result on ubuntu
On Wed, May 5, 2010 at 6:42 PM, Dmitrijs Ledkovs
dmitrij.led...@ubuntu.com wrote:
On 5 May 2010 16:31, Ozkan Sezer seze...@gmail.com wrote:
On Wed, May 5, 2010 at 6:22 PM, Wolfgang Glas wolfgang.g...@ev-i.at wrote:
On 2010-05-05 16:49, Ozkan Sezer wrote:
Can you please write s simple Fortran
Already tested that before sending. Compiled using my own x86-linux-
w64 toolchain, the result runs just fine on w64. (why should it fail?)
Because debian smarty pants script for detection of code assumes
pointer size = size of int is wrong =)
Can you tell me exactly which file/line
On Wed, May 5, 2010 at 8:03 PM, Dmitrijs Ledkovs
dmitrij.led...@ubuntu.com wrote:
On 5 May 2010 16:56, Ozkan Sezer seze...@gmail.com wrote:
Already tested that before sending. Compiled using my own x86-linux-
w64 toolchain, the result runs just fine on w64. (why should it fail?)
Because
On Thu, May 6, 2010 at 7:06 AM, t66...@gmail.com t66...@gmail.com wrote:
Hello:
After I have built a cross compiler + native one, of gcc-4_5-branch +
binutils-cvs, in previous build problem of the gcc-releases having
leading underscore.
There is a problem of how mingw-w64-svn winsock2.h is
On Sat, May 8, 2010 at 9:58 AM, Jim Michaels jmich...@yahoo.com wrote:
in MSVC++, you do
__int64 n=9223372036854775807i64;
but in all forms of GCC, including mingw-w64, you do
#include basetsd.h
__int64 n=9223372036854775807LL;
because nothing else works.
could that be fixed? it would be
On Sat, May 8, 2010 at 10:22 AM, t66...@gmail.com t66...@gmail.com wrote:
On 8/05/2010 4:31 PM, Ozkan Sezer wrote:
On Sat, May 8, 2010 at 6:19 AM, t66...@gmail.comt66...@gmail.com wrote:
Hello:
Further interests to the 64bit no leading underscore problem...
I was trying to compile various
On Mon, May 10, 2010 at 7:30 PM, Ozkan Sezer seze...@gmail.com wrote:
On Mon, May 10, 2010 at 5:04 PM, Dmitrijs Ledkovs
dmitrij.led...@ubuntu.com wrote:
I'm almost there..
Update:
1) testsuite
I've enabled $ make check in this build and it started to run dejagnu
testsuite against
To anyone who might be interested: I updated my custom w32/w64 native
and cross-compiler build with gcc-4.4 with several backports and fixes
from mainstream and put them under the mingw-w64 sf.net file release
system under the subdirectories:
- Toolchain sources - Personal Builds,
- Toolchains
I updated my custom w32/w64 native and cross-compiler build with gcc-4.4
with several backports and fixes from mainstream, and put them under the
mingw-w64 sf.net file release system under the subdirectories:
- Toolchain sources - Personal Builds,
- Toolchains targetting Win32 - Personal Builds
On Sat, May 15, 2010 at 7:12 AM, Jim Michaels jmich...@yahoo.com wrote:
1.
I have noticed that for sezero and auto compilers, there averages
7-8 LONG directories for lib path totalling 284-328 characters
5 LONG directories for include path totalling 274-310 characters
1-2 directories for bin
On Thu, May 27, 2010 at 10:34 PM, NightStrike nightstr...@gmail.com wrote:
On Sat, May 22, 2010 at 3:36 PM, Kai Tietz ktiet...@googlemail.com wrote:
Hi Jarrod,
2010/5/22 Jarrod Chesney jarrod.ches...@gmail.com:
Hi All
This is my patch for the mingw-w64-headers for the comutil issues
On Sun, May 30, 2010 at 12:29 PM, Wolfgang Glas wolfgang.g...@ev-i.at wrote:
Hi all,
I'm currently using sezero's 20100515 distribution and I'm in the works to
switch to 20100527. (Great work, sezero, big hands :-) Everything worked fine
for 20100515, I even got a qt-4.7 snapshot
On Wed, Jun 2, 2010 at 9:47 AM, Jim Michaels jmich...@yahoo.com wrote:
it's probably my machine, but once I execute g++ and windres, I can no
longer execute them again. they corrupt themselves.
in other words, I can't do it twice. weirdly enough, even the source zip
file got corrupted, so I
I updated my custom w32/w64 native and cross-compiler build with gcc-4.4
with several backports and fixes from mainstream, and put them under the
mingw-w64 sf.net file release system under the subdirectories:
- Toolchain sources - Personal Builds,
- Toolchains targetting Win32 - Personal Builds
I'm using GUID_DEVINTERFACE_USB_DEVICE in my windows code, which uses
setupapi.dll. This declaration has been in ddk/usbiodef.h as of
mingw-w64-gcc-4.4.1
However this header seems to be gone in erecnt versions (I'm currently on
sezero gcc-4.4.5-20100527). Morevover I can't find
On Mon, Jun 7, 2010 at 12:09 AM, Dmitrijs Ledkovs
dmitrij.led...@ubuntu.com wrote:
On 6 June 2010 12:00, Ozkan Sezer seze...@gmail.com wrote:
On Sun, Jun 6, 2010 at 1:37 PM, Wolfgang Glas wolfgang.g...@ev-i.at wrote:
Hi all,
I'm using GUID_DEVINTERFACE_USB_DEVICE in my windows code, which
On Mon, Jun 7, 2010 at 10:17 AM, Wolfgang Glas wolfgang.g...@ev-i.at wrote:
On 2010-06-07 08:52, Ozkan Sezer wrote:
On Mon, Jun 7, 2010 at 12:09 AM, Dmitrijs Ledkovs
dmitrij.led...@ubuntu.com wrote:
On 6 June 2010 12:00, Ozkan Sezer seze...@gmail.com wrote:
On Sun, Jun 6, 2010 at 1:37 PM
Well, the only solution I see here for the ddk-optional SDK is, that
we do a fork of it and have to maintain it by ourself. The only need
we would have here is a volunteer doing the manual merge and which
signs responsible to build up an testsuite for it.
We should keep in experimental
On Mon, Jun 7, 2010 at 12:37 PM, Kai Tietz ktiet...@googlemail.com wrote:
2010/6/7 Ozkan Sezer seze...@gmail.com:
Well, the only solution I see here for the ddk-optional SDK is, that
we do a fork of it and have to maintain it by ourself. The only need
we would have here is a volunteer doing
On Thu, Jun 10, 2010 at 1:17 PM, Ozkan Sezer seze...@gmail.com wrote:
On Thu, Jun 10, 2010 at 5:34 AM, Dmitrijs Ledkovs
dmitrij.led...@ubuntu.com wrote:
FYI
A bunch of more headers removed from the ddk/ dir of the svn repo =(
Ugh!... :-((
More job for me checking all the dependencies
On Thu, Jun 10, 2010 at 10:10 PM, Henry N. henrynmail-mi...@yahoo.de wrote:
On 10.06.2010 19:04, Ozkan Sezer wrote:
On Thu, Jun 10, 2010 at 1:17 PM, Ozkan Sezer wrote:
On Thu, Jun 10, 2010 at 5:34 AM, Dmitrijs Ledkovs
dmitrij.led...@ubuntu.com wrote:
FYI
A bunch of more headers removed
On Thu, Jul 1, 2010 at 12:00 AM, Paarvai Naai opensource3...@gmail.com wrote:
Hi,
I want to gain an understanding for the reasoning behind the
libtool_patch function used in the Custom toolchain builds
distributed by Ozkan Sezer.
I don't see this mentioned in the standard cross-compiler
On Wed, Jun 30, 2010 at 10:32 PM, Paarvai Naai opensource3...@gmail.com wrote:
Hi all,
I am trying to build a mingw-w64 cross-compiler using the instructions
outlined on the web.
Originally I was successful in building a multilib cross-compiler
using GCC 4.5.0, but now I want to backtrack
, Jun 30, 2010 at 2:07 PM, Ozkan Sezer seze...@gmail.com wrote:
On Thu, Jul 1, 2010 at 12:00 AM, Paarvai Naai opensource3...@gmail.com
wrote:
Hi,
I want to gain an understanding for the reasoning behind the
libtool_patch function used in the Custom toolchain builds
distributed by Ozkan Sezer
On Thu, Jul 1, 2010 at 4:42 PM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
Hi,
Following up on a recent discussion on the bug tracker, I'd like to know
what came of this discussion on the gcc list:
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01114.html
Is there a need to open a new
On Thu, Jul 1, 2010 at 8:28 PM, Paarvai Naai opensource3...@gmail.com wrote:
Hi Ozkan,
Libtool 2.2.6/2.2.7 may not detect w64 libraries properly so the
linkage would fail. Please look at what the patch does: it just updates
the pe-x86_64 magic that is already in libtool 2.2.7.
While I have
On Thu, Jul 8, 2010 at 9:05 AM, Bidski bid...@bigpond.net.au wrote:
Hi all,
Just running through this but have run into a problem while building the
crt. Everything else has appeared to configure and make without error thus
far.
The error I am getting is while running make and looks like
On Thu, Jul 8, 2010 at 10:01 AM, Bidski bid...@bigpond.net.au wrote:
Ozkan Sezer seze...@gmail.com wrote:
You are using headers from mingw.org and not from mingw-w64.
Please use headers from mingw-w64.
Should I overwrite the heaqders I have from mingw.org or should i set some
CFLAGS
On Thu, Jul 8, 2010 at 10:20 AM, Bidski bid...@bigpond.net.au wrote:
The mingw.org headers are the ones im using to build this cross-compiler,
which is why I am wondering if its safe to get rid of them.
Hmm, you used mingw.org compiler to build a w64 compiler, yes?
In that case, the answer is
On Thu, Jul 8, 2010 at 6:04 PM, Dongsheng Song dongsheng.s...@gmail.com wrote:
Hi,
Due to recent update of pthread-w32, the patch:
http://sourceware.org/ml/pthreads-win32/2009/msg00030/w64sup.patch
can not apply cleanly, have some conflicts now, is there have any update
patch ?
Regards,
On Sun, Jul 11, 2010 at 10:06 PM, Ozkan Sezer seze...@gmail.com wrote:
I updated my custom w32/w64 native and cross-compiler build with gcc-4.4
with several backports and fixes from mainstream, and put them under the
mingw-w64 sf.net file release system under the subdirectories:
- Toolchain
On Mon, Jul 12, 2010 at 3:40 PM, Wolfgang Glas wolfgang.g...@ev-i.at wrote:
On 2010-07-12 13:25, Ozkan Sezer wrote:
On Sun, Jul 11, 2010 at 10:06 PM, Ozkan Sezer seze...@gmail.com wrote:
[snip]
---
- Wolfgang Glas
On Thu, Jul 22, 2010 at 12:29 PM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
Hi,
Would it be feasable to provide an extension to the POSIX dirent.h
functionality? I found a small patch in some compatibility layer (in git
source) that adds d_type to the DIR structure, which is currently
On Sat, Jul 24, 2010 at 2:56 PM, Henry N. henrynmail-mi...@yahoo.de wrote:
On 20.06.2010 18:43, Doug Semler wrote:
On Sun, Jun 20, 2010 at 12:03 PM, Henry N.henrynmail-mi...@yahoo.de
wrote:
Hello,
in the 32 bit build environment a simple include like
cat check.c
On Wed, Jul 28, 2010 at 10:54 AM, Dongsheng Song
dongsheng.s...@gmail.com wrote:
于 2010-7-28 15:43, Kai Tietz 写道:
2010/7/28 Dongsheng Song dongsheng.s...@gmail.com:
Hi Kai,
When we cross build gcc 4.5 for windows, I found we can build windows gcc
binary one
week ago, but now the build
On Thu, Jul 29, 2010 at 6:28 PM, Kai Tietz ktiet...@googlemail.com wrote:
2010/7/29 Dongsheng Song dongsheng.s...@gmail.com:
Thanks, when I build libassuan, I found ENOFILE not defined yet (within
errno.h)
#define ENOFILE 2 /* No such file or directory */
#define ENOENT
On Thu, Jul 29, 2010 at 6:54 PM, Ozkan Sezer seze...@gmail.com wrote:
On Thu, Jul 29, 2010 at 6:32 PM, Alon Bar-Lev alon.bar...@gmail.com wrote:
Hello,
Is there any reason why we have pdh in 64bit but not for 32bit?
I guess this is with v1.0 runtime and not from the trunk
On Sat, Jul 31, 2010 at 11:48 PM, Luis Lavena luislav...@gmail.com wrote:
Hello,
I've installed i686-w64-mingw32 for darwin target (20100730), and I'm
trying to cross-compile a Ruby extension that uses oleauto (it is
bundled with Ruby sources and is called win32ole).
During the cross
On Sun, Aug 1, 2010 at 12:52 AM, Luis Lavena luislav...@gmail.com wrote:
On Sat, Jul 31, 2010 at 6:28 PM, Ozkan Sezer seze...@gmail.com wrote:
If that change goes back to 2002, then it was intended for
really old gcc versions, The oldest I currently use from time to
time is 3.4.5 and AFAIK
On Sun, Aug 1, 2010 at 12:58 AM, Ozkan Sezer seze...@gmail.com wrote:
On Sun, Aug 1, 2010 at 12:52 AM, Luis Lavena luislav...@gmail.com wrote:
On Sat, Jul 31, 2010 at 6:28 PM, Ozkan Sezer seze...@gmail.com wrote:
If that change goes back to 2002, then it was intended for
really old gcc
On Thu, Aug 5, 2010 at 3:45 AM, Chris Sutcliffe ir0nh...@gmail.com wrote:
Hi Kai,
On 7/31/10 1:13 PM, Kai Tietz wrote:
2010/7/31 Chris Sutcliffe:
It turns out it's not gcc, it's due to the fact that libmsvcrt.a doesn't
export `__p___mb_cur_max'. The mingw.org msvcrt.def file contains:
On Thu, Aug 5, 2010 at 5:21 AM, Chris Sutcliffe ir0nh...@gmail.com wrote:
On 8/04/10 9:10 PM, Ozkan Sezer wrote:
What happens if you comment out lines 459 and 462 in
win32/osdep.h and allow stdlib.h and mbstring.h to be
included and get a proper definition of MB_CUR_MAX ?
I don't know why
On Tue, Aug 10, 2010 at 1:15 AM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
Hi,
I'm still using latest sezero toolchain, and fear there is a problem with
Out of curiosity, what is the source of your fear?
it.
I tried finding an oldere build, but it has been deleted. Does someone still
On Tue, Aug 10, 2010 at 10:52 AM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
Out of curiosity, what is the source of your fear?
I reverted Qt sources to a state that previously worked (I think, there were
conflicts I had to resolve manually...) , and the same crash popped up. I'll
try
On Sun, Aug 15, 2010 at 5:08 PM, John E. / TDM tdra...@tdragon.net wrote:
On 8/15/2010 7:48 AM, Chris Sutcliffe wrote:
Is there native 64-bit tool chain available? Looking in the automated
builds, I can only find a i686 cross-compiler. I looked into the sezero
builds, but unfortunately they
On Mon, Aug 16, 2010 at 2:18 AM, Chris Sutcliffe ir0nh...@gmail.com wrote:
When compiling code that includes is fails at these lines:
WINCOMMCTRLAPI BOOL WINAPI DPA_Grow(HDPA pdpa, IN int cp);
WINCOMMCTRLAPI int WINAPI DPA_InsertPtr(HDPA hdpa, IN int i, void *p);
WINCOMMCTRLAPI PVOID
On Tue, Aug 17, 2010 at 2:24 PM, Kai Tietz ktiet...@googlemail.com wrote:
2010/8/17 Pete Batard pbat...@gmail.com:
For 32 bit, the current MinGW-w64 winbase has:
LONG InterlockedIncrement(LONG volatile *lpAddend);
LONG InterlockedDecrement(LONG volatile *lpAddend);
LONG
On Tue, Aug 17, 2010 at 2:34 PM, Kai Tietz ktiet...@googlemail.com wrote:
2010/8/17 Ozkan Sezer seze...@gmail.com:
On Tue, Aug 17, 2010 at 2:24 PM, Kai Tietz ktiet...@googlemail.com wrote:
2010/8/17 Pete Batard pbat...@gmail.com:
For 32 bit, the current MinGW-w64 winbase has:
LONG
On Tue, Aug 17, 2010 at 2:52 PM, Kai Tietz ktiet...@googlemail.com wrote:
2010/8/17 Ozkan Sezer seze...@gmail.com:
On Tue, Aug 17, 2010 at 2:44 PM, Kai Tietz ktiet...@googlemail.com wrote:
2010/8/17 Pete Batard pbat...@gmail.com:
On 2010.08.17 12:29, Ozkan Sezer wrote:
Thank you Pete
On Tue, Aug 17, 2010 at 3:50 PM, Kai Tietz ktiet...@googlemail.com wrote:
2010/8/17 Pete Batard pbat...@gmail.com:
On 2010.08.17 12:55, Kai Tietz wrote:
Pete,
could you provide us a list of the Interlock* API, which has stdcall
calling convention by our findings? Please just list names of
I've been forgetting this for quite some time:
http://quakespasm.sourceforge.net/
We've been compiling for w64 using mingw-w64 for some time.
The project uses SDL, so we are including x64 builds of SDL
also prepared using mingw-w64. It has been successful since
the beginning.
--
O.S.
On Thu, Aug 26, 2010 at 10:46 AM, Vasilakis fithis2...@gmail.com wrote:
I have installed both
sezero_20100711_w32_runtime_update_3405.zip
mingw-w32-bin_i686-mingw_20100711_sezero.zip
on my Windows XP SP3 x86 machine. I tried to compile
tbb30_20100406oss_src.tgz
but to no avail. Build
On Thu, Aug 26, 2010 at 2:03 PM, Vasilakis fithis2...@gmail.com wrote:
On 8/26/2010 11:34 AM, Ozkan Sezer wrote:
On Thu, Aug 26, 2010 at 10:46 AM, Vasilakisfithis2...@gmail.com wrote:
I have installed both
sezero_20100711_w32_runtime_update_3405.zip
mingw-w32-bin_i686
1 - 100 of 499 matches
Mail list logo
