EV fails to install on OS X 10.7

Marc Lehmann schmorp at schmorp.de
Thu Feb 2 13:10:30 CET 2012


On Thu, Feb 02, 2012 at 10:01:26AM +0400, Alexey Borzenkov <snaury at gmail.com> wrote:
> As far as I understand this specific place is for adding inline
> assembly for different *architectures*, this shouldn't be about
> compilers too much, as long as compiler supports __asm__. If __llvm__

Thanks, I'll think about that.

> Hmm, you're right, although I'm not sure about portability (even
> though I code in C I never actually read the standard, so I don't
> really know what's supposed to happen here).

Well, the right thing obviously (6.9.1 External object definitions). It's
portable to every C compiler, something which clang is relatively far
away, which is why it isn't worth supporting it yet, it's just too buggy
(being so young, thats somewhat expected).

> Although when I previously saw such a trick the symbol in libraries
> was always declared extern, and there was a separate .c file that only
> defined this global variable.

And how do you propose does this work when the symbol is static? Libev has
to support both.

> However, I'm not sure why you really need this. If user embeds libev,
> then this variable would be static wherever user includes ev.c and
> libev should use that.

No, if the variable is static it cannot be used outside the file it is
defined in, which breaks most embedders. This is solely about whether the
symbols themselves are externally visible or not. In most cases, it has
to be externally visible, but not in EV, because it uses only a single
translation unit and libev symbols aren't used by anybody else.

For EV, this is useful in case another perl module links against a shared
libev, to keep the symbols separate (the EV ABI is incompatible to the
normal libev one).

> definitions wouldn't be compiled, and when user includes ev.h symbols
> will be declared extern, so the inline function will refer to extern
> symbol define elsewhere. I'm confused what is this elaborate construct
> for?

To support both static and external definitions of all symbols.

In any case, this, again, hightlights exactly why I am not so keen on working
around compiler bugs.

1. This is an obvious bug in clang, the libev code is perfectly fine C,
   and works with virtually any other C compiler.
2. clang apparently is not the default compiler on any system where this
   is relevant (for good reasons, IMHO, it's just not there yet).
3. I am spending a lot of time explaining C, when I could actually do useful
   work.

I am not accusing you to steal my time, and I would be happy to discuss C
declaration semantics with you, but not in the context of "why is this
necessary" - if you don't understand C well enough to understand static vs.
extern, then nothing stops you from learning it.

So it happens again - we are disucssing, at length, another obvious bug in
clang and I get told my code should support it somehow.

But this is not how it works - my code is completely fine and valid C, and
arguing that _I_ should do something to help apple in it's quest to destroy
free software for a non-default compiler is really annoying, not the first
time, but when it happens continuously.

It's also not as if alternatives would not be readily available.

So, we can discuss the merits of tentative definitions and the meaning
of extern, but not in the context of "EV should be changed to accomodate
outragously buggy compilers".

If this was an obscure bug in the optimiser or something like that, sure,
happens all the time, but this is a bug where the compiler doesn't even
parse "extern" and "static" correctly, and there is no question it needs
to be fixed in clang.

In any case, disucssions such as these, which are *completely* irrelevant,
because clang isn't used for perl on apple, drive the maintainance effort of
my software on apple into enourmous heights. All other platforms combined do
not eat as much time as these useless discussions, and this is the reason why
I am getting more and more inclined to really drop support for this platform.

It's obvious that you like clang, but libev and EV are written in C, not
clangs incompatible dialect of it, and on top, it's trivial to work around
this problem if you really insist on using 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?
> 
> Both. There's no plain gcc anymore, and XCode uses clang by default
> (although you can still override). However most of system software
> (Perl, Python, etc.) are compiled with llvm-gcc, so their build
> systems compile extensions with llvm-gcc too.

So that means there is no reason to support clang for EV.

Note that libev compiles with clang (3.0, earlier versions don't.)

> The future seems to be for clang to become the only compiler on Apple,

Let's hope that apple has the grace of fixing it then.

> directly. The most frustrating part is that llvm in llvm-gcc seems to
> be a private copy and older (LLVM build 2336.1.00 whatever that is)
> than the one used by clang is newer (LLVM 3.0svn). Some bugs seem to
> come from this old/buggy llvm version, I have an interesting case

llvm doesn't support llvm-gcc anymore, so it's not surprising that apple
finds it difficult to keep porting a dead piece of code to newer versions
of llvm.

> I searched were that it wasn't coming, as maybe one reason that Apple
> jumped on clang bandwagon was to avoid GPLv3+ that gcc >= 4.2.2 use
> (and Apple is frozen in 4.2.1 land).

Yes, of course, all these changes are motivated by GPLv3: apple is the
biggest enemy of free software at the moment, one more reason not to play
their games.

> So the bottom line is that llvm-gcc is crap even when it works, but
> it's default right now (and we have to deal with it) simply because
> chunks of the OS are compiled with it, however clang is pushing to
> become the default in the future and it's good to support both (at
> least I try to test both).

There is no value in supporting a compiler that can't even even compile
simple statc/external declarations. It only leads to madness.

clang should just fix that bug, and everybody will be happy.

Any discussion about that is just a big waste of time.

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