On Thu, Jul 15, 2010 at 3:11 PM, [email protected] <[email protected]> wrote: > Hi, > On 15/07/2010 9:50 PM, Kai Tietz wrote: >> 2010/7/15 Kai Tietz<[email protected]>: >>> 2010/7/15 [email protected]<[email protected]>: >>>> Hi >>>> On 15/07/2010 8:47 PM, Prof Brian Ripley wrote: >>>>> We're working towards switching over to post-April snapshots, but we >>>>> have 1000s of R packages to recompile. A couple of those (so far) >>>>> have thrown up header conflicts. >>>>> >>>>> Specifically for this report I used >>>>> mingw-w64-1.0-bin_i686-mingw_20100702.zip but I first found the >>>>> problem with a Linux cross-compiler snapshot. This is a distillation >>>>> of a very much more complex issue involving BOOST headers. >>>>> >>>>> If I compile the two-line C++ file test.cpp >>>>> >>>>> #include<process.h> >>>>> #include<cstdlib> >>>>> >>>>> with x86_64-w64-mingw32-g++ -c test.cpp I get >>>>> >>>>> In file included from test.cpp:2:0: >>>>> e:/r/w64/gcc-4.5.1/lib/gcc/../../x86_64-w64-mingw32/include/c++/4.5.1/cstdlib:166:11: >>>>> error: '::_Exit' has not been declared >>>>> e:/r/w64/gcc-4.5.1/lib/gcc/../../x86_64-w64-mingw32/include/c++/4.5.1/cstdlib:204:22: >>>>> error: '__gnu_cxx::_Exit' has not been declared >>>>> >>>>> This code works in the 20100405 snapshot (of 4.4.4). I have a simple >>>>> workaround (#include<cstdlib> at the top of the affected files), but >>>>> the code concerned is not mine and I don't believe that should be >>>>> necessary. The conflict is caused by this block of code >>>>> >>>>> #ifndef _CRT_TERMINATE_DEFINED >>>>> #define _CRT_TERMINATE_DEFINED >>>>> void __cdecl __MINGW_NOTHROW exit(int _Code) __MINGW_ATTRIB_NORETURN; >>>>> _CRTIMP void __cdecl __MINGW_NOTHROW _exit(int _Code) >>>>> __MINGW_ATTRIB_NORETURN; >>>>> >>>>> #pragma push_macro("abort") >>>>> #undef abort >>>>> void __cdecl __declspec(noreturn) abort(void); >>>>> #pragma pop_macro("abort") >>>>> >>>>> #endif >>>>> >>>>> I'd welcome advice about the correct fix here. >>>>> >>>>> Brian Ripley >>>>> >>>> >>>> I think if you build your own compiler and then you do --disable-c99 >>>> this problem will go away but the issue probably isn't there just >>>> because of c99 enabled. >>>> I have encountered this issue on another level of software where this >>>> can be a header inclusion order problem or C99 get enabled problem. >>>> I was investigating such compile problem and found that >>>> incompatibilities when c99 enabled when you include C headers in mixed >>>> fashion with C++ headers this problem tends to occur. >>>> However, it can be simply work-around problem, or alternatively you can >>>> disable-c99. >>>> But it seems you're using the compiler by the buildbot... >>>> Maybe someone else can shed more light on this issue. >>>> >>>> ------------------------------------------------------------------------------ >>>> This SF.net email is sponsored by Sprint >>>> What will you do first with EVO, the first 4G phone? >>>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >>>> _______________________________________________ >>>> Mingw-w64-public mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >>>> >>> >>> The issue is in libstdc++ headers. Here the _Exit doesn't get (as >>> other runtime functions of stdlib.h) no put into std:: namespace. So >>> this is an issue to be address to gcc bugzilla. AFAIR there is already >>> a report for it, but I am not sure. >>> I don't see here a good solution for this to fix this in our headers, >>> but maybe someone of you have an idea how to solve it on our site. >>> >>> Regards, >>> Kai >>> >>> -- >>> | (\_/) This is Bunny. Copy and paste >>> | (='.'=) Bunny into your signature to help >>> | (")_(") him gain world domination >>> >> >> I see the issue in our headers. I prepare a fix for it soon. It would >> be nice if you could test the patch, if it fixes your problem >> (Committed at revision 2837 to trunk). >> >> Thanks for reporting it, >> Kai >> > > Kai: > Thanks for the hot patch at revision 2837 > I tried the patched headers and tried to compile the affected software > library again! This time it compiles successfully! > Great! Now no more need to work around it. > > Best Regards
Kai, can you apply the fix to 1.0 branch, too? (Or sholud I do it?) -- Ozkan ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
