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

-pack and cmx dependancies #3488

Closed
vicuna opened this issue Feb 24, 2005 · 4 comments
Closed

-pack and cmx dependancies #3488

vicuna opened this issue Feb 24, 2005 · 4 comments

Comments

@vicuna
Copy link

vicuna commented Feb 24, 2005

Original bug ID: 3488
Reporter: administrator
Status: confirmed (set by @damiendoligez on 2013-07-02T14:01:39Z)
Resolution: open
Priority: normal
Severity: text
Category: compiler driver
Has duplicate: #6778
Related to: #5473
Monitored by: @hcarty

Bug description

Full_Name: frédéric BESSON
Version: 3.09+dev16 (2005-02-16)
OS: MACOSX
Submission from: zarquon.irisa.fr (131.254.10.195)

Hi all,

Suppose that b.cmx depends on a.cmx but are packed the other way round

ocamlopt -pack -o mylib b.cmx a.cmx
When using mylib, the compiler can issue a type error whose origin is fairly
difficult to find.

The following code illustrates this situation
(* a.ml *)
type a = A

(* b.ml *)
let foo A.A = ()

(* c.ml *)
let _ = Mylib.B.foo Mylib.A.A

File "c.ml", line 1, characters 20-29:
This expression has type Mylib.A.a but is here used with type A.a

It would be nice if ocamlopt -pack would yield a warning (x)or
if the documentation would warn about this side-effect

--
Frédéric

@vicuna
Copy link
Author

vicuna commented Jul 24, 2013

Comment author: @damiendoligez

A warning is the best solution.

@vicuna
Copy link
Author

vicuna commented Feb 25, 2015

Comment author: @damiendoligez

I think this is related to #5473.

@vicuna
Copy link
Author

vicuna commented Feb 28, 2017

Comment author: dsheets

This issue is not isolated to use of -pack. 6778 contains a reproduction which does not use -pack.

@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

No branches or pull requests

1 participant