Skip to content

Conversation

@jkelleyrtp
Copy link
Member

Attempts to fix #4237 by white-listing just rust's incremental object files and instead lets the linker deal with "funny" rlibs. Note that for rlibs that contain "funny" artifacts and rust artifacts, we still submit the rust ones.

@jkelleyrtp jkelleyrtp requested a review from a team as a code owner June 3, 2025 13:22
@gmorenz
Copy link
Contributor

gmorenz commented Jun 3, 2025

This is clever! I'll try testing it locally.

Copy link
Contributor

@gmorenz gmorenz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This works great locally.

Are there cases where editing non-ffi rust breaks with this? The possibility that comes to mind is that if a generic function calls an FFI function, will the linker include the object file needed for that FFI function in v0 before there are any calls to it?

@jkelleyrtp jkelleyrtp merged commit 2ee54e5 into main Jun 3, 2025
19 checks passed
@jkelleyrtp jkelleyrtp deleted the jk/whitelist-rcgu branch June 3, 2025 14:40
@jkelleyrtp
Copy link
Member Author

Are there cases where editing non-ffi rust breaks with this? The possibility that comes to mind is that if a generic function calls an FFI function, will the linker include the object file needed for that FFI function in v0 before there are any calls to it?

Ended up testing it and seemed to work out fine, but the -L flag needs to be set before you add the extern block. Ie if you want to reference libc externs, they need to be available in your build.rs first.

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.

Subsecond fails to build project with rlib that contains unecessary .o files with unresolved symbols

3 participants