gambit-c @4.7.6 Change compiler and add desirable ./configure option

[somebody-237654]

Executive Summary:

The Gambit-C package should be compiled using recent versions of the “macports-gcc” compiler package. Note that I am deliberately distinguishing between the Apple version of GCC (“gcc-4.0”, “apple-gcc-4.0”, etc.) and the purer MacPorts version. Additionally, the “--enable-single-host” option should be specified to the “./configure” script when gambit is built.

Justification:

The Gambit-C package is a high-performance interpreter and compiler for the Scheme (LISP-family) programming language. The gambit compiler works by first translating Scheme source code into C code, which is then compiled using the system’s C compiler. Because Scheme programs can have a very nonlinear flow of control, including advanced features such as first class continuations, the C code produced by the gambit compiler is complicated and not intended for human consumption - it is an intermediate form generated by one compiler for another compiler, principally consisting of a single, exceedingly large, C function (a “trampoline” function).

Note that the gambit compiler itself is mostly written in Scheme, so the choice of C compiler affects the building of the gambit package by the Macports buildbot, not just the usage of the gambit package by the end user.

The complex nature of the intermediate C code generated by gambit tests the limits of even modern C compilers. My recommendation that the purest version of GCC (“macports-gcc”) be used to compile gambit is not based on compiler favouritism; past versions of all of the common compilers, GCC, LLVM, clang, and the Apple versions of these compilers, have had troubles compiling gambit C code in the past. But the original author of gambit “highly recommends” using GCC [see 1]. And currently it seems that recent versions [4] of the GCC compiler perform the best, and the difference between GCC and the other compilers is significant (30 times faster to compiler the gambit scheme compiler than even the Apple GCC compiler!) [3].

