order limits.h before stdlib.h to workaround for glibc _FORTIFY_SOURCE#1184
Conversation
`limits.h` must be included before `stdlib.h` when building with glibc and having `_FORTIFY_SOURCE` set to a non-zero value. When building with `_FORTIFY_SOURCE`, `realpath()` is inlined, and its definition depends on whether `limits.h` has been included or not (clearly, this is a terrible idea in terms of interacting with Clang modules and should probably be fixed upstream). If the definition differs from the one in SwiftGlibc, then _TestingInternals will not build. swiftlang/swift-testing#1184
grynspan
left a comment
There was a problem hiding this comment.
Can we put it in alphabetical position? Also, can you include a URL to whatever issue tracks the upstream fix?
|
@swift-ci test |
|
Obviously we could also conditionalise this based on platform but I presume it's generally safe to include |
Yes, will do. |
|
Is there a URL we can point to tracking the issue in glibc? |
I haven't filed a bug yet, will do (sorry, it's Sunday, negotiating bug fixing around family life!). |
|
Understood. This can certainly wait until Monday! |
It appears applying for a glibc bug tracker account is a manual process so, I'll have to wait until I hear back... |
|
Okay, fair enough. When you get the issue filed please comment here so we can refer back to it in the future. It's not a blocking issue, so we can merge this change without it. |
|
@swift-ci test |
|
Updated. glibc bug here: https://sourceware.org/bugzilla/show_bug.cgi?id=33120 |
|
@swift-ci test |
1 similar comment
|
@swift-ci test |
|
FYI upstream bug is a duplicate, first report was in 2023: |
|
That's okay, we just want a paper trail. Want to update the link? We can then merge the PR I think. |
`limits.h` must be included before `stdlib.h` when building with glibc and having `_FORTIFY_SOURCE` set to a non-zero value. When building with `_FORTIFY_SOURCE`, `realpath()` is inlined, and its definition depends on whether `limits.h` has been included or not (clearly, this is a terrible idea in terms of interacting with Clang modules and should probably be fixed upstream). If the definition differs from the one in SwiftGlibc, then _TestingInternals will not build. glibc bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30516
`limits.h` must be included before `stdlib.h` when building with glibc and having `_FORTIFY_SOURCE` set to a non-zero value. When building with `_FORTIFY_SOURCE`, `realpath()` is inlined, and its definition depends on whether `limits.h` has been included or not (clearly, this is a terrible idea in terms of interacting with Clang modules and should probably be fixed upstream). If the definition differs from the one in SwiftGlibc, then _TestingInternals will not build. swiftlang/swift-testing#1184
limits.hmust be included beforestdlib.hwhen building with glibc and having_FORTIFY_SOURCEset to a non-zero value.When building with
_FORTIFY_SOURCE,realpath()is inlined, and its definition depends on whetherlimits.hhas been included or not (clearly, this is a terrible idea in terms of interacting with Clang modules and should probably be fixed upstream). If the definition differs from the one in SwiftGlibc, then _TestingInternals will not build.