On Tue, May 14, 2024 at 2:06 AM James K. Lowden
wrote:
>
> On Wed, 8 May 2024 21:40:44 +0200
> Jakub Jelinek 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.
>
> 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