Lastly, I would argue that the “--enable-single-host” option should be specified to “./configure” when gambit is built because this option dramatically improves the efficiency of the compiled code, and because this option is highly recommended by the original author of the gambit package [2]. Note that adding “--enable-single-host” increases the time needed to compile gambit, and this has caused problems for the macports buildbot in the past, when the pure macports gcc compiler was not used [for example, see #46013]. The improvement in compile-time when using the macports-gcc package should more than offset the increased build time incurred by highly desirable “--enable-single-host” option.

- William

Notes:

From: ​http://gambitscheme.org/wiki/index.php/Configure_script_options

[1] “It is also highly recommended to use the GCC compiler to build the system as the source code can take advantage of some GCC extensions. Notably the use of GCC's computed gotos reduces the execution time by roughly 35%.”

[2] “It is highly recommended to use the --enable-single-host option to improve the execution speed and compactness of the executables … [for example] the speed of the Gambit-C interpreter improves by a factor of 2 as a result.”

[3] From: ​https://webmail.iro.umontreal.ca/pipermail/gambit-list/2015-January/007698.html

“As can be seen, the Apple C compilers build Gambit in roughly 30 minutes, which is about 30x slower than when using GNU gcc 4.9.2 . The execution time is also better for GNU gcc, about 2.3x faster. So on OS X it is clearly advantageous to install GNU gcc when using Gambit.”

[4] From: ​https://github.com/Homebrew/homebrew/commit/beb68f8a63243587ea736fd61e7cea2af4fdf9ab#Library/Formula/gambit-scheme.rb

“don't try to build with GCC 4.2 or 4.3 … requires absurd amounts of RAM”

[ryandesign (Ryan Carsten Schmidt)]

The compiler value macports-gcc means "the version of FSF gcc selected by the user by running sudo port select gcc". No port should specify this compiler value, because it would result in the port building differently depending on which compiler the user has selected (see ReproducibleBuilds), and causing the port to fail to build on the buildbot and for any users who have not selected any gcc. In my opinion, MacPorts should not offer macports-gcc as a possible value for configure.compiler.

Ports that need to use FSF gcc should offer variants so the user can choose which version of FSF gcc to use, with one (usually the most recent stable version, which at the present time is gcc5) being the default. The compilers 1.0 portgroup should be used to offer these variants.

Using FSF gcc is problematic on OS X because software built with it will use FSF gcc's libgcc_s. On non OS X systems this is not a problem because the OS and everything else is already using that libgcc_s. On OS X, the OS and software compiled using clang, llvm-gcc or Apple gcc use Apple's copy of libgcc_s, a.k.a. libSystem, which might not be 100% compatible with FSF gcc's. I don't know what effect these issues might have on gambit-c or other software that might be built using gambit-c but it is the usual reason why we do not use FSF gcc, even if upstream developers state that it is preferred, because upstream developers often do not understand this nuanced situation as it applies to OS X.

Additional complications arise if any C++ code is used; see wiki:FAQ#libcpp. (I don't know if gambit-c uses any C++.)

[somebody-237654]

Thanks Ryan for your comments. Indeed, I did not know the rationale behind the choice of default C compiler in macports.

I have tested the gcc5 compiler (macports-gcc-5) by compiling the gambit package itself, and by then using that gambit and the gcc5 compiler to compile some little scheme programs, and it seems to work well. I feel pretty strongly that the benefits of using this compiler with the "--enable-single-host" configuration option are worth pursuing.

Perhaps we could compromise by: (1) switching the configure.compiler option to specify "macports-gcc-5", and (2) adding that compiler as a dependent? This way I assume that the compatible version of libgcc_s will exist on the user's system. Additionally, a “notes” section could be added to the Portfile explaining that an atypical compiler is recommended for this package.

I have made these changes, and uploaded the new .diff file for your perusal.

With regard to your comments regarding C++…

From upstream: ​http://gambitscheme.org/wiki/index.php/Configure_script_options :

“The option --enable-cplusplus should be used when applications developed with the Gambit-C compiler are to be linked with code or libraries written in C++. This will compile all of the Gambit-C source code with a C++ compiler instead of a C compiler (this is possible because the code generated by the Gambit-C compiler conforms both to C and C++).”

I have wrapped this option into a new variation (called: “cpp”).

[somebody-237654]

Second version of .diff file

[somebody-237654]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

In MacPorts, we typically use "cxx" (not "cpp") as a substitute for the term "C++" in situations where the "+" symbol is not allowed, for example port names and variant names. "cpp" typically means C pre-processor.

There is no need to manually add a dependency on gcc5; setting configure.compiler to the desired compiler automatically adds the required dependency.

If another version of gcc would also work, you should offer compiler variants, using the compilers 1.0 portgroup, rather than forcing the use of gcc5.

I still don't know that I approve of the change of compiler, for the reasons stated, especially with regard to the C++ support added by the variant. If users are going to use C++ code linked against gambit-c C++ code, then they absolutely must use the same C++ library; not doing so will result in build failure. Forcing the user to use g++ instead of clang++ might be problematic for some use cases.

I would also suggest that C++ support should be always-on. Why make it a variant? Variants make it difficult for other ports to depend on that feature.

[barracuda156]

Is it for a good reason that gcc-4.2 is not blacklisted, despite the statement above: “Don't try to build with GCC 4.2 or 4.3 … requires absurd amounts of RAM”?

The build makes this warning:

***                                                                    ***
*** The GCC compiler that is being used has problems compiling Gambit  ***
*** generated code when the normal set of C compiler optimizations are ***
*** enabled and the configure flag "--enable-single-host" is           ***
*** specified.  It can take over 20 GB of virtual memory to            ***
*** compile some files.  For this reason the GCC compiler optimization ***
*** which performs loop invariant code motion has been disabled by     ***
*** adding the GCC command line option "-fno-move-loop-invariants".    ***
*** This greatly reduces compile time space requirements and it has a  ***
*** small impact on overall run time performance, but for some tight   ***
*** loops the effect is larger.  If you want to avoid this problem     ***
*** then upgrade your version of GCC to 4.4 (or above hopefully) or    ***
*** downgrade to a version prior to 4.2 .                              ***
***