Why need SRS_STATIC_STD_CPP? Maybe we should only support SRS_STATIC which leads to -static-libstdc++ -static?

-static will generate a static linked executer,
-static-libstdc++ only link the static libstdc++ library.
So -static will cover -static-libstdc++ scope, I think it's no need to combine -static -static-libstdc++ together.

https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html

What is the output if use -static without -static-libstdc++? User only want a static binary without depends, majority of users can't understand the nuance of these two options.

On Linux:

-static output:

docker run -it --rm -v `pwd`:/srs -w /srs ossrs/srs:ubuntu20 bash -c "./configure --static=on && make"

/usr/bin/ld: ./objs/src/kernel/srs_kernel_error.o: in function `parse_symbol_offset(char*)':
/srs/./src/kernel/srs_kernel_error.cpp:73: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: ./objs/src/kernel/srs_kernel_utility.o: in function `srs_dns_resolve(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, int&)':
/srs/./src/kernel/srs_kernel_utility.cpp:161: warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: ./objs/openssl/lib/libcrypto.a(b_sock.o): in function `BIO_gethostbyname':
b_sock.c:(.text+0x78): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
make[1]: Leaving directory '/srs'

The warning said: dlopen, getaddrinfo and gethostbyname requires libc similar runtime shared library to support.

docker run -it --rm -v `pwd`:/srs -w /srs ossrs/srs:ubuntu20 bash -c "ldd ./objs/srs"

not a dynamic executable

with both -static -static-ibstdc++

same warning like -static.
ldd ./objs/srs
same output: not a dynamic executable.

git show 6314c27

on above commit, SRS_STATIC use -static-libstdc++ to replace -static.
But I think keep fully static linked exec can be an option, but not recommended.

Upon investigation, when we utilize certain functions such as dlopen and gethostbyname, we cannot achieve complete static linking, even though we use the -static flag; full static linking is not possible.

Only by removing the dependencies on these functions can we fully utilize the -static flag to create a version that truly does not depend on glibc.

Therefore, it is necessary to remove the dependencies on these functions. The dependency on dlopen comes from third-party libraries, which might be removed through compilation options. Functions like gethostbyname may require the use of different libraries or an implementation by the ST team itself.

https://stackoverflow.com/questions/15165306/compile-a-static-binary-which-code-there-a-function-gethostbyname

xmrig/xmrig#2902

https://www.reddit.com/r/haskell/comments/vqqq7x/comment/iez099a/

TRANS_BY_GPT4

To facilitate full static linking, we can only support the -static option, rather than also having a -static-libstdc++ option, which users might not understand how to use.

Essentially, when we support -static, a multitude of warnings are generated. These warnings actually indicate potential issues, hence our support for -static is not robust and leaves underlying problems unresolved.

We absolutely cannot offer an option that carries potential risks, as it would make any arising issues even more difficult to address.

TRANS_BY_GPT4