On Wed, Jan 25, 2012 at 10:16:32AM +0400, Alexey Borzenkov <[email protected]>
wrote:
> Hi Marc,
>
> On Mon, Jan 23, 2012 at 5:44 PM, Marc Lehmann <[email protected]> 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
--==---/ / _ \/ // /\ \/ / [email protected]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
