EV fails to install on OS X 10.7

Marc Lehmann schmorp at schmorp.de
Thu Feb 2 04:26:53 CET 2012


On Wed, Jan 25, 2012 at 10:16:32AM +0400, Alexey Borzenkov <snaury at gmail.com> wrote:
> Hi Marc,
> 
> On Mon, Jan 23, 2012 at 5:44 PM, Marc Lehmann <schmorp at schmorp.de> wrote:
> > I tested EV before release and it seems to compile fine, but I cannot test
> > on os x 10.7.
> 
> I just did and there are two issues. First, it seems llvm is
> deliberately excluded from ecb.h, but after this patch:

Ahh, that makes more sense - the trouble with __llvm__ is that it's
defined by a lot of compilers - is there a more specific way to check for
apple's compiler, or is this guaranteed to work with all compilers that
define __llvm__?

> Now I know that llvm-gcc was very broken in the past (and maybe even
> today), but it seems that all tests pass in my case (Mac OS X 10.7.2,
> XCode 4.2.1), is there anything else I could test to make sure it
> works?

Only by heavily using it or so. The tests should cover most basic issues
though, and covers all known llvm/clang bugs (it didn't link in previous
versions because it optimised out static variables that were in use - of
course, that can be luck only).

> Second, clang is a more strict C compiler and when I try to use it, it
> gives lots of warnings, but there's one error:

Yes, we know of that bug, but we don't kbnow a workaround for it at the
moment (neither gcc nor dragonfly seem to have it, and apparently, neither
apples llvm-gcc).

Best is to report it and hope for a quick fix, clang has matured quite
fast in the past.

> /libev/ev.c:1237:31: error: static declaration of
> 'ev_default_loop_ptr' follows non-static declaration
>   EV_API_DECL struct ev_loop *ev_default_loop_ptr = 0; /* needs to be
> initialised to make it a definition despite extern */

The error mesage is slightly confusing, because the problem here is a
definition following a tentative definition. If clang has a problem with
that, it is free to issue a warning, but it should compile the code.

> libev/ev.h:552:26: note: previous definition is here
>   extern struct ev_loop *ev_default_loop_ptr;
>                          ^
> Which is actually pretty strange on part of libev, why is
> ev_default_loop_ptr extern, when 5 lines above it is already defined
> as EV_API_DECL?

Because we always need to refer to the outside symbol, and using extern
does that, even for static variables only tentatively defined.

> Anyway, a simple patch:

libev supports having its symbols external as well as static, which
requires this maybe surprising but valid construct to work portably.

One can comment out the "#define EV_API_STATIC" in EV.xs, to get it to
compile even with clang.

However, I am a bit confused - which compiler is used on apple, clang or
llvm-gcc (or even dragonfly by now?), or yet another one?

Since clang is very young, it is expected to iron out such bugs, and if it
isn't the default compiler, I don't want to add code to work around parser
bugs.

On the good side, that EV links and loads successfully is definitely
a new and positive development. It means older versions of EV would
probably work out of the box, which means waiting for a fix is actually
not unreasonable.

> The rest are about unused values in assert (technically, all those
> strings are actually unused, but it's quite a common idiom for
> asserts, so clang is too pedantic here).

As long as it's warnings only they can be safely ignored, but making valid
code not an error is of course quite a bit more annoying.

Thanks a lot for looking into this!

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\



More information about the libev mailing list