Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build: More miscellaneous fixes #1811

Merged
merged 6 commits into from
Feb 4, 2025

Conversation

jcm93
Copy link
Contributor

@jcm93 jcm93 commented Feb 4, 2025

Minor changes:

  • Run CI for pushes to any branch, not just master. This is mostly relevant for forks, where you will often want CI on WIP branches. Releases still check that they are on the master branch and won't be generated for other branches.

  • The GCC stringop-overflow heuristic still seems to be buggy, tripping in seemingly irrelevant areas, and in different areas depending on toolchain/OS. Hence, just disable it for now; conforms with legacy behavior.

  • Fix a macro redefinition in the GTK CMake code

  • Add a missing "included" source to the desktop-ui CMake code so it shows up in IDEs

  • gersemi formatting pass

Lastly:

Allow generating DWARF symbols in MSYS2/MinGW environments. This is controlled by the cache variable ARES_MINGW_USE_DWARF_SYMBOLS (on by default only for GCC, inoperable under MSVC/Clang-CL). This allows for easier use of gdb or lldb for debugging on Windows. The support here is considered incomplete but functional for debugging the main ares executable.

In particular, we do not generate DWARF symbols on Windows in ares-deps, so debugging dynamic dependency issues with gdb or lldb will require self-compiling dependencies. DWARF symbols are also embedded and this PR does not ship them with releases. The "primary" Windows clang build will continue to use CodeView symbols so that releases may be debugged with WinDbg, Visual Studio, etc.

I am not satisfied with this level of support, but I am also not sure whether "full support" for two independent debugging symbol formats on one platform is a reasonable thing or a good idea to maintain. For one thing, ares-deps targets the MSVC ABI for portability, where DWARF symbol availability is limited. Targeting the GNU ABI in ares-deps would mean reconciling multiple independent components' dependence on libc++ that would eventually need to be linked together. This might theoretically be possible but in any case is not undertaken here. Also not undertaken is the extant PDB functionality for stripping into separate files, bundling, copying to the rundir, etc.

@LukeUsher LukeUsher merged commit c899461 into ares-emulator:master Feb 4, 2025
17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants