Support building with GCC v8.x/v9.x #265
Conversation
The return type of the `GetProcAddress()` function is `FARPROC` which evaluates to `long long int (*)()`, i.e. it cannot be cast to the correct function signature by GCC 8. To work around that, we first cast to `void *` and go on with our merry lives. Signed-off-by: Johannes Schindelin <[email protected]>
The kwset functionality makes use of the obstack code, which expects to be handed a function that can allocate large chunks of data. It expects that function to accept a `size` parameter of type `long`. This upsets GCC 8 on Windows, because `long` does not have the same bit size as `size_t` there. Now, the proper thing to do would be to switch to `size_t`. But this would make us deviate from the "upstream" code even further, making it hard to synchronize with newer versions, and also it would be quite involved because that `long` type is so invasive in that code. Let's punt, and instead provide a super small wrapper around `xmalloc()`. Signed-off-by: Johannes Schindelin <[email protected]>
We introduced helper macros to simplify loading functions dynamically. Might just as well use them. This also side-steps a compiler warning when building with GCC v8.x: it would complain about casting between incompatible function pointers. Signed-off-by: Johannes Schindelin <[email protected]>
The `labs()` function operates, as the initial `l` suggests, on `long` parameters. However, in `config.c` we tried to use it on values of type `intmax_t`. This problem was found by GCC v9.x. To fix it, let's just "unroll" the function (i.e. negate the value if it is negative). Signed-off-by: Johannes Schindelin <[email protected]>
|
/submit |
|
Submitted as [email protected] |
![gitgitgadget[bot]](https://avatars.githubusercontent.com/in/12836?s=60&v=4){kind=small}
|
This branch is now known as |
|
This patch series was integrated into pu via git@3a9119b. |
|
This patch series was integrated into pu via git@c444961. |
|
This patch series was integrated into pu via git@ecf0ecc. |
|
This patch series was integrated into pu via git@19d6d32. |
|
This patch series was integrated into pu via git@32983d7. |
|
This patch series was integrated into pu via git@2d469a6. |
|
This patch series was integrated into pu via git@ecc6479. |
|
This patch series was integrated into pu via git@21460a6. |
|
This patch series was integrated into pu via git@431cb85. |
|
This patch series was integrated into pu via git@8307f7b. |
|
This patch series was integrated into pu via git@00d3192. |
|
This patch series was integrated into pu via git@eb1fa43. |
|
This patch series was integrated into next via git@92bb0db. |
|
This patch series was integrated into pu via git@d8281fa. |
|
This patch series was integrated into pu via git@4017071. |
|
This patch series was integrated into pu via git@7734bfb. |
|
This patch series was integrated into pu via git@184a1fd. |
|
This patch series was integrated into pu via git@cfa9706. |
|
This patch series was integrated into pu via git@be21fa8. |
|
This patch series was integrated into pu via git@7785f9b. |
|
This patch series was integrated into next via git@7785f9b. |
|
This patch series was integrated into master via git@7785f9b. |
|
Closed via 7785f9b. |
The issues with GCC have been resolved: - The bug in GCC v8.x was fixed that prevented `-fstack-protector-strong` to produce valid code: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86832 - The issues were resolved in Git for Windows' source code that triggered build warnings with GCC v8.x (warnings that cause build failures with `DEVELOPER=1`): git-for-windows/git#2149 - The issue preventing Git for Windows to be compiled with GCC v9.x under `DEVELOPER=1` was resolved: git-for-windows/git#2258 - The issues preventing Git's `master` to be compiled with GCC v9.x (rolling up the fixes for GCC v8.x) were resolved: gitgitgadget/git#265 The issue with osslsigncode no longer signing the code after the upgrade to OpenSSL v1.1.1, but pretending to succeed, has been fixed some time recently through a rebuild of mingw-w64-osslsigncode. Signed-off-by: Johannes Schindelin <[email protected]>
The issues with GCC have been resolved: - The bug in GCC v8.x was fixed that prevented `-fstack-protector-strong` to produce valid code: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86832 - The issues were resolved in Git for Windows' source code that triggered build warnings with GCC v8.x (warnings that cause build failures with `DEVELOPER=1`): git-for-windows/git#2149 - The issue preventing Git for Windows to be compiled with GCC v9.x under `DEVELOPER=1` was resolved: git-for-windows/git#2258 - The issues preventing Git's `master` to be compiled with GCC v9.x (rolling up the fixes for GCC v8.x) were resolved: gitgitgadget/git#265 Signed-off-by: Johannes Schindelin <[email protected]>
I noticed a while ago that I could not build Git's
masterin Git for Windows' SDK when using GCC v8.x. This became a much less pressing problem when I discovered a serious bug that would not let us compile with ASLR/DEP enabled (the resulting executables would just throw segmentation faults left and right), so I put these patches on the backburner for a while.But now GCC v8.x is fixed, and MSYS2 even switched to GCC v9.x (which found yet another problem that I fix in patch 4/4 of this patch series). So it is time to get Git's
masterready.