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
Fix CC logic in configure #607
Conversation
In e9a52aa, the logic was changed to try check harder for GCC, but it dropped the default setting of cc=${CC}. It was throwing away any pre-set CC value as a result. The rest of the script then cascades down a bad path because it's convinced it's not GCC or a GCC-like compiler. This led to e.g. misdetection of inability to build shared libs for say, multilib cases (w/ CC being one thing from the environment being used for one test (e.g. x86_64-unknown-linux-gnu-gcc -m32 and then 'cc' used for shared libs (but missing "-m32"!)). Obviously just one example of how the old logic could break. This restores the old default of 'CC' if nothing overrides it later in configure. Bug: https://bugs.gentoo.org/836308 Signed-off-by: Sam James <sam@gentoo.org>
I can confirm that this PR solve #608 |
Include fixes from upstream PRs: madler/zlib#607 madler/zlib#599
This also fixes the compilation of dynamic library in macOS. |
Include fixes from upstream PRs: madler/zlib#607 madler/zlib#599
Include fixes from upstream PRs: madler/zlib#607 madler/zlib#599
Include fixes from upstream PRs: madler/zlib#607 madler/zlib#599
Include fixes from upstream PRs: madler/zlib#607 madler/zlib#599
See 05796d3 . |
Thanks. |
@madler: It is not possible to merge PRs than close? |
Not sure how. |
I use pram usually (e.g.
(github has its own merge buttons but I don't usually use those as the repo isn't always hosted on github directly, just a mirror.) |
github normally have a green "merge" button, if you don't care about the merge commits. Otherwise a shortcut of @thesamesam's suggestion: |
A convenient way also provided by https://github.com/leahneukirchen/git-merge-pr :) |
Apply patch that already has been applied upstream: - madler/zlib#607 - madler/zlib@05796d3
Apply patch that already has been applied upstream: - madler/zlib#607 - madler/zlib@05796d3
Apply patch that already has been applied upstream: - madler/zlib#607 - madler/zlib@05796d3 (cherry picked from commit f091c0e)
Apply patch that already has been applied upstream: - madler/zlib#607 - madler/zlib@05796d3 (cherry picked from commit f091c0e)
Apply patch that already has been applied upstream: - madler/zlib#607 - madler/zlib@05796d3 (cherry picked from commit f091c0e)
Apply patch that already has been applied upstream: - madler/zlib#607 - madler/zlib@05796d3 (cherry picked from commit f091c0e)
Apply patch that already has been applied upstream: - madler/zlib#607 - madler/zlib@05796d3 (cherry picked from commit f091c0e)
Apply patch that already has been applied upstream: - madler/zlib#607 - madler/zlib@05796d3 (cherry picked from commit f091c0e)
Apply patch that already has been applied upstream: - madler/zlib#607 - madler/zlib@05796d3 (cherry picked from commit f091c0e)
Apply patch that already has been applied upstream: - madler/zlib#607 - madler/zlib@05796d3 (cherry picked from commit f091c0e)
In e9a52aa,
the logic was changed to try check harder for GCC, but it dropped
the default setting of cc=${CC}. It was throwing away any pre-set CC value as
a result.
The rest of the script then cascades down a bad path because it's convinced
it's not GCC or a GCC-like compiler.
This led to e.g. misdetection of inability to build shared libs
for say, multilib cases (w/ CC being one thing from the environment being used
for one test (e.g. x86_64-unknown-linux-gnu-gcc -m32 and then 'cc' used for
shared libs (but missing "-m32"!)). Obviously just one example of how
the old logic could break.
This restores the old default of 'CC' if nothing overrides it later
in configure.
Bug: https://bugs.gentoo.org/836308
Signed-off-by: Sam James sam@gentoo.org