[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP41FADEE5972AC61817618BFD100@phx.gbl>
Date: Sun, 20 Jan 2013 19:22:39 +0100
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: clang build error
On 01/20/2013 05:21 PM, magnum wrote:
> On 20 Jan, 2013, at 16:17 , Frank Dittrich <frank_dittrich@...mail.com> wrote:
>> (unstable-jumbo)src $ git diff
>> diff --git a/src/common.h b/src/common.h
>> index 4efff92..49bda4c 100644
>> --- a/src/common.h
>> +++ b/src/common.h
>> @@ -29,7 +29,7 @@ typedef unsigned long long ARCH_WORD_64;
>> #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 7)
>> #define MAYBE_INLINE __attribute__((always_inline)) inline
>> #elif __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
>> -#define MAYBE_INLINE __attribute__((always_inline))
>> +#define MAYBE_INLINE __attribute__((always_inline)) inline
>> #else
>> #define MAYBE_INLINE __inline__
>> #endif
>
> Ah, I did not get that you wanted to reproduce the problem.
Solar asked for the specific error message.
(I should indeed have listed it in my earlier mail.)
>> 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.
I only have gcc 4.7.2 and gcc 4.6.3 on my systems.
Frank
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.
