On Tue, May 14, 2024 at 2:06 AM James K. Lowden <jklow...@schemamania.org> wrote: > > On Wed, 8 May 2024 21:40:44 +0200 > Jakub Jelinek <ja...@redhat.com> wrote: > > > Perhaps you don't link cobol1 with the correct make variables > > as other FEs are linked? > > First, thank you for the careful answer. It allowed me to trace > through the machinery. And I confirmed that it works, usually. > > The Make-lang.in for the cobol1 compiler was modelled on the one for > fortran and, indeed, it's usually built statically linked to libstdc++: > > $ g++ -no-pie -g3 -DIN_GCC -fno-exceptions -fno-rtti > -fasynchronous-unwind-tables [...] -fno-common -DHAVE_CONFIG_H -no-pie > -static-libstdc++ -static-libgcc attribs.o -o cobol1 [...] > > As we would expect, ldd(1) reports that output is not linked to libstdc+ > +.so. > > Where things appear to go awry is when I try to take a shortcut: > > $ make -C build install
I don't think that's designed to work. You should do make -C build && make -C build install Also note that when you are not bootstrapping you get cobol1 linked to the host compilers libstdc++ dynamically I think (same for stage1 when bootstrapping). > where "build" is the top of the gcc build tree, where we'll eventually > find build/gcc/cobol1. When done that way, cobol1 sometimes ends up > dependent on libstdc++.so. > > I haven't tried to find out why that is, whether it's something we're > doing, or something more general. It does seem like more gets built > than needs to be when I do that. <shrug> > > For now, at least I understand what the expected outcome is. The > compiler should be statically linked to the C++ library. When it's > not, something went wrong. > > --jkl
