On 02/08/2018 04:42 AM, Aldy Hernandez wrote: > In this PR, the reporter is complaining that forcing -static-libstdc++ > and -static-libgcc during stage1 will also force it down to all > subdirectories (gdb for instance). > > There is some back and forth in the PR whether this is good or not. I'm > indifferent, but an alternative is to provide a flag > --disable-stage1-static-libs to disable this behavior. > > Tested on an x86-64 Linux system with static libraries and verifying > that with --disable-stage1-static-libs we get an xgcc linked against > shared libraries of libstdc++ and libgcc: > > $ ldd xgcc > linux-vdso.so.1 (0x00007ffe92084000) > libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fec11a06000) > libm.so.6 => /lib64/libm.so.6 (0x00007fec116fd000) > libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fec114e6000) > libc.so.6 => /lib64/libc.so.6 (0x00007fec11120000) > /lib64/ld-linux-x86-64.so.2 (0x0000557117206000) > > I also verified that without the flag or with > --enable-stage1-static-libs we get no such shared libraries. > > Again, I'm agnostic here. We can just as easily close the PR and tell > users to specify --with-stage1-libs to override the static linking, as > I've mentioned in the PR. > > OK for trunk? > > curr.patch > > > > PR bootstrap/56750 > * configure.ac (stage1-static-libs): New option. > * configure: Regenerate. > > gcc/ > > PR bootstrap/56750 > * doc/install.texi (--enable-stage1-static-libs): New. You are a brave soul.
Every time I look at 56750 I shake my head and say it's not worth the pain to untangle (sorry Mike). There's no single solution here that will satisfy everyone that I'm aware of. Given that there is a workaround that I think will work for the problems Mike is trying to address, I think this is a WONTFIX. Another configury option just adds more complexity here that we're not likely to test and is likely to bitrot over time. Go ahead with WONTFIX and if Mike complains, point him at me :-) jeff
