Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 20 Jan 2013 15:03:07 +0400
From: Solar Designer <>
Subject: Re: clang build error (was: New compiler warnings)

On Tue, Jan 15, 2013 at 11:35:24PM +0100, Frank Dittrich wrote:
> On 01/15/2013 11:05 PM, magnum wrote:
> > On 15 Jan, 2013, at 22:29 , magnum <> wrote:
> >> 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.

OK, let's make this change.

> > I also replaced a similar construct in dummy.c to MAYBE_INLINE, maybe you should in core too.

It's already MAYBE_INLINE in dummy.c in core (for some months).

> 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)

That's bad news.  What specific error message did clang give?


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.