#599093 dh_ocaml: warns on not resolving dependencies on modules contained in the application

Package:
dh-ocaml
Source:
dh-ocaml
Submitter:
Ralf Treinen
Date:
2010-10-05 13:33:11 UTC
Severity:
normal
#599093#5
Date:
2010-10-04 15:41:50 UTC
From:
To:
dh_ocaml spits out a list of warnings concerning modules that are in fact
defined in the application program itself, which is annoying. Example
bibtex2html (which is compiled to bytecode, if that matters):

   dh_ocaml
W: bibtex2html doesn't resolve dependency on unit Condition_parser
W: bibtex2html doesn't resolve dependency on unit Condition_lexer
W: bibtex2html doesn't resolve dependency on unit Latexmacros
W: bibtex2html doesn't resolve dependency on unit Bibtex
W: bibtex2html doesn't resolve dependency on unit Options
W: bibtex2html doesn't resolve dependency on unit Translate
W: bibtex2html doesn't resolve dependency on unit Bib2bib
W: bibtex2html doesn't resolve dependency on unit Latex_accents
W: bibtex2html doesn't resolve dependency on unit Parse_condition
W: bibtex2html doesn't resolve dependency on unit Bibfilter
W: bibtex2html doesn't resolve dependency on unit Version
W: bibtex2html doesn't resolve dependency on unit Bibtex_lexer
W: bibtex2html doesn't resolve dependency on unit Condition
W: bibtex2html doesn't resolve dependency on unit Biboutput
W: bibtex2html doesn't resolve dependency on unit Bbl_lexer
W: bibtex2html doesn't resolve dependency on unit Bibtex_parser
W: bibtex2html doesn't resolve dependency on unit Copying
W: bibtex2html doesn't resolve dependency on unit Expand
W: bibtex2html doesn't resolve dependency on unit Readbib
W: bibtex2html doesn't resolve dependency on unit Latexscan
W: bibtex2html doesn't resolve dependency on unit Html
W: bibtex2html doesn't resolve dependency on unit Main
#599093#10
Date:
2010-10-04 18:32:21 UTC
From:
To:
severity 599093 wishlist
tags 599093 + moreinfo
thanks

I don't know what's the purpose of this bug and how you want us to deal
with it. So, I'm adding appropriate tags and reducing the severity.

Note that those warnings are important to be sure that all external
modules are resolved.

Regards,
#599093#19
Date:
2010-10-04 19:01:41 UTC
From:
To:
They are not external. They are internal to the program.
#599093#28
Date:
2010-10-04 19:34:50 UTC
From:
To:
I said "to be sure that all external modules are resolved". If all
listed modules are local, then it's fine and it's good to check that.
IIRC, there are some cases when it's not possible to distinguish between
local/external modules but I failed to remember exactly the cases…
#599093#33
Date:
2010-10-05 12:56:52 UTC
From:
To:
Le 05/10/2010 11:49, Sylvain Le Gall a écrit :

How can symbols be unresolved in OCaml executables?
#599093#38
Date:
2010-10-05 13:31:46 UTC
From:
To:
Le 05/10/2010 14:56, Stéphane Glondu a écrit :

C stubs can be "unresolved", and IIRC dh_ocaml uses dependencies between
ocaml interfaces to find dependencies to dynamic stubs (dll*.so files).
This approach is good to find ABI-zed dependencies, but warnings
generated in this case won't be relevant most of the time.

However, we also have access to dynamic stub dependencies in the
bytecode executables, so I propose we still use OCaml interfaces to find
ABI-zed dependencies, get rid of the warning for so-called "unresolved"
symbols on the OCaml side, and issue warnings for dll*.so that cannot be
found.