Re: FE C++ requirement
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
Re: FE C++ requirement
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 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
Re: FE C++ requirement
On Tue, May 07, 2024 at 04:40:55PM -0400, James K. Lowden wrote: > /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.32' not > found (required by build-O2/gcc/cobol1 The cc1/cc1plus/f951/... binaries are normally linked with -static-libstdc++ -static-libgcc in second and later stages (first stage is linked against the host libstdc++, so not a problem, but even that stage is often linked with it). See e.g. --with-static-standard-libraries configure option in toplevel configury. Perhaps you don't link cobol1 with the correct make variables as other FEs are linked? I think it is $(LDFLAGS) that is needed: grep ^LDFLAGS *gcc/Makefile gcc/Makefile:LDFLAGS = -static-libstdc++ -static-libgcc prev-gcc/Makefile:LDFLAGS = -static-libstdc++ -static-libgcc stage1-gcc/Makefile:LDFLAGS = -static-libstdc++ -static-libgcc but better follow what other FEs do in Make-lang.in E.g. the linking of the FE binaries need to be specially chained for --enable-link-serialization or --enable-link-serialization=N such that only N binaries are linked together, etc. c++.serial = cc1plus$(exeext) ... cc1plus$(exeext): $(CXX_OBJS) cc1plus-checksum.o $(BACKEND) $(CODYLIB) $(LIBDEPS) $(c++.prev) @$(call LINK_PROGRESS,$(INDEX.c++),start) +$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \ $(CXX_OBJS) cc1plus-checksum.o $(BACKEND) $(CODYLIB) \ $(LIBS) $(BACKENDLIBS) @$(call LINK_PROGRESS,$(INDEX.c++),end) does that (the lang.serial line, $(lang.prev) dependency, the LINK_PROGRESS.lang calls, using $(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) ... $(BACKEND) $(BACKENDLIBS) $(LIBS) too. Jakub
FE C++ requirement
/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by build-O2/gcc/cobol1 The above error comes from ldd(1). I'm experimenting with what's minimally needed to install gcc when configured with --languages=cobol. Until this week, we always used --languages=c++,cobol. But, I said, why not just whatever C++ compiler and library happens to be on hand? Like the rest of gcc, our cobol1 compiler uses C++. The above message suggests to me that there's an assumption being made somewhere, that because the COBOL front end is being built, and uses C++, that the C++ library should be built and installed, too. 1. Is my understanding correct? 2. Is the dependency intentional, or can it be be defeated? >From my point of view, we need a reasonably modern libstdc++.so, but by no means do we need one that could be built in-tree. --jkl
