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

Attempt two at solving Windows symbol linking issues #8117

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

dschaefer2
Copy link
Member

Instead of creating two modules, one that exports symbols and one that doesn't and letting consuming products pick which one they want, we now mark all targets on Windows as static and then reset that if a target is in a DLL product. This gets by the missing feature of marking a target as a DLL (only products can be DLLs).

We also turn off the exporting imported symbol warning that is generated when a module in a DLL is also used in a static context confusing the linker.

Reverts the prevous attempt at fixing symbol export errors in EXEs.

Instead, for Windows triples, we mark all targets as needing to be
static. Then, after the products are planned, walks throught the
staticTargets of DLL products and marks as not static.

This allows executables in packages to import modules in local
DLL products as exporting. This is a temporary fix until we add
the ability for targets to explicity depend on local products.
Doing recursive deps brought back the exported a symbol you
imported warnings.
This will happen when a module that exports a symbol for a DLL
is also linked into an EXE with modules that import it.
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.

2 participants