Skip to content
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

Remove -static-libgcc link flag from mingw32 port #1535

Merged
merged 2 commits into from Dec 19, 2017

Conversation

Projects
None yet
4 participants
@dra27
Copy link
Contributor

dra27 commented Dec 16, 2017

MPR#6411 added the -static-libgcc to 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-libgcc directly in LDOPTS for both otherlibs/bigarray and otherlibs/win32unix (since mmap.o is now compiled by both libraries). This causes dllbigarray.dll and dllunix.dll to obtain ___divdi3 and ___moddi3 statically and eliminates the dependency on libgcc_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.dll on 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 alainfrisch/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)

dra27 added some commits Dec 16, 2017

Correct -static-libgcc error in README.win32.adoc
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.
MPR#6411 revisited
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).

@dra27 dra27 force-pushed the dra27:mpr6411-revisited branch from 6038803 to 1a21d1a Dec 16, 2017

@dra27 dra27 added this to the 4.07 milestone Dec 16, 2017

@gasche

This comment has been minimized.

Copy link
Member

gasche commented Dec 16, 2017

@shindere

This comment has been minimized.

Copy link
Contributor

shindere commented Dec 19, 2017

@xavierleroy

This comment has been minimized.

Copy link
Contributor

xavierleroy commented Dec 19, 2017

Contrary to README.win32, this [-static-libgcc] has never been set in the 64-bit mingw port.

I guess it was not necessary: 64-bit integer division and modulus is implemented in hardware, no need for the software implementation from libgcc.

@xavierleroy

This comment has been minimized.

Copy link
Contributor

xavierleroy commented Dec 19, 2017

This looks good to me as well. Merging!

@xavierleroy xavierleroy merged commit 410ba0b into ocaml:trunk Dec 19, 2017

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

fdopen added a commit to fdopen/ocaml-ctypes that referenced this pull request Jun 24, 2018

windows: fix tests for OCaml 4.07
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

windows: fix issues introduced by OCaml 4.07
workarounds for
 - ocaml/ocaml#1535 (no dll dependency)
 - ocaml/ocaml#1528 (string_of_float format)
 - ocaml/ocaml#1479 (chdir changes environment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.