On Tue, 2021-12-28 at 00:42 +0900, Jason Yang via Gcc-help wrote: > Dear GCC developers: > > If this email address is not correct for questions, please help forward > this email. Sincerely sorry that I just find this email on gcc.gnu.org > website and hope my question can be answered. > > I am currently working on building cpython with gcc. The problem is that > after turning on lto option, such as the following I've been using --with-lto building Python 3 for a while. No problems observed. /* snip */ > When I enabled the LTO flags and built cpython with optimization (enable > –with-lto, -fuse-linker-plugin, -ffat-lto-objets, -flto-partition=none, > -flto), the built python3 will encounter segmentation fault when I > trying to run it on another host (not using Docker ,but using some > LD_PRELOAD hacks created sandbox, which means host libc will be involved > during the initialization), when I use Docker (isolated namespaces) with > LTO compiled python3, there is no such segmentation fault issue. > My guess is that LTO has requirements for gcc link/compiler environments? Yes. But it does not have requirements for runtime environments, so it should be irrelevent to the segfault. > Though I’ve read this url > https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html ; > <https://gcc.gnu.org/onlinedocs/gccint/LTO-Overview.html> > > but still could not understand whether the LTO is link/compiler > specific? and how about its portability(compiled in one environment, and > can be used in another environment with different link/compiler versions? ) It's not portable. For example, you can't link GCC LTO objects with LLVM linker plugin, or vice versa. And you can't use GCC linker plugin to link the LTO objects compiled by an old GCC release if LTO_major_version has changed (for example, see https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568286.html). -- Xi Ruoyao <xry111@xxxxxxxxxxxxxxxx> School of Aerospace Science and Technology, Xidian University
