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

ocamlc -linkall -c test.ml should activate force-linking in test.cmo #6409

Closed
vicuna opened this issue May 10, 2014 · 2 comments
Closed

ocamlc -linkall -c test.ml should activate force-linking in test.cmo #6409

vicuna opened this issue May 10, 2014 · 2 comments

Comments

@vicuna
Copy link

vicuna commented May 10, 2014

Original bug ID: 6409
Reporter: @gasche
Status: resolved (set by @damiendoligez on 2017-03-01T14:27:43Z)
Resolution: fixed
Priority: low
Severity: feature
Category: compiler driver

Bug description

When producing an archive (cma, cmxa), adding -linkall marks compilation unit of the archive as force-linked. It would be consistent and helpful if -linkall did also work when producing .cmo/.cmx. As far as I can tell, it is currently ignored.

$ mkdir test
$ echo "let x = 1" > test.ml
$ ocamlc -linkall -c test.ml
$ ocamlobjinfo test.cmo | grep link
Force link: no

While .cmo/.cmx are always linked anyway when passed to a linking step, the interest of marking a .cmo with force-linking is that it would remain force-linked in any archive including it.

I stepped on this non-behavior of -linkall when playing with force-linking side-effecting modules of the compiler (eg. typing/typeclass.cmo) during the discussion of #53. In any situation where typeclass.cmo and typecore.cmo are available and typecore.cmo is used, it is unsafe not to link typeclass.cmo as well; it would make sense to simply compile typeclass.cmo with -linkall.

@vicuna
Copy link
Author

vicuna commented May 17, 2014

Comment author: @garrigue

I'm not sure your example is a good one.
What you are saying is that whenever typecore.cmo is linked, typeclass.cmo should be linked too.
I.e., that there is a two-way dependency between these modules.
But the proposed solution would include typeclass.cmo always, even when typecore.cmo is not included.

Isn't it rather a good reason to keep -pack around: interdependent files should be packed inside the same object. If needed, one can avoid the induced nesting using module aliases.

@vicuna
Copy link
Author

vicuna commented Mar 1, 2017

Comment author: @damiendoligez

Implemented by #1009 ( #1009 )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant