On Mon, Nov 2, 2009 at 12:14 PM, Kai Tietz <ktiet...@googlemail.com> wrote: > 2009/11/2 Ozkan Sezer <seze...@gmail.com>: >> 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 >>> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:708: error: called >>> object '1' is not a function >>> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:713: error: called >>> object '1' is not a function >>> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:731: error: called >>> object '1' is not a function >>> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:760: error: called >>> object '1' is not a function >>> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:764: error: called >>> object '1' is not a function >>> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:790: error: called >>> object '1' is not a function >>> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:793: error: called >>> object '1' is not a function >>> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:823: error: called >>> object '1' is not a function >>> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:870: error: called >>> object '1' is not a function >>> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:888: error: called >>> object '1' is not a function >>> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:904: error: called >>> object '1' is not a function >>> /home/slack/gcc/binutils-cvs/libiberty/getopt.c:953: error: called >>> object '1' is not a function >>> make[3]: *** [getopt.o] Error 1 >>> >>> Hi >>> I have no idea what is happening with the w64-headers it seems to be >>> unable to compile binutils target=x86_64-w64-mingw32 the >>> mingw-w64-headers from 101009 worked Ok. >>> Anyone got a solution ? Or idea of which commit caused the breakage? >>> Thanks. >> >> Is this problem reproducible with revision 1508 of the >> headers? >> >> -- >> Ozkan >> > > This issue is related to the definition in _mingw_mac.h of a temporary > _ as 1. If you add here before the pop_macro call an '#undef _' (we > did this already on our trees), does it helps? > > Kai
Kai, this will bite us, and it will bite us very hard if it isn't fixed properly. Our workaround in the headers is very fragile because it relies on the assumption that _mingw.h or _mingw_mac.h is included early enough and all other possible definitions of "_" would come *after* that include which may not be the case at all. -- Ozkan ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
