Re: [PATCH 1/4] Support GCC LTO on GNU/Linux.

[Charles Wilson]

On 4/4/2010 4:55 AM, Ralf Wildenhues wrote:
> * NEWS: Update.
> * libltdl/config/ltmain.m4sh (func_mode_link): Allow through
> flags matching -O*, -flto*, -fwhopr, -fuse-linker-plugin.
> * libltdl/m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS): Drop symbols
> starting with __gnu_lto.
> (_LT_LINKER_SHLIBS) [linux] <archive_cmds, archive_expsyms_cmds>:
> Add $pic_flag for GCC.
> (_LT_LANG_CXX_CONFIG) [linux] <archive_cmds, archive_expsyms_cmds>:
> Likewise.
> <output_verbose_link_cmd>: Only list lines starting with a space
> and containing 'collect'.
> (_LT_SYS_HIDDEN_LIBDEPS): Ignore files matching *.lto.o.
> Suggested by Török Edwin and Simon Richter.

One thing I worry about -- but can't test on my platform, since cygwin's
compiler is not up to the latest-and-greatest yet so doesn't yet support
LTO -- is whether this bit, in the cwrapper, will break:

const char * MAGIC_EXE = "$magic_exe";

where $magic_exe is "%%%MAGIC EXE variable%%%", and is used by the test
in func_ltwrapper_executable_p():

    $GREP "$magic_exe" "$1$func_ltwrapper_exec_suffix" >/dev/null 2>&1

IOW, we directly grep the binary cwrapper for the magic string "%%%MAGIC
EXE variable%%%", as a kind of sigil to indicate that the specific
executable IS, in fact, a cwrapper.

It's been my understanding that sticking random static variables into an
application, when that variable is never accessed by the app's code, is
one of the things that gets "optimized out" by LTO.

Can anybody confirm that this sort of thing will continue to work, even
with LTO turned on?

--
Chuck