That it's practically a one-liner is encouraging.

Please if you could, make sure to test that this doesn't break anything on Windows as a result. I chose Protected visibility instead of Hidden, since it seemed more permissive and still worked. If it breaks Windows, it should be okay to just stuff it behind an architecture-based condition.

With this patch applied, I get the following.

Windows:

Init from inside alpha.
Init from inside beta.
Init from the main program.
Another init from the main program.
32
16

Linux:

Init from inside beta.
Init from inside alpha.
Init from the main program.
Another init from the main program.
32
16

I don't know why, but on Linux it consistently prints beta before alpha, and on Windows it's consistently alpha, then beta. But it's progress.

Interesting. I just noticed the order is actually different too as you pointed out, so it's technically not mirroring Windows.

I would consider this a bug in its own right, as I can imagine people may need to rely on certain linking order behaviors in the future, especially if init procs are involved.

That may be down to the difference between msvc and clang's linkers, who knows. Would have to be looked into. Other than that the fix looks fine to me, but let's let Bill take a gander first.

Looks similar to a patch I did recently that was having the same symptoms with other procs and globals being used from other modules: 1053ec3

Weird that doesn't apply it to these procs too.

It looks like the startup/cleanup procs are never seen by either lb_find_ident or lb_find_value_from_entity, which are the two ways you get to lb_set_entity_from_other_modules_linkage_correctly.

It looks like they are getting skipped on lb_build_expr_internal due to them being constant values, so we don't get to case_ast_node(i, Ident, expr) which could lead to a call to lb_find_ident.

Is this possibly where another check for it should be?

I updated the patch to use the same visibility/linkage as lb_correct_entity_linkage.