config, os: add support for Musl libc #771
Conversation
MaxDesiatov
force-pushed
the
maxd/musl-support
branch
from
7fcc48f to
9b9965b
Compare
|
@swift-ci test |
1 similar comment
|
@swift-ci test |
| @@ -25,14 +25,6 @@ | |||
| typedef int mode_t; | |||
| typedef void pthread_attr_t; | |||
|
|
|||
| #if defined(__cplusplus) | |||
There was a problem hiding this comment.
Should this instead just be added to os/generic_unix_base.h instead? This seems a platform specific thing instead of moving it to os/object.h - this declaration has nothing to do with os objects.
There was a problem hiding this comment.
This was previously only needed for Windows, now it's needed for Musl-based Linux too. I moved it to a new <os/generic_base.h> header, I hope that addresses your feedback.
MaxDesiatov
force-pushed
the
maxd/musl-support
branch
from
3f746fd to
819f24b
Compare
config/config.h
Outdated
| @@ -47,7 +47,9 @@ | |||
|
|
|||
| /* Define to 1 if you have the declaration of `program_invocation_short_name', | |||
| and to 0 if you don't. */ | |||
| #ifndef HAVE_DECL_PROGRAM_INVOCATION_SHORT_NAME | |||
There was a problem hiding this comment.
I don't see similar ifndef stuff for other knobs that could be configured - I'm not very familiar with this part of the dispatch build system but this feels like it might not be the place to add this.
cc: @compnerd to weigh in.
There was a problem hiding this comment.
You're right. In fact, when _GNU_SOURCE is defined (on a level above, in the Swift build system) related errors go away and I don't have to add an #ifndef here. That's cleaned up now.
MaxDesiatov
force-pushed
the
maxd/musl-support
branch
from
819f24b to
56e8ea6
Compare
According to Musl's FAQ, `__BEGIN_DECLS` and `__END_DECLS` macros come from Glibc private headers. Because of that, we need to define them manually in case those aren't defined.
MaxDesiatov
force-pushed
the
maxd/musl-support
branch
from
56e8ea6 to
ca40df0
Compare
|
@swift-ci test |
| @@ -3,9 +3,10 @@ | |||
| # voucher_private.h are included in the source tarball | |||
|
|
|||
| install(FILES | |||
| object.h | |||
| generic_base.h | |||
There was a problem hiding this comment.
Should the unix and windows base.h versions just import generic_base.h?
There was a problem hiding this comment.
Oh I see that they already do that. So we shouldn't need this additional install step then? Either way, doesn't hurt I guess.
There was a problem hiding this comment.
I assume this new header needs to be installed to be importable at the expected install location.
|
This regressed the Windows release. You introduced a new distributed header but did not update the Windows installer manifest. |
|
@compnerd Sorry about that, could you point to the installer manifest to be updated? Additionally, is there a Swift CI setup on this repository I could use in subsequent PRs to verify this? |
|
The manifests are now in apple/swift-installer-scripts. I think that setting up CI here is a great idea, @shahmishal should be able to help with that. However, that alone would be insufficient, you should also do a cross-repository test with a full toolchain build. The dispatch builds are tested as part of the regular PR tests on apple/swift and on a toolchain build. |
swiftlang/swift-corelibs-libdispatch#771 introduced a new header and broke the Windows toolchain due to the missing header. Update the SDK manifest accordingly which is required to get SPM to work again.
swiftlang/swift-corelibs-libdispatch#771 introduced a new header and broke the Windows toolchain due to the missing header. Update the SDK manifest accordingly which is required to get SPM to work again. Co-authored-by: Max Desiatov <[email protected]>
According to Musl's FAQ document,
__BEGIN_DECLSand__END_DECLSmacros come from Glibc private headers, thus we need to define them manually in case those aren't defined.