Re: [Mingw-w64-public] WIN32_ONLY_COMPILER

2010/7/1 Jim Michaels > did somebody think to implement the #define WIN32_ONLY_COMPILER? I am > getting compiler errors trying to compile postgres 8.4.0. > I don't think this is a mingw-w64 problem, and I think that this is defined inside the postgres sources (see here

[Mingw-w64-public] WIN32_ONLY_COMPILER

did somebody think to implement the #define WIN32_ONLY_COMPILER? I am getting compiler errors trying to compile postgres 8.4.0. Jim Michaels jmich...@yahoo.com(main) http://JesusnJim.com (my site) http://DoLifeComputers.JesusnJim.com (Do Life Computers group si

Re: [Mingw-w64-public] Backporting multilib support to GCC 4.4.x tree

Hi Doug, > Here's a better example, while pretty contrived, that shows how the > compiler can optimize away things due to aliasing rules. > > What do you expect the output of the printf to be?  In the -O2 and > better case, I can tell you that gcc 4.4 differs from gcc 4.5, and is > probably not wh

Re: [Mingw-w64-public] Reason for libtool patch in "Custom toolchain build"?

On Thu, Jul 1, 2010 at 8:28 PM, Paarvai Naai 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 been developi

Re: [Mingw-w64-public] Problems using -municode with mingw-w64 target

On Wed, Jun 30, 2010 at 8:59 PM, JonY wrote: > GCC probably recognizes main() so it doesn't mangle it. > > Adding extern "C" is fine, I usually see it accompanying WinMain/wWinMain > and wmain in C++ code, just to be explicit. Okay, that sounds good for now. Thanks! Paarvai

Re: [Mingw-w64-public] Reason for libtool patch in "Custom toolchain build"?

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 been developing code and compiling open source projects for a long time, I

Re: [Mingw-w64-public] Strange auto-import issue with libstdc++

Hi Doug, > Not only can the warning be ignored, the warning will no longer occur > with the binutils from the current trunk HEAD, because > --enable-auto-import has now become the default for x86 and x64 mingw > targets. Yes, I also confirmed this also last night by looking at the latest binutils

Re: [Mingw-w64-public] Backporting multilib support to GCC 4.4.x tree

I'm sorry if I didn't convey my meaning properly, I was interrupted before I completed. Here's a better example, while pretty contrived, that shows how the compiler can optimize away things due to aliasing rules. What do you expect the output of the printf to be? In the -O2 and better case, I ca

Re: [Mingw-w64-public] Strange auto-import issue with libstdc++

On Wed, Jun 30, 2010 at 10:20 PM, JonY wrote: > On 7/1/2010 10:21, Paarvai Naai wrote: >> As I have mentioned in some recent emails, I am building my mingw-w64 >> toolchain using upstream binutils-2.20.1, gcc 4.5.0, and >> mingw-w64-v1.0-20100604 snapshot.  The host is i386-linux and the >> target

[Mingw-w64-public] ddraw.h vs strmif.h

Hi, I discovered a build error when testing Qt 4.7 with the autobuilds (dated 28 June mingw-w64-bin_i686-mingw), with the addition of the dx headers from the source package: g++ -c -g -frtti -fexceptions -mthreads -Wall -DUNICODE > -DQT_LARGEFILE_SUPPORT -DPHONON_MAKE_QT_ONLY_BACKEND -DQT_DLL -D

Re: [Mingw-w64-public] gcc system headers (float.h, stdarg.h, and stddef.h) + /mingw directory and multilib naming

On Thu, Jul 1, 2010 at 4:42 PM, Ruben Van Boxem 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 bug report, is it fi

[Mingw-w64-public] gcc system headers (float.h, stdarg.h, and stddef.h) + /mingw directory and multilib naming

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 bug report, is it fixed somewhere upstream, should I annoy the devs with spam about this