Resolve dbg linker problems due to asserts

[openroad-ci]

Summary

libstdc++ and libc++ differ and abc uses asserts. It is compiled with libstdc++ headers and then linked with libc++ without this change.

Type of Change

• Bug fix

Verification

• I have verified that the local build succeeds (./etc/Build.sh).
• I have run the relevant tests and they pass.
• My code follows the repository's formatting guidelines.
• I have signed my commits (DCO).

[gemini-code-assist]

Code Review

This pull request modifies the .bazelrc file to force the use of libc++ for the abc external dependency, addressing linker errors encountered during debug builds. The reviewer suggests that configuring the standard library globally within the toolchain definition would be a more robust solution to prevent potential ODR violations and also identified a minor typo in the documentation comments.

[gemini-code-assist]

Forcing libc++ for a specific external dependency via per_file_copt is a workaround for a broader inconsistency. If the project is intended to use libc++ globally (as suggested by the linker errors and the -libcxx_assertions feature in BUILD.bazel), it is more robust to configure this in the toolchain definition within MODULE.bazel using the stdlib = "libc++" attribute on the llvm.toolchain extension. This ensures consistency across all dependencies and avoids potential ODR violations that can occur when mixing standard library implementations. Additionally, there is a small typo in the comment ("avoid" should be "avoids").

# This avoids problems with building -c dbg which enables asserts.
# Without this libstdc++ vs libc++ differences cause link errors.
build --per_file_copt=.*external/abc.*@-stdlib=libc++
build --host_per_file_copt=.*external/abc.*@-stdlib=libc++

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[maliberty]

@hzeller @QuantamHD merging to unblock but also interested in your opinions on the right way to handle this. The summary of a tedious debug session

 ABC's .c files are compiled as C++ via -x c++ in copts, but Bazel treats them 
  as C compilation actions, so the toolchain's cxx_flags (including             
  -stdlib=libc++) are NOT applied. Without -stdlib=libc++, clang uses the       
  system's libstdc++ headers.                                                   
                                                                                
  On gLinux, the system libstdc++ headers likely have hardened                  
  containers/assertions enabled by default (common in Google's internal
  toolchain). These headers reference __glibcxx_assert_fail. But at link time,  
  the binary links against the hermetic libc++ (not libstdc++), so the symbol is
   unresolved.

  The mismatch is:
  - Compile time: ABC uses system libstdc++ headers (no -stdlib=libc++)
  - Link time: binary links libc++.a (from hermetic LLVM), no libstdc++         
                                                                       
  The fix is to add -stdlib=libc++ to ABC's COPTS so it uses the same libc++    
  headers as everything else. Since ABC is an external dependency, let me check 
  how it's pulled in.                                                           
                                                                                
  Searched for 2 patterns, read 1 file (ctrl+o to expand)     
                                                                         
● ABC is a BCR module dependency. The quickest fix is to force -stdlib=libc++
  for ABC's compilations via .bazelrc. Since ABC's .c files use -x c++ but miss
  the toolchain's -stdlib=libc++, we need to inject it.                       
                 
  Add this to .bazelrc:                                                         
                                                                                
  build --per_file_copt=.*external/abc.*@-stdlib=libc++                         
  build --host_per_file_copt=.*external/abc.*@-stdlib=libc++                    
                                                                                
  This fixes the root cause: ABC's C-files-compiled-as-C++ will use the hermetic
   libc++ headers instead of the system's libstdc++ headers, eliminating the
  __glibcxx_assert_fail reference entirely.                                     
                             
  The .bazelrc already has a similar pattern for suppressing warnings on        
  external code (line 65-66), so this is consistent.

[maliberty]

Based on gemini's suggestion claude came back with

build --copt=-stdlib=libc++    --host_copt=-stdlib=libc++

I haven't tried it yet.

[hzeller]

Since we use --cxxopt (instead of --copt), I'd hope that -xc++ is not applied to *.c files. So interesting.

Not sure how related, but there are a few files in abc that are c++ though and there is a C-file that needed to be renamed to c++ for the atomic include; @QuantamHD fixed that and I have applied it to the latest yosys in BCR bazelbuild/bazel-central-registry#8356 - So independent of if this is related, updating the bazel dep to 0.64-yosyshq is probably a good idea.

I wonder why the c++ library linking is not working as expected. This PR fixes a problem, but for me to understand, how can the problem that shows up without the change be reproduced ?