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.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 7223 Reporter:@let-def Status: acknowledged (set by @damiendoligez on 2016-04-14T15:35:20Z) Resolution: open Priority: normal Severity: minor Version: 4.02.3 Category: misc Related to:#4148 Monitored by:@hcarty
Bug description
The issue is two fold:
First, the -pack option of the compiler seems to accept cmi files (interface only) as input.
There is extensive code in the compiler to support this (PM_intf in */*packager.ml files), so I guess this is a desired feature.
However I couldn't find corresponding documentation or specification, so I am unsure what the intended behavior is. Could this be clarified in the manual?
Finally, an inconsistent behavior appears between native and bytecode backends when mixing module aliases and packed interfaces.
Packing a CMI and referring to it via a module alias module A = My_packed_intf in another packed module fails in bytecode but succeeds in native.
Steps to reproduce
Launching make with the three files provided triggers the issue.
A and B are setup as described above and the Makefile packs both with a bytecode and a native target.
Expected output:
$ make
ocamlopt -for-pack Fail -c a.mli
ocamlopt -for-pack Fail -c b.ml
ocamlopt -pack -o fail.cmx a.cmi b.cmx
ocamlc -for-pack Fail -c a.mli
ocamlc -for-pack Fail -c b.ml
ocamlc -pack -o fail.cmo a.cmi b.cmo
File "none", line 1:
Error: Forward reference to A in file b.cmo
Makefile:9: recipe for target 'byte' failed
make: *** [byte] Error 2
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.
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.
Original bug ID: 7223
Reporter: @let-def
Status: acknowledged (set by @damiendoligez on 2016-04-14T15:35:20Z)
Resolution: open
Priority: normal
Severity: minor
Version: 4.02.3
Category: misc
Related to: #4148
Monitored by: @hcarty
Bug description
The issue is two fold:
First, the -pack option of the compiler seems to accept cmi files (interface only) as input.
There is extensive code in the compiler to support this (PM_intf in */*packager.ml files), so I guess this is a desired feature.
However I couldn't find corresponding documentation or specification, so I am unsure what the intended behavior is. Could this be clarified in the manual?
Finally, an inconsistent behavior appears between native and bytecode backends when mixing module aliases and packed interfaces.
Packing a CMI and referring to it via a module alias
module A = My_packed_intf
in another packed module fails in bytecode but succeeds in native.Steps to reproduce
Launching make with the three files provided triggers the issue.
A and B are setup as described above and the Makefile packs both with a bytecode and a native target.
Expected output:
$ make
ocamlopt -for-pack Fail -c a.mli
ocamlopt -for-pack Fail -c b.ml
ocamlopt -pack -o fail.cmx a.cmi b.cmx
ocamlc -for-pack Fail -c a.mli
ocamlc -for-pack Fail -c b.ml
ocamlc -pack -o fail.cmo a.cmi b.cmo
File "none", line 1:
Error: Forward reference to A in file b.cmo
Makefile:9: recipe for target 'byte' failed
make: *** [byte] Error 2
Additional information
Also fails on 4.03.0+beta2
File attachments
The text was updated successfully, but these errors were encountered: