Current libtool does not yet work with lto. When generating symbol lists, it does not grep out __gnu_lto_v1 (BTW, which would be the right pattern to grep out?) Anyway, that can cause something like this to happen: cat >a.c <<'EOF' extern char __gnu_lto_v1; const struct { const char *name; void *address; } lt_libltdl_LTX_preloaded_symbols[] = { {"__gnu_lto_v1", (void *) &__gnu_lto_v1} }; EOF gcc -fno-builtin -fPIC -c a.c gcc -flto -fPIC -shared -o liba.so a.o resulting in this: lto1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. lto-wrapper: gcc returned 1 exit status collect2: lto-wrapper returned 1 exit status And yes, the lack of -flto in the compile line is another bug in libtool.
Confirmed. Note that I think libtool also strips -flto from the linker commandline. The proper way to fix this bug is to stop emitting this artificial symbol but instead use another way to identify object files with LTO content. For example by checking if the required sections are available or by emitting and checking a ELF note.
(In reply to comment #1) > Confirmed. Note that I think libtool also strips -flto from the linker > commandline. Naturally. It may be regarded as a feature that libtool strips the flag as long as it doesn't support it properly, <http://thread.gmane.org/gmane.comp.gnu.libtool.general/10794/focus=9757>, and as long as there are bugs in lto for functionality that libtool requires.
So __gnu_lto_v1 is no longer produced after r10-2015 but __gnu_lto_slim is still produced. Looks like __gnu_lto_slim can be removed too after https://sourceware.org/bugzilla/show_bug.cgi?id=24768 is fixed.