[m-rev.] for review: Make link-time optimisation with gcc work.

Julien Fischer jfischer at opturion.com
Tue Jan 28 15:24:34 AEDT 2020



On Tue, 28 Jan 2020, Peter Wang wrote:

> On Tue, 28 Jan 2020 15:12:46 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
>>
>> Hi Peter,
>>
>> On Tue, 28 Jan 2020, Peter Wang wrote:
>>
>>> configure.ac:
>>>    Add -flto to LINK_SHARED_OBJ and LINK_SHARED_OBJ_SH commands
>>>    when LTO is enabled with gcc.
>>>
>>>    Search for and use LTO-aware gcc-ar, gcc-ranlib and gcc-nm
>>>    programs in place of the normal tools.
>>>
>>> diff --git a/configure.ac b/configure.ac
>>> index 3e7e10c09..6dbee8860 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -5348,7 +5348,19 @@ if test "$mercury_cv_lto" = "yes"; then
>>>             CFLAGS_FOR_LTO="-GL"
>>>             LDFLAGS_FOR_LTO="-LTCG"
>>>             ;;
>>> -        gcc*|clang*)
>>> +        gcc*)
>>> +            CFLAGS_FOR_LTO="-flto"
>>> +            LDFLAGS_FOR_LTO="-flto"
>>> +            LINK_SHARED_OBJ="$LINK_SHARED_OBJ -flto"
>>> +            LINK_SHARED_OBJ_SH="$LINK_SHARED_OBJ_SH -flto"
>>> +            AC_CHECK_TOOL([GCC_AR], [gcc-ar], [])
>>> +            AC_CHECK_TOOL([GCC_RANLIB], [gcc-ranlib], [])
>>> +            AC_CHECK_TOOL([GCC_NM], [gcc-nm], [])
>>
>>
>> Is that going to work in situations where the gcc executable is not
>> named gcc.  (For Homebrew, it is named gcc-9, gcc-8 etc.)
>> (We don't need to support that case now however.)
>
> I don't know. As long as gcc-ar etc. are still available without the
> version suffix, otherwise I assume they won't be found.

I don't know what they're named on that machine; I'll check this
evening.

Julien.


More information about the reviews mailing list