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

How to encode bare (system) link libs and flags for none C++ toolchains #75

Open
GregBowyer opened this issue Jun 30, 2020 · 0 comments
Labels
P4 Acknowledged issue. It's unlikely that the team will ever fix this issue. type: feature request Request for new, generally useful functionality that is missing

Comments

@GregBowyer
Copy link

As part of bazelbuild/rules_rust#361 a minor challenge is presented. Presently the Rust standard library links to a number of system libraries on various platforms.

These are to get access to the obvious aspects of the underlying system since unlike golang Rust does not use syscalls for OS access.

Right now the additional flags are encoded as a list of platform to the flags that should be added to the linker. Using Linux as an example this means that to link a binary using a Rust library that itself uses std requires -lpthread and -ldl.

The challenge starts with toolchains that do not understand these link flags. For example on windows you can have a GNU toolchain which only understands unix style flags and not MSVC ones. Making the (probably incorrect) windows link libraries like w2_32.lib incorrect for that configuration.

What I think might be better:

cc_common.create_linker_input(
    owner = ctx.label,
    libraries = depset([my_new_library]),
    system_link_libraries = depset(["pthread", "dl", "resolv"])
)

Where system_link_libraries is able to plug into the rest of the toolchain rules around flag groups and actions and given plain libraries know how to generate the correct flags for the linker.

I suspect that a variant of this is what causes these sort of issues bazelbuild/rules_rust#251

This is probably a little bit of a niche use case and does break hermetic properties of bazel somewhat, but would seem to be better than assuming the toolchain is the platform common toolchain and providing overrides via environment variables.

@comius comius added type: feature request Request for new, generally useful functionality that is missing P4 Acknowledged issue. It's unlikely that the team will ever fix this issue. labels Dec 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P4 Acknowledged issue. It's unlikely that the team will ever fix this issue. type: feature request Request for new, generally useful functionality that is missing
Projects
None yet
Development

No branches or pull requests

2 participants