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

singly unlinkable cma orders silently allowed #6778

Closed
vicuna opened this issue Feb 11, 2015 · 10 comments · May be fixed by #10563
Closed

singly unlinkable cma orders silently allowed #6778

vicuna opened this issue Feb 11, 2015 · 10 comments · May be fixed by #10563

Comments

@vicuna
Copy link

vicuna commented Feb 11, 2015

Original bug ID: 6778
Reporter: dsheets
Status: acknowledged (set by @damiendoligez on 2015-02-18T22:58:36Z)
Resolution: open
Priority: normal
Severity: minor
Version: 4.02.1
Category: compiler driver
Duplicate of: #3488
Has duplicate: #7566
Monitored by: @whitequark @gasche elfring @alainfrisch

Bug description

.cma files retain the order used in their construction from a command-line. This order is then used during linking even when only a subset of units are used from the archive. Dependencies from early units to later units in a cma are permitted by the compiler. Unfortunately, these cma orders can never link because the later units are not in scope at the time the earlier units are read.

It should be a warning or error to attempt to produce an cma which is unlinkable with only a single provision to a compile command.

Steps to reproduce

  1. Run make
  2. Run make reverse-cma

File attachments

@elfring
Copy link

elfring commented Apr 15, 2019

I am still curious how affected software components will be improved also for this issue.

@github-actions
Copy link

github-actions bot commented Aug 3, 2020

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label Aug 3, 2020
@whitequark
Copy link
Member

Still an issue AFAIK.

@github-actions github-actions bot removed the Stale label Aug 5, 2020
@github-actions
Copy link

github-actions bot commented Aug 6, 2021

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label Aug 6, 2021
@damiendoligez
Copy link
Member

When we build a .cma, do we have easy access to the dependency relation between the .cmx that go into it?

@dbuenzli
Copy link
Contributor

For each object you are trying to put in the archive you know which interfaces it imports so you can certainly check that the user provided order makes sense when the archive is built.

@nojb
Copy link
Contributor

nojb commented Aug 12, 2021

I guess we could perform the same check that is done when linking an executable but at library-construction time, assuming all modules that go into the library are being "linked".

@lthls
Copy link
Contributor

lthls commented Aug 12, 2021

I've made a branch with a possible implementation of this check here.
It only checks the order for bytecode libraries (mirroring the behaviour of the link check, which only gives helpful errors in bytecode).
I can turn it into a PR if needed.

@nojb
Copy link
Contributor

nojb commented Aug 12, 2021

I can turn it into a PR if needed.

I think that would be a good idea. I have a couple of questions but I'll wait until there is a PR for review.

@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

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

Successfully merging a pull request may close this issue.

7 participants