bjorn3 opened Issue #1325:
Feature
Currently it is only possible to create symbols that are either local to an object file, or exported from the final linking artifact. It is not possible to create symbols that are exported from an object file, but are not exported from the final linking artifact.
Benefit
This makes it possible to export less symbols from dylibs. This may be required to prevent conflicting definitions of a symbol. It also makes the linker faster when linking against a dylib compiled by Cranelift.
Implementation
Add a new
Hiddenvariant toLinkage.Alternatives
In the long term we may want to refactor
Linkageinto the separate concepts it has: if a symbol is weak, the scope of the symbol, if symbol interposition is allowed, ... Adding aHiddenvariant toLinkageis easier for now though.
pchickey commented on Issue #1325:
The requirement totally makes sense to me. I'm good with adding just a new
Hiddenvariant toLinkagenow, if you don't mind it changing a bit when its time to do the bigger refactoring you suggest. It should be very straightforward to add support forLinkage::Hiddento all of the existing backends in-tree.
pchickey closed Issue #1325:
Feature
Currently it is only possible to create symbols that are either local to an object file, or exported from the final linking artifact. It is not possible to create symbols that are exported from an object file, but are not exported from the final linking artifact.
Benefit
This makes it possible to export less symbols from dylibs. This may be required to prevent conflicting definitions of a symbol. It also makes the linker faster when linking against a dylib compiled by Cranelift.
Implementation
Add a new
Hiddenvariant toLinkage.Alternatives
In the long term we may want to refactor
Linkageinto the separate concepts it has: if a symbol is weak, the scope of the symbol, if symbol interposition is allowed, ... Adding aHiddenvariant toLinkageis easier for now though.
Last updated: Dec 06 2025 at 06:05 UTC