[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9f983ddb026f39e49ce0defa661fad68@smtp.hushmail.com>
Date: Wed, 16 Jan 2013 00:28:25 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: clang build error
On 15 Jan, 2013, at 23:35 , Frank Dittrich <frank_dittrich@...mail.com> wrote:
> On 01/15/2013 11:05 PM, magnum wrote:
>> On 15 Jan, 2013, at 22:29 , magnum <john.magnum@...hmail.com> wrote:
>>> Solar,
>>>
>>> Frank pointed out that the following will mute the inline warnings:
>>>
>>> -#define MAYBE_INLINE attribute((always_inline))
>>> +#define MAYBE_INLINE attribute((always_inline)) inline
>>>
>>> Should we commit this? I don't really understand the difference.
>>
>> I did so. Some googling reveals this is a better definition anyway, since at least some compilers will totally ignore that attribute without the inline specification added.
>>
>> I also replaced a similar construct in dummy.c to MAYBE_INLINE, maybe you should in core too.
>
> When I did that common.h change (MAYBE_INLINE definition), I got a build
> error for the linux-x86-64-clang make target.
>
> clang 3.1 claims to be compatible with gcc 4.2.1.
>
> So may be we can only add inline to that definition for __GNUC__ > 4 ||
> __GNUC__ == 4 && __GNUC_MINOR__ >= 7)
I'll add this for now.
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.
