[Feature Request]: Consider removing unnecessary dependency on libstdc++

[twesterhout]

Summary of Feature

Description:

If I compile the hello6-taskpar-dist.chpl example, on Linux I'm getting a dependency on libstdc++:

$ chpl src/hello6-taskpar-dist.chpl
$ ldd ./hello6-taskpar-dist
	linux-vdso.so.1 (0x00007eff081a2000)
	libdl.so.2 => /nix/store/rcp9sdrrq8sfxkm5zdykglx7hd2gzbfy-glibc-2.40-66/lib/libdl.so.2 (0x00007eff07fd1000)
	libm.so.6 => /nix/store/rcp9sdrrq8sfxkm5zdykglx7hd2gzbfy-glibc-2.40-66/lib/libm.so.6 (0x00007eff07ee9000)
	libpthread.so.0 => /nix/store/rcp9sdrrq8sfxkm5zdykglx7hd2gzbfy-glibc-2.40-66/lib/libpthread.so.0 (0x00007eff07ee4000)
	libstdc++.so.6 => /nix/store/fly29nz0gwiww48y76myy0mimv12wz5w-gcc-14.3.0-lib/lib/libstdc++.so.6 (0x00007eff07c00000)
	libgcc_s.so.1 => /nix/store/fly29nz0gwiww48y76myy0mimv12wz5w-gcc-14.3.0-lib/lib/libgcc_s.so.1 (0x00007eff07eb4000)
	libc.so.6 => /nix/store/rcp9sdrrq8sfxkm5zdykglx7hd2gzbfy-glibc-2.40-66/lib/libc.so.6 (0x00007eff07800000)
	/nix/store/rcp9sdrrq8sfxkm5zdykglx7hd2gzbfy-glibc-2.40-66/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007eff081a4000)

This seems weird since we're not loading any C++ libraries and Chapel runtime shouldn't depend on the C++ standard library either... (right? 😄)

So let's run a test:

$ patchelf --print-needed ./hello6-taskpar-dist
libdl.so.2
libm.so.6
libpthread.so.0
libstdc++.so.6
libgcc_s.so.1
libc.so.6
ld-linux-x86-64.so.2
$ patchelf --remove-needed libstdc++.so.6 ./hello6-taskpar-dist
$ ldd ./hello6-taskpar-dist
	linux-vdso.so.1 (0x00007f26775f7000)
	libdl.so.2 => /nix/store/rcp9sdrrq8sfxkm5zdykglx7hd2gzbfy-glibc-2.40-66/lib/libdl.so.2 (0x00007f2677426000)
	libm.so.6 => /nix/store/rcp9sdrrq8sfxkm5zdykglx7hd2gzbfy-glibc-2.40-66/lib/libm.so.6 (0x00007f267733e000)
	libpthread.so.0 => /nix/store/rcp9sdrrq8sfxkm5zdykglx7hd2gzbfy-glibc-2.40-66/lib/libpthread.so.0 (0x00007f2677339000)
	libgcc_s.so.1 => /nix/store/fly29nz0gwiww48y76myy0mimv12wz5w-gcc-14.3.0-lib/lib/libgcc_s.so.1 (0x00007f267730b000)
	libc.so.6 => /nix/store/rcp9sdrrq8sfxkm5zdykglx7hd2gzbfy-glibc-2.40-66/lib/libc.so.6 (0x00007f2677000000)
	/nix/store/rcp9sdrrq8sfxkm5zdykglx7hd2gzbfy-glibc-2.40-66/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f26775f9000)
$ ./hello6-taskpar-dist
Hello, world! (from locale 0 of 1 named ...)

So it seems like we don't actually need libstdc++ at runtime! And to double check:

$ LD_DEBUG=symbols ./hello6-taskpar-dist 2>&1 | grep 'libstdc++'

Prints nothing. So yeah, not loading libstdc++.

Hence this issue. Could we make sure that there's no dependency on C++ when it's not needed? E.g., if I'm using re2 that's written in C++, then libstdc++ is needed.

The motivation is of course distributing Chapel binaries, i.e. using a Chapel program/library in an environment different from where it was compiled.

[jabraham17]

We end up linking against the C++ stdlib because CHPL_TARGET_LD is the C++ linker. There isn't a way to change that without hacking the build system, but it is possible to use a C linker in limited cases. You can adjust get_target_link_command in util/chplenv/compile_link_args_utils.py to use a C compiler for the linker (and I did confirm this results in an executable without C++ stdlib linked in), but its not going to work in all cases

In general, we need a C++ linker for a few reasons

• the runtime does use C++, for RE2 support and for GPU support
  • I tested this, if I use a C linker and try to compile a program using regex, I get lots of errors about missing C++ symbols
• to support interop with user code written with C++
  • e.g., a user can compile a C++ file to an object file (with the appropriate extern statements) and then call it from Chapel. But without a C++ CHPL_TARGET_LD, there will be linker errors