Remove -static-libgcc link flag from mingw32 port#1535
Merged
xavierleroy merged 2 commits intoocaml:trunkfrom Dec 19, 2017
Merged
Remove -static-libgcc link flag from mingw32 port#1535xavierleroy merged 2 commits intoocaml:trunkfrom
xavierleroy merged 2 commits intoocaml:trunkfrom
Conversation
The instructions for the mingw64 port added in 600a93d amended the sentence about -static-libgcc to include config/Makefile.mingw64. The 64-bit mingw port has never required or included this flag.
Including -static-libgcc in all link instructions prevents C++ exceptions from ever working. mmap.o is the only affected unit, since it needs auxiliary functions to perform division of an __int64. A better fix is to specify --static-libgcc only when building dllbigarray.dll and dllunix.dll (since they both export versions of this primitive).
6038803 to
1a21d1a
Compare
Member
|
(cc @alainfrisch, @msprotz) |
Contributor
|
This looks good to me so approving but not merging, just to make sure
somebody else has the opportunity to add something.
But @dra27, if nobody comments, IMO feel free to merge yourself.
|
shindere
approved these changes
Dec 19, 2017
Contributor
I guess it was not necessary: 64-bit integer division and modulus is implemented in hardware, no need for the software implementation from libgcc. |
Contributor
|
This looks good to me as well. Merging! |
fdopen
added a commit
to fdopen/ocaml-ctypes
that referenced
this pull request
Jun 24, 2018
workarounds for - ocaml/ocaml#1535 (no dll dependency) - ocaml/ocaml#1528 (string_of_float format) - ocaml/ocaml#1479 (chdir changes environment)
fdopen
added a commit
to fdopen/ocaml-ctypes
that referenced
this pull request
Dec 6, 2018
workarounds for - ocaml/ocaml#1535 (no dll dependency) - ocaml/ocaml#1528 (string_of_float format) - ocaml/ocaml#1479 (chdir changes environment)
This was referenced Nov 24, 2020
3 tasks
EmileTrotignon
pushed a commit
to EmileTrotignon/ocaml
that referenced
this pull request
Jan 12, 2024
Co-authored-by: Christine Rose <christinerose@users.noreply.github.com>
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
MPR#6411 added the
-static-libgccto all linking instructions for the mingw port in order to fix a problem with dllbigarray.dll. Contrary to README.win32, this has never been set in the 64-bit mingw port.The change was too broad and in particular prevents use of C++ exceptions.
The fix is to specify
-link -static-libgccdirectly inLDOPTSfor both otherlibs/bigarray and otherlibs/win32unix (since mmap.o is now compiled by both libraries). This causes dllbigarray.dll and dllunix.dll to obtain___divdi3and___moddi3statically and eliminates the dependency onlibgcc_s_sjlj-1.dll.libunix.a and libbigarray.a are unaffected by this flag. When linking C executables, GCC assumes static by default so these libraries will continue with libgcc.a, as they were before.
My understanding (and testing) is that C++ exceptions will still work even in the presence of dllbigarray.dll or dllunix.dll because the only thing they will have linked statically from libgcc is those two functions, so the exception handler stuff will still correctly in a C/C++ mixed environment.
At the time of the original PR, we didn't really have a working testsuite. Our present testsuite would have caught the original "bug" as soon as AppVeyor's Cygwin updated. I have a vague recollection of having to start symlinking
libgcc_s_sjlj-1.dllon my own systems back when GCC 4.x appeared but, as Jonathan notes in the MPR discussion, I didn't regard that as a bug so I never looked for the Mantis report at the time.Note that in conjunction with ocaml/flexdll#48, this appears to resolve all issues linking C++ with the two mingw ports (as far as I can tell, linking C++ objects in the MSVC port has always worked)