[tlbuild] gcc vs. clang in icu

[Mojca Miklavec]

On Tue, Mar 26, 2013 at 10:52 PM, Karl Berry wrote:
> Dick reported the following.  I wanted to reply on the list so it would
> end up in the archives.
>
>     The whole compile uses [gcc], EXCEPT the icu compile. It's configure
>     utility checks for clang and clang++, finds them, and uses
>     them. Recall that llvm-clang is another open source compiler system,
>     which Apple supports. In Lion Apple switched completely to this
>     system and removed gcc. I believe gcc and clang are compatible, so
>     the fact that clang is used for icu causes no harm. But I wouldn't
>     bet my house on it.)
>
> I wouldn't bet a nickel on it.  Indeed, I find it amazing that this
> works at all -- clang++ and g++ do precisely the same name-mangling of
> symbols?  Seems sooo unlikely, but I guess that is the inescapable
> conclusion, otherwise your xetex wouldn't link.
>
> Anyway, it's certainly true
> (Build/source/libs/icu/icu-51.1/source/configure.in, line 119) that icu
> goes to a lot of trouble to disable the user's chosen compiler and
> preferentially use clang[++] from PATH.  I can't express how bad of an
> idea I think this is.  It seems they do not even provide a way to
> override it.
>
> One viable option is to leave bad enough alone until a user-level
> problem is seen.  Otherwise, I would suggest temporarily making clang
> and clang++ be symlinks to /bin/false for your build (in $HOME/bin or
> some such early directory in your path), so configure will presumably
> not consider them working compilers and use gcc/g++ instead.  Of course,
> I won't be surprised if ICU then starts to misbehave :).

To Karl: users have been testing XeTeX for about a month and that one
has been built *exactly* in the same way - using clang(++) for
building ICU and gcc for everything else. Nobody complained about any
problem related to this while the number of other reports has been
relatively extensive, but it is also true that the number of users
testing this has been small.

It would probably be better to use just clang for the whole build
(rather then setting clang to /bin/false) if compiling with the same
compiler is so important, but then one would hit the error that I
reported earlier (possible to overcome).

I have no idea why this works, but I didn't try to guess. As far as
shared libraries are concerned, there are lots of packages in MacPorts
that need(ed) to be built with llvm-gcc or some other gcc compiler
because they wouldn't compile with clang. And most of their
dependencies are built with clang. I don't remember any major problems
related to that except for this one:
    https://trac.macports.org/ticket/34806 - mkvtoolnix needs boost
and icu built with same compiler

That is: the program mostly works except when it doesn't. (I tried to
manipulate a long video and the program crashed during some
operations.)

I would like to warn that there is a fair chance that ICU would try to
be built with clang also on other platforms in case that clang exists.

Mojca