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
Detecter inclusions multiples de .cmx #3922
Comments
Comment author: @alainfrisch Voilà un patch qui implémente le test. Ça donne qqchose comme: Files a.cmx and x.cmx both define a module named X__A (pas très joli). |
Comment author: @lefessan I would say that the problem is that you are trying to link a .cmx directly, while it had been generated for packing. I think the compiler should complain not about the double link, but about linking instead of packing. |
Comment author: @damiendoligez I agree with Fabrice: the problem appears only because you are linking a -for-pack'd module. |
Comment author: @alainfrisch Is it forbidden to link directly a -for-pack'd module ? I agree this is bad style in general, but I was not aware it was forbidden (yet). It could be useful to allow it, e.g. for compiling compiler modules for -for-pack, so as to allow to include them in a third-party project without risking name collisions. But I wouldn't object to disallow it explicitly (probably in byte-code as well). |
Comment author: @mshinwell I believe it is forbidden to link a -for-pack'd module directly -- Flambda cannot deal with this. We should add an error I suppose. |
Comment author: @mshinwell I think this is effectively a duplicate of #3922. |
Comment author: @mshinwell I meant this is a duplicate of #7086 |
Comment author: @alainfrisch I reopen, because I'm not sure to understand why they are the same problem. I understand this one (#3922) would be fixed by disallowing linking directly modules compiled with -for-pack, but not #7086, AFAICT. |
Comment author: @mshinwell Yeah. Although #7349 was a duplicate of this one. |
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: 3922
Reporter: @alainfrisch
Status: confirmed (set by @mshinwell on 2017-03-07T13:23:14Z)
Resolution: reopened
Priority: low
Severity: text
Version: 3.09.0
Category: compiler driver
Tags: patch
Has duplicate: #7349 #7645
Monitored by: @lefessan @alainfrisch
Bug description
Le linker natif détecte en général si on lui demande de mettre plusieurs fois le même module:
../ocaml/ocamlopt -o bug y.cmx y.cmx
Files y.cmx and y.cmx both define a module named Y
Par contre, si l'on -pack un module, la détection ne marche plus:
../ocaml/ocamlopt -for-pack X -c a.ml
../ocaml/ocamlopt -pack -o x.cmx a.cmx
../ocaml/ocamlopt -o bug a.cmx x.cmx
a.o: In function
camlX__A__data_begin': : multiple definition of
camlX__A__data_begin'x.o:: first defined here
a.o: In function
camlX__A__entry': : multiple definition of
camlX__A__code_begin'x.o:: first defined here
a.o: In function
camlX__A': : multiple definition of
camlX__A'x.o:: first defined here
a.o: In function
camlX__A__entry': : multiple definition of
camlX__A__entry'x.o:: first defined here
a.o: In function
camlX__A__code_end': : multiple definition of
camlX__A__code_end'x.o:: first defined here
a.o: In function
camlX__A__data_end': : multiple definition of
camlX__A__data_end'x.o:: first defined here
a.o: In function
camlX__A__frametable': : multiple definition of
camlX__A__frametable'x.o:: first defined here
collect2: ld returned 1 exit status
Error during linking
File attachments
The text was updated successfully, but these errors were encountered: