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

[Linux] Enable build-ids. #4995

Merged
merged 1 commit into from
Jun 27, 2024

Conversation

al45tair
Copy link
Contributor

We should use build IDs on Linux so that we can identify the built artefacts, and also so that we can match them up with debug information should we choose to separate it.

rdar://130582768

We should use build IDs on Linux so that we can identify the built
artefacts, and also so that we can match them up with debug
information should we choose to separate it.

rdar://130582768
Copy link
Contributor

@jmschonfeld jmschonfeld left a comment

Choose a reason for hiding this comment

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

Overall the change looks good to me!

Since we don't have CI setup on this branch yet, I used my other WIP PRs to kick off this linux test which includes this PR: https://ci.swift.org/job/swift-PR-Linux/16070/. Let's wait for that to pass before merging (Linux is in the state where swift-ci testing should pass).

Do we also need to do the same for all of the dependencies (swift-foundation, swift-foundation-icu, and swift-collections)?

@al45tair
Copy link
Contributor Author

al45tair commented Jun 27, 2024

Do we also need to do the same for all of the dependencies (swift-foundation, swift-foundation-icu, and swift-collections)?

👍 Yes, ideally, anything that is installed as a .so or that produces an executable on Linux would have --build-id=sha1 as a linker option, so that we get build IDs on everything (like we have on Apple platforms by default). It isn't necessary for static libraries.

@jmschonfeld
Copy link
Contributor

I'm seeing some build failures that appear to be new with this change:

(.data.rel.ro+0x330): error: undefined reference to '$s22_FoundationCollections4RopeV8_StorageCMn'
/home/build-user/build/buildbot_linux/none-swift_package_sandbox_linux-x86_64/usr/lib/swift_static/linux/libFoundationEssentials.a(AttributedString+_InternalRuns.swift.o)(.data.rel.ro+0x338): error: undefined reference to '$s22_FoundationCollections4RopeV5_NodeVMn'

This symbol should be exported from lib_FoundationCollections.a which is auto linked from libFoundationEssentials.a:

target_compile_options(FoundationEssentials PRIVATE
        "SHELL:$<$<COMPILE_LANGUAGE:Swift>:-Xfrontend -public-autolink-library -Xfrontend _FoundationCollections>")

Is it possible that this change introduced that issue?

@jmschonfeld
Copy link
Contributor

Oh I apologize, that was due to an issue on my end. New test run kicked off at https://ci.swift.org/job/swift-PR-Linux/16085/

@jmschonfeld
Copy link
Contributor

Ok the new linux test passed so this looks good to me, thanks!

@jmschonfeld jmschonfeld merged commit f186ff8 into swiftlang:package Jun 27, 2024
compnerd added a commit to compnerd/swift-corelibs-foundation that referenced this pull request Dec 17, 2024
This reverts commit f186ff8. This is
incorrectly being applied to Windows builds as well.
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