has_function: Don't check for builtins with includes #1150
Merged
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
This was referenced Dec 6, 2016
|
The failure should go away if you rebase this to master. |
|
I haven't tested this on Linux properly yet, so I want to do that first and maybe make changes to the test case accordingly. |
|
I've finished testing this on Linux and made some changes for that. Everything should be OK now. |
We were checking for builtins explicitly like this because the ordinary checks don't work for builtins at all. We do exactly the same check as Autoconf and it doesn't work with Autoconf either (Autoconf is broken!) So now we check for it in two ways: if there's no #include in prefix, we check if `__builtin_symbol` exists (has_function allows checking for functions without providing includes). If there's a #include, we check if `symbol` exists. The old method was causing problems with some buggy toolchains such as MSYS2 which define some builtins in the C library but don't expose them via headers which meant that `__builtin_symbol` would be found even though `symbol` is not available. Doing this allows people to always get the correct answer as long as they specify the includes that are required to find a function while also not forcing people to always specify includes to find a function which is cumbersome. Closes #1083
bonzini
pushed a commit
to qemu/qemu
that referenced
this pull request
Mar 8, 2022
Currently we incorrectly think that posix_memalign() exists on
Windows. This is because of a combination of:
* the msys2/mingw toolchain/libc claim to have a
__builtin_posix_memalign when there isn't a builtin of that name
* meson will assume that if you have a __builtin_foo that
counts for has_function('foo')
Specifying a specific include file via prefix: causes meson to not
treat builtins as sufficient and actually look for the function
itself; see this meson pull request which added that as the official
way to get the right answer:
mesonbuild/meson#1150
Currently this misdectection doesn't cause problems because we only
use CONFIG_POSIX_MEMALIGN in oslib-posix.c; however that will change
in a following commit.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20220226180723.1706285-6-peter.maydell@linaro.org
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
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.
We check for builtins explicitly like this because we want to support finding them without any includes in prefix, but this causes problems with some buggy toolchains such as MSYS2 which define the builtin in the C library but don't expose it via headers.
Doing this allows people to always get the correct answer as long as they specify the includes that are required to find a function while also not forcing people to always specify includes to find a function which is cumbersome.
Closes #1083