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

Control how the static library is linked #100

Open
wusticality opened this issue Jun 7, 2024 · 3 comments
Open

Control how the static library is linked #100

wusticality opened this issue Jun 7, 2024 · 3 comments

Comments

@wusticality
Copy link

In tracy-client-sys in build.rs, inside the build_tracy_client function, you build libtracy-client.a via the cc package. On Windows, we are being provided external dll's that link against the C runtime statically. Unfortunately, your code links against the C runtime dynamically, and on Windows, all libraries that your exectuable links against must link against the C runtime the same way (either statically or dynamically). Being able to control this would be very helpful. At present this is only a problem on Windows. Our hack looks something like this:

// KEVIN: This is a hack, libcef.dll and the sandbox statically link
// to the CRT, but tracy-client-sys doesn't. This causes a linker
// error when the CRT is loaded twice. Here we force static linking.
#[cfg(all(target_os = "windows"))]
{
    builder.flag("/MT");
}

You can see our branch here. Perhaps the best way to handle this is through a feature flag? Thanks in advance.

@nagisa
Copy link
Owner

nagisa commented Jun 7, 2024

Huh, I was under an impression that intermediate libraries shouldn't need to care how dependencies are linked at all. I would've expected them to get figured out during the final link of the executable.

Either way, I'm happy for you all to explore the solution space and propose a fix here. I'm not really familiar with the in-depth details of how the Microsoft's ecosystem is meant to work here, so my input is also prone to not be particularly insightful here.

@wusticality
Copy link
Author

Huh, I was under an impression that intermediate libraries shouldn't need to care how dependencies are linked at all. I would've expected them to get figured out during the final link of the executable.

Either way, I'm happy for you all to explore the solution space and propose a fix here. I'm not really familiar with the in-depth details of how the Microsoft's ecosystem is meant to work here, so my input is also prone to not be particularly insightful here.

Hey @nagisa, thanks for your reply. This only appears to be an issue on Windows. There, all libraries you link against (whether static or dynamic) must link against the C runtime the same way. Since this happens in build.rs, I suppose a quick and dirty hack would be to add like a "statically-linked" feature flag on Windows, but perhaps a better way would be via an environment variable that you parse and then iterate over to pass things along, maybe like:

TRACY_CLIENT_CC_FLAGS = "/MT" "some_other_flag"

Thoughts?

@nagisa
Copy link
Owner

nagisa commented Jun 7, 2024

We already have an ability to pass in the C(++) flags via an environment variable: TRACY_CLIENT_SYS_CXXFLAGS

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

No branches or pull requests

2 participants