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