Re: Use $CC instead of gcc

Peter Gutmann <[email protected]> Wed, 15 Apr 2015 02:46:48 +1200
Newsgroups gmane.comp.encryption.cryptlib
Message-ID <[email protected]>
Ryan Schmidt <[email protected]> writes:

>It just replaces a hardcoded invocation of "gcc" with "$CC". In MacPorts we
>want to be in control of what compiler is used, and for cryptlib we do this
>by specifying the CC environment variable when running make, which has the
>desired effect everywhere but this one line of this one script.

There's a historic reason for cryptlib's attempt to use gcc if at all
possible, which was that commercial vendors have traditionally shipped truly
ghastly C compilers (or, in Sun's case, a non-C compiler that pretended to be
a compiler so you had to use all sorts of trickery to determine whether there
was a real compiler present or not).  

To deal with all this brokenness, cryptlib tried really hard to locate and use
gcc if it was available, thus the hardcoding of gcc in various locations in
scripts.

Now the situation has become somewhat reversed, with gcc taking the role of
the broken compiler and clang/LLVM being the one you want to use.

>Note that "$CC -dumpversion" produces the value "4.2.1" when used with any
>version of the clang compiler, presumably on the grounds that clang
>understands code somewhat similarly to gcc 4.2.1. I see you already have code
>earlier in this file to detect whether clang is being used, however this line
>with "gcc" was still being run. On recent OS X versions, where clang is the
>only compiler, "gcc" is usually a symlink to "clang", but the user may have
>changed this, so assuming "gcc" is any particular compiler is not very
>reliable and you should be consistent in always using $CC.

Hmm, so this is why the "if it's not gcc then exit" check just above the
GCC_VER one isn't triggered.  The reason why the GCC_VER check hardcodes in
gcc is because you shouldn't get to that point unless $CC = gcc.

So the solution would be to find some way to detect genuine gcc and apply all
the bug-workarounds for that, and also detect clang and apply clang-specific
options for that.  For that I'd need access to a system on which clang
pretends to be gcc, or alternatively a set of diffs to detect real vs. pretend
gcc.

Peter.

_______________________________________________
Cryptlib mailing list
[email protected] via Mail: [email protected]
Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/
http://news.gmane.org/gmane.comp.encryption.cryptlib
Posts from non-subscribed addresses are blocked to prevent spam, please
subscribe in order to post messages.