Fix CC logic in configure#607
Fix CC logic in configure#607thesamesam wants to merge 1 commit intomadler:developfrom thesamesam:configure-cc
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 <[email protected]>
|
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)
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 [email protected]