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

Detecter inclusions multiples de .cmx #3922

Closed
vicuna opened this issue Dec 13, 2005 · 10 comments
Closed

Detecter inclusions multiples de .cmx #3922

vicuna opened this issue Dec 13, 2005 · 10 comments

Comments

@vicuna
Copy link

vicuna commented Dec 13, 2005

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

@vicuna
Copy link
Author

vicuna commented Dec 13, 2005

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).

@vicuna
Copy link
Author

vicuna commented Jan 19, 2012

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.

@vicuna
Copy link
Author

vicuna commented Sep 11, 2012

Comment author: @damiendoligez

I agree with Fabrice: the problem appears only because you are linking a -for-pack'd module.

@vicuna
Copy link
Author

vicuna commented Sep 11, 2012

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).

@vicuna
Copy link
Author

vicuna commented Feb 24, 2017

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.

@vicuna
Copy link
Author

vicuna commented Mar 7, 2017

Comment author: @mshinwell

I think this is effectively a duplicate of #3922.

@vicuna
Copy link
Author

vicuna commented Mar 7, 2017

Comment author: @mshinwell

I meant this is a duplicate of #7086

@vicuna
Copy link
Author

vicuna commented Mar 7, 2017

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.

@vicuna
Copy link
Author

vicuna commented Mar 7, 2017

Comment author: @mshinwell

Yeah. Although #7349 was a duplicate of this one.

@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