Skip to content

Fix TCC symbol lookup failure on macOS in c_loader #640

Closed
ROKUMATE wants to merge 1 commit intometacall:developfrom
ROKUMATE:issue-442-fix
Closed

Fix TCC symbol lookup failure on macOS in c_loader #640
ROKUMATE wants to merge 1 commit intometacall:developfrom
ROKUMATE:issue-442-fix

Conversation

@ROKUMATE
Copy link
Contributor

@ROKUMATE ROKUMATE commented Feb 24, 2026

Summary

Fixes #442 — the C loader test (metacall_test) fails on macOS because TCC-compiled symbols cannot be discovered, with the error:

Symbol 'compiled_print' not found, skipping the function
Failed to discover C function declaration 'compiled_print'

Root Cause

On macOS, TCC may store symbols with a leading _ prefix per the platform ABI (e.g. compiled_print_compiled_print). Clang's AST parser always reports plain names. When the symbols map is populated with _-prefixed names, the plain-name lookup in c_loader_impl_discover_signature fails.

The existing #if __APPLE__ workaround in c_loader_impl_discover_signature tried to compensate by prepending _ at lookup time — this worked for the system TCC, but fails with the MetaCall forked TCC (which does NOT add the underscore prefix). Since CI uses the forked TCC (by design), the test failed.

Fix

Rather than patching the lookup side (which is TCC-variant-dependent), normalize symbol names at insertion time in c_loader_impl_discover_symbols:

  • On macOS: strip any leading _ from the symbol name before inserting into the map
  • If the forked TCC (no prefix) is in use: the if condition is false, no change in behaviour
  • If the system TCC (with prefix) is in use: the _ is stripped, map holds plain name

Then remove the now-redundant #if __APPLE__ prefix-prepend in c_loader_impl_discover_signature so lookups always use the plain Clang-reported name.

Files Changed

  • source/loaders/c_loader/source/c_loader_impl.cpp
    • c_loader_impl_discover_symbols() — strip leading _ on macOS at insertion time
    • c_loader_impl_discover_signature() — remove #if __APPLE__ block, use func_name directly

Testing

Build verified clean. The fix makes behaviour consistent across both TCC variants.

@ROKUMATE ROKUMATE changed the title Fix TCC symbol lookup failure on macOS in c_loader (#442) Fix TCC symbol lookup failure on macOS in c_loader Feb 24, 2026
@viferga
Copy link
Member

viferga commented Feb 25, 2026

Have you tested this? It is just wrong...

@ROKUMATE
Copy link
Contributor Author

Hey, thanks for the review. Could you point out specifically what's wrong?
mine understanding was:
the MetaCall forked TCC (what CI uses) doesn't add _ prefix on macOS, so discover_symbols stores compiled_print
the original #if __APPLE__ in discover_signature added _ before lookup → _compiled_print → not found in the map → symbol skipped
so the fix was: normalize at insertion time (strip _ if present on macOS) + remove the lookup-side #if __APPLE__. This makes it work for both TCC variants.

@ROKUMATE
Copy link
Contributor Author

Here's our reasoning and test: https://gist.github.com/ROKUMATE/8191109dbbbe5816a91ad771369ed399

The gist shows that without the _ stripping, system TCC (macOS ABI) stores _compiled_print but the lookup always uses the plain Clang-reported name compiled_print → not found → symbol skipped. That's the root cause

@viferga
Copy link
Member

viferga commented Mar 4, 2026

@ROKUMATE here is the full review of your PR: 6496e03

As there is no way to know at compile time if TCC is going to produce "_" or not, I checked their repo for seeing if there is any version where they introduced the flag to test against it but I found nothing.

Due to that I did a simple check at runtime for detecting if the symbols are underscored using the same method of the list. I wasn't neither sure if the tcc_get_symbol would be quivalent, that's why.

This should work in any case and always properly. Your case could introduce something like having a symbol with _ in the real name and getting deleted although tcc uses no symbol, preventing the C Loader to find it later on.

@viferga viferga closed this Mar 4, 2026
@ROKUMATE
Copy link
Contributor Author

ROKUMATE commented Mar 5, 2026

The runtime check is much safer. I'll study your commit to understand the pattern for future contributions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

macOS CI fails with C

2 participants