Hi Doug,
> Since no headers are required for wmain definitions
> themselves, the only workaround at this time is to document that when
> compiling with the g++ compiler,
>
> #ifdef __cplusplus
> extern "C"
> #endif
> int wmain(int, wchar_t**, wchar_t**)
> {
> ...
> }
Okay, but how does this get
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
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
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
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
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 is x86_64-w64-mingw32 with multilib support.
I am running into a strange auto-import issue when co
vai
On Wed, Jun 30, 2010 at 7:10 PM, Paarvai Naai wrote:
> Hi,
>
> I have returned to using GCC 4.5.0 for my x86_64-w64-mingw32 multilib
> target. I tried using the -municode option with my build and get the
> following error:
>
> ] /usr/local/gcc/x86_64-windows-gcc/bin/x8
Hi,
I have returned to using GCC 4.5.0 for my x86_64-w64-mingw32 multilib
target. I tried using the -municode option with my build and get the
following error:
] /usr/local/gcc/x86_64-windows-gcc/bin/x86_64-windows-g++ -municode
-o hello.exe hello_win_unicode.c
/usr/local/gcc/x86_64-windows-gcc/
On Wed, Jun 30, 2010 at 4:05 PM, Paarvai Naai wrote:
> Yes, I am planning on posting my find on the GCC Bugzilla. I'm pretty
> sure it's a case of over-optimization (and a critical one at that),
> but I freely admit that I'm not an expert on the internals of GCC. :)
I ha
Hi Doug,
> Have you filed a bugzilla report for gcc against this bug? If it is
> an optimization wrong code bug, then it probably exists for other
> targets besides mingw32.
Yes, it's a problem across targets. I first caught it when compiling
for an x86_64-linux target.
> For example, a
> comm
On Wed, Jun 30, 2010 at 2:07 PM, Ozkan Sezer wrote:
> On Thu, Jul 1, 2010 at 12:00 AM, Paarvai Naai
> wrote:
>> Hi,
>>
>> I want to gain an understanding for the reasoning behind the
>> "libtool_patch" function used in the "Custom toolchain builds&
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 instructions
found on the mingw-w64 project page:
http://sourceforge.net/apps/trac/
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 to GCC 4.4.4. This is
because I found an optimization bug in GCC 4.5.0 that results i
13 matches
Mail list logo
