[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
