Support for different compilers

Volker Simonis volker.simonis at
Mon Feb 3 09:36:54 UTC 2014

Hi Magnus,

I think that supporting multiple compilers per platform will be really
helpful to make the code base more robust and portable.

How do you plan to address the fact that during he build process we
are actually already using two different compilers - the "build"
compiler which builds various tools used during the build process and
the "target" compiler which builds the actual bits of the JDK. There's
already bug "8029375: configure needs a way to customize
compiler/linker options for the "build" compiler"
( which objects that
there's currently no way to specify special flags for the "build"

If we support different compiler families, we should think about this
and if we want to allow different compiler families for the "build"
and "target" compilers.


PS: I'd prefer the name "compiler-family", as suggested by Henry

On Mon, Feb 3, 2014 at 9:12 AM, Magnus Ihse Bursie
<magnus.ihse.bursie at> wrote:
> I agree. The issue with different compilers are basically in the flags and how the toolchain works. The source code should not be modified if it can be avoided. On the other hands, compiler flags typically needs to be completely written from scratch to support a new compiler.
> /Magnus
>> On 3 feb 2014, at 07:43, David Holmes <david.holmes at> wrote:
>> Hi Martin,
>>> On 1/02/2014 4:30 AM, Martin Buchholz wrote:
>>> In practice, every compiler defines preprocessor symbols that allow
>>> conditional compilation based on compiler type.  So there's not much value
>>> in having configure define yet another "compiler family" variable, or at
>>> least not useful within the C/C++ code itself.
>> On the contrary! We want to isolate compiler idiosyncracies to the makefiles/build-system NOT the sources. Compiler based ifdefs should be an absolute last resort in my opinion.
>> David
>> -----
>>> I also think that the "toolchain environment" is much more nuanced.  Each
>>> family comes with a number of variations and version history.  And
>>> low-level libraries may be provided independently of compiler proper.
>>>> On Fri, Jan 31, 2014 at 9:27 AM, Henry Jen <henry.jen at> wrote:
>>>>> On 01/31/2014 08:09 AM, Martin Buchholz wrote:
>>>>> I think it's generally wrong to use a "compiler type" just like it's
>>>>> generally wrong to use a "OS type".  Most code should be portable, and
>>>>> most
>>>>> of the rest should use autoconf features "HAVE_FOO"
>>>>> Getting openjdk to build with random compilers (e.g. icc or clang) without
>>>>> adding too much new code is a very good quality improvement effort.
>>>> I think this proposal is mainly targeting the build process, particularly
>>>> on complier flags, therefore we will need to know what compiler is in use
>>>> to set those flags accordingly.
>>>> On random compiler, we probably can setting with a minimum set of flags
>>>> and expect it to build the product.
>>>> The proposal looks reasonable to me. I assume default would be a ordered
>>>> list of preference on our side instead of a single choice?
>>>> compiler-family or compiler-type works for me. :)
>>>> Cheers,
>>>> Henry
>>>>> On Fri, Jan 31, 2014 at 5:42 AM, Magnus Ihse Bursie <
>>>>> magnus.ihse.bursie at> wrote:
>>>>>  I'm about to start addressing the issue of supporting different compilers
>>>>>> on the same platform.
>>>>>> The major driver for this project is the compiler upgrade that is about
>>>>>> to
>>>>>> happen in JDK 9. On MacOS X, we will be switching from gcc to clang as
>>>>>> default compiler. However, a complete switch at a single time will not be
>>>>>> easy to orchestrate. Instead, we will be supporting both gcc and clang in
>>>>>> parallel. To do this properly, we will have to make sure that the build
>>>>>> system can understand the difference between "compiler" and "platform".
>>>>>> Up until now, we've had only one supported compiler per platform, and
>>>>>> (more or less) a different compiler for every platform. In such
>>>>>> circumstances, code tends to be a bit murky -- should we test for gcc, or
>>>>>> for linux, or possibly both? Apart from the actual instances of testing
>>>>>> for
>>>>>> compiler/platform, there have been no good framework to support this
>>>>>> notion
>>>>>> of compiler vs platform.
>>>>>> My plan is to achieve the following end result for the user:
>>>>>> * A new configure flag, presumably --with-compiler-type which can be set
>>>>>> to any of the supported compiler types: gcc, clang, mscl, oracle-studio.
>>>>>> For every platform, there is a default that will be used if the flag is
>>>>>> omitted. Setting the flag to a non-supported combination will result in a
>>>>>> warning, if it is possible but untested (like gcc on solaris), or a
>>>>>> failure
>>>>>> if it is impossible (e.g. mscl on linux is not available).
>>>>>> * If the flag is set to a non-default but possible value, we'll try to
>>>>>> locate a compiler of the given type.
>>>>>> * Alternatively, one can explicitely request a specific compiler binary
>>>>>> to
>>>>>> be used by setting CC= and CXX=. Setting just one of them will result in
>>>>>> a
>>>>>> warning, since a mismatch is likely in that case. In this case, we'll
>>>>>> test
>>>>>> the given compiler to try to determine it's type. Failure to properly
>>>>>> determine the type will result in an error, since then we don't know what
>>>>>> we're dealing with.
>>>>>> * For users with special needs, maybe running some kind of special build
>>>>>> or a wrapper around gcc, it is possible to combine the two. In that case,
>>>>>> we'll use the binaries pointed to by CC and CXX, and will assume that
>>>>>> they
>>>>>> are of the type given by the --with-compiler-type. We will check if we
>>>>>> agree with the classification, but if not, we will still take the user's
>>>>>> given type by face value and just inform the user of this mismatch. In
>>>>>> this
>>>>>> mode, compile failures can occur even if configure succeeded.
>>>>>> I'd appreciate any input or feedback on this solution.
>>>>>> For instance, is "compiler type" a good name, or would "compiler brand"
>>>>>> be
>>>>>> better?
>>>>>> /Magnus

More information about the build-dev mailing list