Port abseil to GNU/Hurd. #1829
Open
Port abseil to GNU/Hurd. #1829
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
abseil has failed to build on GNU/Hurd for a long time. Now
let's make it work! :)
Note that `__GNU__` is the macro for detecting GNU/Hurd. And
`__MACH__` is also defined there besides on Apple platform.
They are both "mach" but with different implementation and
platform details. Here are the works,
* Mark platform features (not) supported by GNU/Hurd.
* Supports `mmap` and `write`.
* Not supports `vdso`. It's specific to Linux.
* Not supports `ELF_SYMBOLIZE` for now. GNU/Hurd uses ELF as
the binary format. But symbolizing in abseil relies on
reading object file path from `/proc/self/task/<pid>/maps`
(Linux specific) or `/proc/self/maps`. GNU/Hurd does have
the latter. However, due to its micro-kernel design, it's
currently unable to get the file path info there.
* Disable stack consumption measurement. The problem behind
it is that GNU/Hurd uses a very different way to implement
signal handling. Due to compiler behavior, it is
impossible to get a stable, valid and reliable statictic
data. In my test environment, it's 96 bytes (< 100) for
current codes.
* GNU/Hurd uses different errno and messages than Linux. So
related things are adjusted accordingly.
* Fix a misuse of `__MACH__`, which should actually be
`__APPLE__`.
* Fix a missing including of `signal.h` for using `SIGABRT`.
Otherwise compilation will fail with undefined symbol error
on GNU/Hurd.
Signed-off-by: Yuqian Yang <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pr is to port abseil to GNU/Hurd. It might be a little hard for you to thoroughly review and test the patch on GNU/Hurd manually. But feel free to talk about any problems on it. I'm here willing to explain as much as I can. Here are some info that might be helpful.
I have succeeded to package it to
.debon GNU/Hurd Debian distribution. One step of the.debpackaging process is to run the unit tests, just like Debian on other platforms. And they passed.I have recently submitted a patch to
libgav1, which is the av1 decoder used in Chromium (maybe), and depends on abseil. I fixed its compiling failure on GNU/Hurd and built it with ported abseil. It works well and I can use it to decode real av1 videos.This patch was firstly posted to GNU/Hurd Debian mailing list for review, and some of the maintainers of GNU/Hurd have checked it. Some discussions also took place on irc channel. If you are interested, check here [1] [2] [3].
Following is the commit message. Most platform technical details are described on it.
abseil has failed to build on GNU/Hurd for a long time. Now let's make it work! :)
Note that
__GNU__is the macro for detecting GNU/Hurd. And__MACH__is also defined there besides on Apple platform. They are both "mach" but with different implementation and platform details. Here are the works,Mark platform features (not) supported by GNU/Hurd.
Supports
mmapandwrite.Not supports
vdso. It's specific to Linux.Not supports
ELF_SYMBOLIZEfor now. GNU/Hurd uses ELF as the binary format. But symbolizing in abseil relies on reading object file path from/proc/self/task/<pid>/maps(Linux specific) or/proc/self/maps. GNU/Hurd does have the latter. However, due to its micro-kernel design, it's currently unable to get the file path info there.Disable stack consumption measurement. The problem behind it is that GNU/Hurd uses a very different way to implement signal handling. Due to compiler behavior, it is impossible to get a stable, valid and reliable statictic data. In my test environment, it's 96 bytes (< 100) for current codes.
GNU/Hurd uses different errno and messages than Linux. So related things are adjusted accordingly.
Fix a misuse of
__MACH__, which should actually be__APPLE__.Fix a missing including of
signal.hfor usingSIGABRT. Otherwise compilation will fail with undefined symbol error on GNU/Hurd.