Fix Loong64 GLIBCXX version errors by statically linking libstdc++

[Javonne-liu]

Description:

This PR addresses the GLIBCXX version compatibility issues reported in:
#187
#176 (comment)

The cross-compiled Node.js binaries for Loong64 were failing at runtime with errors like:

[root@6986da0ddce7 /]# ./node-v24.7.0-linux-loong64/bin/node -v
./node-v24.7.0-linux-loong64/bin/node: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.31' not found (required by ./node-v24.7.0-linux-loong64/bin/node)
./node-v24.7.0-linux-loong64/bin/node: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by ./node-v24.7.0-linux-loong64/bin/node)
[root@6986da0ddce7 /]# strings /lib64/libstdc++.so.6 | grep GLIBCXX_
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBCXX_3.4.22
GLIBCXX_3.4.23
GLIBCXX_3.4.24
GLIBCXX_3.4.25
GLIBCXX_3.4.26
GLIBCXX_3.4.27
GLIBCXX_3.4.28
GLIBCXX_3.4.29
GLIBCXX_3.4.30
GLIBCXX_DEBUG_MESSAGE_LENGTH

Solution:

Added export LDFLAGS="-static-libstdc++" to recipes/loong64/run.sh to statically link the libstdc++ library during compilation.
This fixes the runtime error where the cross-compiled Node.js binary for Loong64 fails to find required GLIBCXX versions.

[rvagg]

Yeah, I don't know about this, it's one of the reasons I try and discourage the use of the most recent distros to build on, so we don't get tangled in too-modern libc and libstdc++. This

unofficial-builds/recipes/loong64/Dockerfile

Line 1 in f973431

FROM ubuntu:24.04

- and this -

unofficial-builds/recipes/loong64/Dockerfile

Line 9 in f973431

&& add-apt-repository -y ppa:ubuntu-toolchain-r/test \

and basically locking this recipe into being only consumable by systems that are even more up to date, or that have ubuntu-toolchain-r/test installed on them as well.
I'd prefer someone put in some effort to try and downgrade the container and not have to rely on ubuntu-toolchain-r. I don't know if some form of centos is available for loong64 but that would be ideal because the devtoolsets are much better at maintaining maximal compatibility than what you can do on Ubuntu where your best choice is to pick the denominator that supports the compiler you need.

[Javonne-liu]

@rvagg ,Thanks for your insights . However, for the LoongArch architecture, We’ve found ourselves needing to rely on relatively new toolchains and Ubuntu 24.04, mainly due to the following constraints.:

First, LoongArch is a relatively new instruction set, and its support requires newer versions of toolchains:

Binutils only started supporting LSX and LASX from version 2.41 (https://github.com/loongson/build-tools/wiki#binutils-related-support).
GCC only added support for LSX and LASX starting from version 14.1.0 (https://github.com/loongson/build-tools/wiki#gcc-related-support).
Second, lower-version GCC (e.g., GCC 12) cannot compile Node.js v24 properly on LoongArch. There have been relevant comments.: #176 (comment)

The static linking approach in this PR (adding LDFLAGS="-static-libstdc++") was specifically chosen to address the GLIBCXX version issues while working within these toolchain constraints.
Would you be open to this approach as a temporary solution?

[Xiao-Tao]

gcc-12 and later supports the LoongArch architecture. However, using gcc-12 may cause some issues when compiling node v24.x.

gcc-13 does not fully support LSX (Loongson SIMD Extension) and LASX (Loongson Advanced SIMD Extension), which can affect the performance of simdutf, simdjson, and other libraries.

gcc-14 fully supports LSX and LASX.
I believe using -static-libstdc++ to statically link libstdc++ for compatibility with older systems might be a good option.

[wojiushixiaobai]

https://github.com/nodejs/node/blob/b6cfba7cfb4f6e128290a28968c09bfc3b507566/configure.py#L175-L187

parser.add_argument("--fully-static",
    action="store_true",
    dest="fully_static",
    default=None,
    help="Generate an executable without external dynamic libraries. This "
         "will not work on macOS when using the default compilation environment")

parser.add_argument("--partly-static",
    action="store_true",
    dest="partly_static",
    default=None,
    help="Generate an executable with libgcc and libstdc++ libraries. This "
         "will not work on macOS when using the default compilation environment")

[rvagg]

OK, I have 3 of you in here, if you can all agree on the path forward here then I'll go with that. It looks like @wojiushixiaobai is suggesting to use a configure flag to achieve this instead.

[Xiao-Tao]

I think using --partly-static is a good approach as it maintains compatibility.

Using --fully-static would statically link glibc. I prefer dynamically linking glibc, which allows for timely use of CVE fixes in the system's glibc.

[Javonne-liu]

Thank you all for the feedback! I've updated my commit to only modify the configure file with the --partly-static parameter as suggested.

@rvagg @Xiao-Tao @wojiushixiaobai

[rvagg]

OK, docker rebuild was successful, I've queued up a 24.7.0 rebuild for you, watch for new files in https://unofficial-builds.nodejs.org/download/release/v24.7.0/, also watch for a new log directory for 24.7.0 at the bottom of https://unofficial-builds.nodejs.org/logs/ where you can see the build for it if there's any problems.