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

Fix new dynlink's initialisation checks #2176

Merged
merged 5 commits into from Dec 8, 2018

Conversation

@lpw25
Copy link
Contributor

commented Nov 30, 2018

#1063 rewrote the various checks when loading shared libraries with dynlink in order to make them sound. However, the checks to ensure that a module is not used before it has been initialised were far too restrictive. For example, a module in a shared library could not refer to another library within the same shared library. This PR fixes that by updating the list of initialised units earlier. This PR also relaxes the "allowed units" check so that it only applies to implementation dependencies not interface dependencies -- which matches the previous behaviour and is necessary to deal with mli-only modules.

I also added a bunch of tests that exercise the various cases.

This PR should hopefully fix MPR#7876 -- although I haven't actually tried it.

This PR is on top of #2175 because that bug was causing problems with the use of packing added by #1063.

@ejgallego

This comment has been minimized.

Copy link

commented Nov 30, 2018

I confirm this fixes Coq plugins in both build modes [using -pack and using aliases].

@gasche

This comment has been minimized.

Copy link
Member

commented Dec 1, 2018

cc @alainfrisch @chambart @mshinwell : we don't want to wait for too long between the merge of #1063 in trunk and a fix such as included in the present PR, so I think the urgency of this review is a bit higher than the usual.

@mshinwell

This comment has been minimized.

Copy link
Contributor

commented Dec 3, 2018

Ack, I will read this soon.

@gasche

This comment has been minimized.

Copy link
Member

commented Dec 3, 2018

( @lpw25, you could rebase now that #2175 is merged. )

@lpw25 lpw25 force-pushed the lpw25:fix-new-dynlink branch from 482d930 to 7d57ebc Dec 3, 2018

@lpw25

This comment has been minimized.

Copy link
Contributor Author

commented Dec 3, 2018

Rebased

executed completely cannot be depended upon by another shared library being
loaded. *)
(* Check that a shared library can refer to a module in the main program
if its already loaded. *)

This comment has been minimized.

Copy link
@mshinwell

mshinwell Dec 3, 2018

Contributor

Please clarify what "its" refers to. (And, "its" -> "it's".)

*)

(* Check that a module in a shared library can refer to another module
in the shared library if it is already loaded. *)

This comment has been minimized.

Copy link
@mshinwell

mshinwell Dec 3, 2018

Contributor

Same comment as above regarding "it is".

*)

(* Check that a shared library that is loaded during the loading of
another shared libary can refer to modules of that library if they

This comment has been minimized.

Copy link
@mshinwell

mshinwell Dec 3, 2018

Contributor

Typo "libary". Also maybe name the libraries "A" and "B" so we can make "that library" precise.

@mshinwell

This comment has been minimized.

Copy link
Contributor

commented Dec 7, 2018

This is OK to merge after the Changes file has been updated.

@lpw25 lpw25 force-pushed the lpw25:fix-new-dynlink branch from f07e948 to 8c587da Dec 7, 2018

@lpw25 lpw25 merged commit 11d759c into ocaml:trunk Dec 8, 2018

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.