Hey Ruben - I just realized that you have disabled gfortran in your
builds. I hadn't noticed it until a couple of weeks ago when I
downloaded the 4.7.0-1 build and found that gfortran is gone. I checked
your build scripts and sure enough you have disabled the fortran build
in common.sh as of De
sorry, just noticed that gentoo uses snapshots and proper release is
now in place.
2.0.1 is ok!
On Sat, Feb 25, 2012 at 1:28 AM, JonY wrote:
> On 2/25/2012 07:05, Alon Bar-Lev wrote:
>> Hello,
>> Should be supported, right?
>> Thanks!
>> Alon
>> ---
>> #include
>> #include
>>
>> int main(void)
On 2/25/2012 07:05, Alon Bar-Lev wrote:
> Hello,
> Should be supported, right?
> Thanks!
> Alon
> ---
> #include
> #include
>
> int main(void) {
> _wctime(NULL);
> return 0;
> }
> ---
> $ i686-w64-mingw32-gcc -pedantic -Wall -Wextra a.c
> /usr/lib/gcc/i686-w64-mingw32/4.5.3/../..
Hello,
Should be supported, right?
Thanks!
Alon
---
#include
#include
int main(void) {
_wctime(NULL);
return 0;
}
---
$ i686-w64-mingw32-gcc -pedantic -Wall -Wextra a.c
/usr/lib/gcc/i686-w64-mingw32/4.5.3/../../../../i686-w64-mingw32/lib/libmingwex.a(lib32_libmingwex_a-_wctime32.
Op 24 feb. 2012 17:36 schreef "Kai Tietz" het
volgende:
>
> Hmm, well, if Clang doesn't need this define we can guard it in our
> header for it.
It's only problematic when compiling clang itself, it being a builtin
shouldn't be a problem for other code I think.
>
> Otherwise it might be also an
Hmm, well, if Clang doesn't need this define we can guard it in our
header for it.
Otherwise it might be also an option to do in clang an undefine at the
place you mentioned.
Regards,
Kai
PS: All my patches I wanna to see in 4.7 are committed. Also recent
regression in binutils is fixed. So I
I believe my latest 4.7 build (which uses trunk instead of v2.x) has a
conflict with Clang, which defined its builtins inside C++ code (which is
altered by the macro)
I can remedy the problem in Clang by #undef'ing the macro before Clang's
builtins are defined, but before submitting a patch I wond
