Date: Sun, 20 Jan 2013 19:31:26 +0100 From: magnum <john.magnum@...hmail.com> To: john-dev@...ts.openwall.com Subject: Re: clang build error On 20 Jan, 2013, at 19:22 , Frank Dittrich <frank_dittrich@...mail.com> wrote: >>> I still get that error when building linux-x86-64-clang (after doing an >>> unnecessary make clean). >>> I can reproduce the error with Fedora 18 (clang 3.1) and Fedora 16 >>> (clang 2.9). >>> >>> On my 32bit Fedora 16 system, building linux-x86-64-clang with the >>> common.h change mentioned above works. >> >> Just out of curiosity, try >> >> #define MAYBE_INLINE inline __attribute__((always_inline)) >> >> instead of >> >> #define MAYBE_INLINE __attribute__((always_inline)) inline >> >> Does it make any difference? > > For linux-x86-64-clang, I get the same error. > > > gcc 4.7.2 produces the same binary with > #define MAYBE_INLINE inline __attribute__((always_inline)) > or > #define MAYBE_INLINE __attribute__((always_inline)) inline > > clang on my 32bit system as well. > > clang 3.1 claims to be compatible to gcc 4.2.1 (didn't change since > clang 2.9). > > What does clang 3.2 claim? May be Dhiru can answer this. > > clang -dumpversion > or > ./john --list=build-info > > If it is still gcc 4.2.x, we could change > #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 7) > in common.h to > #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 3) > > Then, the change affects all gcc versions >= 4.3, but no clang version > up to 3.1 (or even 3.2). > Of course, we should test it with a gcc 4.3 compiler before releasing > this change. Maybe we should just test for __clang__ and be done with it. I doubt any version of gcc will have problems. magnum
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.