C++ cc_binary segfaults on macos-12

### Description of the problem / feature request:

The most basic cc hello world example produces a segfaulting binary on macos-12, when using rules_cc > 0.0.4.

### Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

WORKSPACE:
```WORKSPACE.bazel
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

http_archive(
name = "rules_cc",
sha256 = "2037875b9a4456dce4a79d112a8ae885bbc4aad968e6587dca6e64f3a0900cdf",
strip_prefix = "rules_cc-0.0.9",
urls = [
"https://github.com/bazelbuild/rules_cc/releases/download/0.0.9/rules_cc-0.0.9.tar.gz",
],
)

load("@rules_cc//cc:repositories.bzl", "rules_cc_dependencies", "rules_cc_toolchains")

rules_cc_dependencies()

rules_cc_toolchains()
```

BUILD:
```BUILD.bazel
load("@rules_cc//cc:defs.bzl", "cc_binary")

cc_binary(
name = "hello",
srcs = ["hello.cc"],
)
```
hello.cc:
```hello.cc
#include

int main()
{
std::cout << "Hello world!\n";
}
```

### What operating system are you running Bazel on?

macos-12 (on Github Actions)

### What's the output of `bazel info release`?

release 6.5.0

### What version of rules_cc do you use? Can you paste the workspace rule used to fetch rules_cc? What other relevant dependencies does your project have?

I am using rules_cc 0.0.9 (See WORKSPACE above), also tried 0.0.5 - 0.0.8 -- all of them fail in the same way. Version 0.0.1 works (that was the version we were using, but wanted to upgrade to the latest. 0.0.4 is the last version that works)

### What Bazel options do you use to trigger the issue? What C++ toolchain do you use?

No added options (just -s to see the commands).

The project is using the local_config_cc toolchain created by rules_cc.

### Have you found anything relevant by searching the web?

No.

### Any other information, logs, or outputs that you want to share?

Here is a CI run: https://github.com/avdv/testproject/actions/runs/9612425632/job/26513036166

The build succeeds on Ubuntu, but fails on macos with:
```
Loading: 0 packages loaded
Analyzing: target //:hello (1 packages loaded, 0 targets configured)
Analyzing: target //:hello (34 packages loaded, 127 targets configured)
Analyzing: target //:hello (34 packages loaded, 127 targets configured)
INFO: Analyzed target //:hello (38 packages loaded, 164 targets configured).
INFO: Found 1 target...
[0 / 5] [Scann] Compiling hello.cc
SUBCOMMAND: # //:hello [action 'Compiling hello.cc', configuration: 4d251272501a09258ab8679e379bc5cb22adc694d852a280468de7618e5b7017, execution platform: @local_config_platform//:host]
(cd /private/var/tmp/_bazel_runner/ea77c70f2ed17460d1dbacea4c3f82b2/execroot/__main__ && \
exec env - \
PATH=/Users/runner/Library/Caches/bazelisk/downloads/sha256/bbf9c2c03bac48e0514f46db0295027935535d91f6d8dcd960c53393559eab29/bin:/usr/local/lib/ruby/gems/3.0.0/bin:/usr/local/opt/ruby@3.0/bin:/usr/local/opt/pipx_bin:/Users/runner/.cargo/bin:/usr/local/opt/curl/bin:/usr/local/bin:/usr/local/sbin:/Users/runner/bin:/Users/runner/.yarn/bin:/Users/runner/Library/Android/sdk/tools:/Users/runner/Library/Android/sdk/platform-tools:/Library/Frameworks/Python.framework/Versions/Current/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/usr/bin:/bin:/usr/sbin:/sbin:/Users/runner/.dotnet/tools:/Users/runner/.ghcup/bin \
*** \
external/local_config_cc/cc_wrapper.sh -U_FORTIFY_SOURCE -fstack-protector -Wall -Wthread-safety -Wself-assign -Wunused-but-set-parameter -Wno-free-nonheap-object -fcolor-diagnostics -fno-omit-frame-pointer '-std=c++0x' -MD -MF bazel-out/darwin-fastbuild/bin/_objs/hello/hello.pic.d '-frandom-seed=bazel-out/darwin-fastbuild/bin/_objs/hello/hello.pic.o' -fPIC '-DBAZEL_CURRENT_REPOSITORY=""' -iquote . -iquote bazel-out/darwin-fastbuild/bin -iquote external/rules_cc -iquote bazel-out/darwin-fastbuild/bin/external/rules_cc -iquote external/bazel_tools -iquote bazel-out/darwin-fastbuild/bin/external/bazel_tools -no-canonical-prefixes -Wno-builtin-macro-redefined '-D__DATE__="redacted"' '-D__TIMESTAMP__="redacted"' '-D__TIME__="redacted"' -c hello.cc -o bazel-out/darwin-fastbuild/bin/_objs/hello/hello.pic.o)
# Configuration: 4d251272501a09258ab8679e379bc5cb22adc694d852a280468de7618e5b7017
# Execution platform: @local_config_platform//:host
[4 / 5] [Prepa] Linking hello
SUBCOMMAND: # //:hello [action 'Linking hello', configuration: 4d251272501a09258ab8679e379bc5cb22adc694d852a280468de7618e5b7017, execution platform: @local_config_platform//:host]
(cd /private/var/tmp/_bazel_runner/ea77c70f2ed17460d1dbacea4c3f82b2/execroot/__main__ && \
exec env - \
PATH=/Users/runner/Library/Caches/bazelisk/downloads/sha256/bbf9c2c03bac48e0514f46db0295027935535d91f6d8dcd960c53393559eab29/bin:/usr/local/lib/ruby/gems/3.0.0/bin:/usr/local/opt/ruby@3.0/bin:/usr/local/opt/pipx_bin:/Users/runner/.cargo/bin:/usr/local/opt/curl/bin:/usr/local/bin:/usr/local/sbin:/Users/runner/bin:/Users/runner/.yarn/bin:/Users/runner/Library/Android/sdk/tools:/Users/runner/Library/Android/sdk/platform-tools:/Library/Frameworks/Python.framework/Versions/Current/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/usr/bin:/bin:/usr/sbin:/sbin:/Users/runner/.dotnet/tools:/Users/runner/.ghcup/bin \
*** \
external/local_config_cc/cc_wrapper.sh -o bazel-out/darwin-fastbuild/bin/hello bazel-out/darwin-fastbuild/bin/_objs/hello/hello.pic.o -Wl,-S -undefined dynamic_lookup -headerpad_max_install_names)
# Configuration: 4d251272501a09258ab8679e379bc5cb22adc694d852a280468de7618e5b7017
# Execution platform: @local_config_platform//:host
Target //:hello up-to-date:
bazel-bin/hello
INFO: Elapsed time: 8.605s, Critical Path: 1.45s
INFO: 5 processes: 3 internal, 2 darwin-sandbox.
INFO: Build completed successfully, 5 total actions
/Users/runner/work/_temp/61ab77a2-d8cd-4d8b-96be-5586bfcc805f.sh: line 4: 4156 Segmentation fault: 11 bazel-bin/hello
```

