From: Richard Jones <rich@annexia.org>
To: caml-list@inria.fr
Subject: objinfo doesn't give right module names for packed modules
Date: Mon, 3 Mar 2008 14:20:40 +0000 [thread overview]
Message-ID: <20080303142039.GA8839@annexia.org> (raw)
This is the output of objinfo for a library which depends on the
calendar package, version 2. In this new version of calendar, all
modules are compiled with -for-pack and packed under a single top
level module called 'CalendarLib'[1].
However objinfo doesn't show what I'd consider to be the true module
names:
File /usr/lib/ocaml/pgocaml/pgocaml.cma
Force custom: no
Extra C object files:
Extra C options: -I/usr/lib/ocaml/csv -I/usr/lib/ocaml/calendar -I/usr/lib/ocaml/pcre -I/usr/lib/ocaml/extlib
Unit name: PGOCaml_config
Interfaces imported:
8ba3d1faa24d659525c9025f41fd0c57 Pervasives
3a213460288e45681958941e81d1020c PGOCaml_config
Uses unsafe features: no
Unit name: PGOCaml
Interfaces imported:
b9ee51d35819429061ce9ee1bac36c96 Time_Zone
^ Should be CalendarLib.Time_Zone
da1ce9168f0408ff26158af757456948 List
aa8e3cd5824f9bb40b93fcd38d0c95b5 Array
9936935480b36bcbc716ee513f37876c Random
5dbbf45a03b54e6dbfcf39178d0d6341 Printf
642aab18369aadca0b70eea7cc0b6f6c Ftime
^ Should be CalendarLib.Ftime
53d99e65d6fe50aa5270d472150ffbd7 PGOCaml
b00eccf481484d6175e1313a172d8b6a Date
82717999a586ede6925c0aa18d6562ac Printexc
c16e527384c2b6d71d8b19582503f5f1 Enum
f6cef633ea14963b84b79c4095c63dc3 Buffer
cc35eea52e247d128e2e6ed0dba3bae0 Period
259cfd8d508c1285ebfccd5d9d1e7f7d Fcalendar
^ Should be CalendarLib.Fcalendar
[etc]
I had a look at the source for objinfo, and there doesn't seem any
obvious way to turn on such information. But even stranger, it's as
if the full module name isn't stored at all in the .cma file. This
is what the relevant structure contains:
type compilation_unit =
{ cu_name: string; (* Name of compilation unit *)
mutable cu_pos: int; (* Absolute position in file *)
cu_codesize: int; (* Size of code block *)
cu_reloc: (reloc_info * int) list; (* Relocation information *)
cu_imports: (string * Digest.t) list; (* Names and CRC of intfs imported *)
cu_primitives: string list; (* Primitives declared inside *)
mutable cu_force_link: bool; (* Must be linked even if unref'ed *)
mutable cu_debug: int; (* Position of debugging info, or 0 *)
cu_debugsize: int } (* Length of debugging info *)
Basically its the contents of cu_imports which is the list of
"Interfaces imported" printed out by objinfo. So I don't understand
how one might print out the full module name, or if this is even
possible?
Rich.
[1] For reference, this is how calendar is built:
ocamlc.opt -I src -c src/utils.mli
ocamlc.opt -I src -c src/utils.ml
ocamlc.opt -I src -c src/time_Zone.mli
ocamlc.opt -I src -c src/time_Zone.ml
ocamlc.opt -I src -c src/period.mli
ocamlc.opt -I src -c src/time_sig.mli
ocamlc.opt -I src -c src/time.mli
ocamlc.opt -I src -c src/time.ml
ocamlc.opt -I src -c src/ftime.mli
ocamlc.opt -I src -c src/ftime.ml
ocamlc.opt -I src -c src/date_sig.mli
ocamlc.opt -I src -c src/date.mli
ocamlc.opt -I src -c src/date.ml
ocamlc.opt -I src -c src/calendar_sig.mli
ocamlc.opt -I src -c src/calendar_builder.mli
ocamlc.opt -I src -c src/calendar_builder.ml
ocamlc.opt -I src -c src/calendar.mli
ocamlc.opt -I src -c src/calendar.ml
ocamlc.opt -I src -c src/fcalendar.mli
ocamlc.opt -I src -c src/fcalendar.ml
ocamlc.opt -I src -c src/printer.mli
ocamlc.opt -I src -c src/printer.ml
ocamlc.opt -I src -c src/version.mli
ocamlc.opt -I src -c src/version.ml
ocamlfind ocamlc -I src -pack -o target/calendarLib.cmo \
src/utils.cmo src/time_Zone.cmo src/time.cmo src/ftime.cmo src/date.cmo src/calendar_builder.cmo src/calendar.cmo src/fcalendar.cmo src/printer.cmo src/version.cmo
ocamlopt.opt -I src -noassert -for-pack CalendarLib -c src/utils.ml
ocamlopt.opt -I src -noassert -for-pack CalendarLib -c src/time_Zone.ml
ocamlopt.opt -I src -noassert -for-pack CalendarLib -c src/time.ml
ocamlopt.opt -I src -noassert -for-pack CalendarLib -c src/ftime.ml
ocamlopt.opt -I src -noassert -for-pack CalendarLib -c src/date.ml
ocamlopt.opt -I src -noassert -for-pack CalendarLib -c src/calendar_builder.ml
ocamlopt.opt -I src -noassert -for-pack CalendarLib -c src/calendar.ml
ocamlopt.opt -I src -noassert -for-pack CalendarLib -c src/fcalendar.ml
ocamlopt.opt -I src -noassert -for-pack CalendarLib -c src/printer.ml
ocamlopt.opt -I src -noassert -for-pack CalendarLib -c src/version.ml
ocamlfind ocamlopt -I src -noassert -pack -o target/calendarLib.cmx \
src/utils.cmx src/time_Zone.cmx src/time.cmx src/ftime.cmx src/date.cmx src/calendar_builder.cmx src/calendar.cmx src/fcalendar.cmx src/printer.cmx src/version.cmx
--
Richard Jones
Red Hat
reply other threads:[~2008-03-03 14:20 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080303142039.GA8839@annexia.org \
--to=rich@annexia.org \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox