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 17:21:36 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: clang build error

On 20 Jan, 2013, at 16:17 , Frank Dittrich <frank_dittrich@...mail.com> wrote:
> On 01/20/2013 01:08 PM, magnum wrote:
>> This looks more like a "make clean" miss, or something wrong with the build target. But Bull can build that target.
> 
> With a new clone of latest git:

> and this change:
> (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.

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

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.