Inside a tmate session I could see that the acutal command that it used to link was this:
```
/usr/bin/gcc -o bazel-out/darwin-fastbuild/bin/hello bazel-out/darwin-fastbuild/bin/_objs/hello/hello.pic.o -Wl,-S -undefined dynamic_lookup -headerpad_max_install_names
```

So, this does not specify any C++ libraries at all, resulting in dynamic resolution at runtime:
```
(lldb) target create "bazel-bin/hello"
Current executable set to '/Users/runner/work/rules_nixpkgs/rules_nixpkgs/examples/toolchains/cc/bazel-bin/hello' (x86_64).
(lldb) run
Process 7097 launched: '/Users/runner/work/rules_nixpkgs/rules_nixpkgs/examples/toolchains/cc/bazel-bin/hello' (x86_64)
Process 7097 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xffffffffffffffe8)
frame #0: 0x00007ff81ae39e80 libc++.1.dylib`std::__1::basic_ostream >::sentry::sentry(std::__1::basic_ostream >&) + 16
libc++.1.dylib`std::__1::basic_ostream >::sentry::sentry:
-> 0x7ff81ae39e80 <+16>: movq -0x18(%rax), %rax
0x7ff81ae39e84 <+20>: cmpl $0x0, 0x20(%rsi,%rax)
0x7ff81ae39e89 <+25>: jne 0x7ff81ae39ea3 ; <+51>
0x7ff81ae39e8b <+27>: movq %rdi, %rbx
Target 0: (hello) stopped.
```

The cc toolchain's config has `link_libs = ["-lstdc++", "-lm"]` but that is not passed to the linker command....

After adding `linkopts = ["-lstdc++"]` to the `cc_binary` rule, the binary works.

Start with the WORKSPACE.bazel and BUILD.bazel reproducer, then inspect the cc toolchain configuration where link_libs is set. Reproduce the macos-12 build and compare the generated link command with the configured libraries. Done means the minimal cc_binary links the required C++ libraries and runs without a segmentation fault.

Written by the indexing model from the issue text.