[Cryptlib] Use $CC instead of gcc

[Jeffrey Walton]

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.

They also define __GNUC__. Its really annoying behavior at times
because Clang can't consume the same set of programs that GCC can. For
example, you can't build Asterisk with Clang because the project uses
trampolines.

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

Yes. I regularly test against Intel's ICC/ICPC, too. ICC/ICPC is a
good test case because it produces the fastest code of all the
compilers. Its also ruthless about removing undefined behavior.

Intel offers a free academic license at
https://software.intel.com/en-us/articles/non-commercial-software-development.

https://trac.macports.org/browser/trunk/dports/devel/cryptlib/files/patch-tools-ccopts.sh.diff?rev=85985
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.
CC may need to be set to a default value such as "gcc" earlier in this script, as is already done in the companion script ccopts-crosscompile.sh.
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.

_______________________________________________
Cryptlib mailing list
***@mbsks.franken.deAdministration via Mail: cryptlib-***@mbsks.franken.de
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.

[Peter Gutmann]

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
***@mbsks.franken.deAdministration via Mail: cryptlib-***@mbsks.franken.de
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.