From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=AWL,HTML_10_20,HTML_MESSAGE, UNPARSEABLE_RELAY autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 5FE25BB84 for ; Thu, 25 Sep 2008 13:04:41 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8DAMMM20jAEhMGmmdsb2JhbACCLTIlI4JYjSABAQEBAQgLCgcRRKcFgWU X-IronPort-AV: E=Sophos;i="4.33,308,1220220000"; d="scan'208,217";a="17737110" Received: from concorde.inria.fr ([192.93.2.39]) by mail1-smtp-roc.national.inria.fr with ESMTP; 25 Sep 2008 13:04:41 +0200 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m8PB4eQL020297 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Thu, 25 Sep 2008 13:04:41 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8DAMMM20jAEhMGmmdsb2JhbACCLTIlI4JYjSABAQEBAQgLCgcRRKcFgWU X-IronPort-AV: E=Sophos;i="4.33,308,1220220000"; d="scan'208,217";a="17737109" Received: from sineb-mail-1.sun.com ([192.18.19.6]) by mail1-smtp-roc.national.inria.fr with ESMTP; 25 Sep 2008 13:04:37 +0200 Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m8PB4URw006770 for ; Thu, 25 Sep 2008 11:04:35 GMT Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K7Q00801ZZ47400@mail-apac.sun.com> (original mail from Xue-Yang.Yan@Sun.COM) for caml-list@inria.fr; Thu, 25 Sep 2008 19:04:30 +0800 (SGT) Received: from [129.158.218.53] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K7R000CS03HW7VV@mail-apac.sun.com>; Thu, 25 Sep 2008 19:04:29 +0800 (SGT) Date: Thu, 25 Sep 2008 18:58:48 +0800 From: bill yan Subject: Re: [Caml-list] What's the purpose of the static library? In-reply-to: <20080923101710.GA29133@annexia.org> Sender: Xue-Yang.Yan@Sun.COM To: Richard Jones Cc: =?ISO-8859-1?Q?St=E9phane_Glondu?= , caml-list@inria.fr Message-id: <48DB6EE8.3040508@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_xBgQArLmiLbKbnYhBqS07w)" X-Accept-Language: zh-cn References: <48D712A8.6090506@sun.com> <48D766CC.5020401@glondu.net> <48D8B266.4000906@sun.com> <20080923101710.GA29133@annexia.org> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; zh-CN; rv:1.7) Gecko/20060627 X-Miltered: at concorde with ID 48DB7048.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; cmxa:01 cmxa:01 ocaml:01 cmi:01 mli:01 compiler:01 'ocamlc:01 mli:01 'ocamlc:01 ml':01 ml':01 toplevel:01 compiler:01 foo:01 cmo:01 This is a multi-part message in MIME format. --Boundary_(ID_xBgQArLmiLbKbnYhBqS07w) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Hi Richard, Thanks a lot for your help on this topic. Now I have a quesiton for the following part: File: library.a and library.cmxa -------------------- These files go together. The *.a file contains compiled native code in the normal system archive format. The *.cmxa file contains metainformation. By my understanding, unlike dlllibrary.so and liblibrary.a give user an option to choose compile dynamically or staticly, it seems for library.a, user can only choose static method. Does that mean "compiled native code" can only be staticly linked to user's application? Thanks & Best regards, Bill Richard Jones ???: >On Tue, Sep 23, 2008 at 05:09:58PM +0800, bill yan wrote: > > >>Thanks a lot for your information. And we'd like to know more about the >>OCaml library architectures, like on what situation dynamic libraries >>are used, and when static libraries are used, and so on.. Really >>appreciate if you could point me to a document that can help on this topic. >> >> > >It's not particularly well-documented, and it changes a little in >3.11, but below is my understanding. There are probably errors in >what follows. If someone can correct the errors then I'll publish a >corrected document. > >File: module.cmi ------------------------------ > >Contains the compiled interface for Module, essentially equivalent to >the contents of the *.mli file but in a compiled/binary form which the >compiler can load easily. > >Created by: 'ocamlc -c module.mli', or if module.mli doesn't exist >then 'ocamlc -c module.ml' (also by 'ocamlopt -c module.ml'). > >Used: Whenever the toplevel or compiler uses any symbol Module.foo, >this file is consulted. > >File: module.cmo ------------------------------ > >Contains the bytecode of the implementation of Module. > >Created by: 'ocamlc -c module.ml' > >Used: When linking bytecode programs, or creating bytecode libraries >(*.cma), or by the toplevel when you use #load, or by Dynlink. > >File: library.cma ------------------------------ > >This is just a set of *.cmo files combined together. > >Created by: 'ocamlc -a' > >Used: Same as for module.cmo > >Files: module.o and module.cmx -------------------- > >These two files go together. The *.o file contains compiled native >code in the normal system object file format. The *.cmx file contains >metainformation about the machine code in the *.o file. > >Created by: 'ocamlopt -c module.ml' > >Used: When linking native code programs, or creating native code >libraries. > >Note(1): You normally never need to specify the *.o files by hand. On >the command line when the compiler sees a *.cmx file, it looks for the >corresponding *.o file if it needs it. > >Note(2): It is thought that the *.cmx file needs to be around even >when linking a library (*.cmxa) file in order to do cross-module >function inlining. Both the Debian & Fedora packaging rules specify >that *.cmx files be kept around for this reason. Whether this is >really true or not is not certain. > >File: library.a and library.cmxa -------------------- > >These files go together. The *.a file contains compiled native code >in the normal system archive format. The *.cmxa file contains >metainformation. > >Created by: 'ocamlopt -a' > >Used: Same as for *.o/*.cmx > >Note: You normally never need to specify the *.a files by hand. > >File: dlllibrary.so and liblibrary.a -------------------- > >These files are created and used when a bytecode or native library >contains some C code. 'dllXXX.so' is created for use by the toplevel >and contains the compiled C code. 'libXXX.a' is created for use by >compiled standalone programs and also contains the same compiled C >code. > >Created by: 'ocamlmklib -o library *.o *.cmo' > or: 'ocamlmklib -o library *.o *.cmx' > >Used: dlllibrary.so is dlopen(2)'d by the toplevel. > liblibrary.a is linked in standalone programs. > >Note: You normally never need to specify these files by hand. The >*.cma/*.cmxa file contains the necessary information to find these >files if necessary. > >---------------------------------------------------------------------- > >Rich. > > > --Boundary_(ID_xBgQArLmiLbKbnYhBqS07w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Hi Richard,

Thanks a lot for your help on this topic.  Now I have a quesiton for the following part:

File: library.a and library.cmxa --------------------

These files go together.  The *.a file contains compiled native code
in the normal system archive format.  The *.cmxa file contains
metainformation.


By my understanding, unlike  dlllibrary.so and liblibrary.a give user an option to choose compile dynamically or staticly,  it seems for library.a, user can only choose static method. Does that mean  "compiled native code" can only be staticly linked to user's application?

Thanks & Best regards,
Bill

Richard Jones 已写入: 
On Tue, Sep 23, 2008 at 05:09:58PM +0800, bill yan wrote:
  
Thanks a lot for your information. And we'd like to know more about the 
OCaml library architectures, like on what situation dynamic libraries 
are used, and when static libraries are used, and so on.. Really 
appreciate if you could point me to a document that can help on this topic.
    

It's not particularly well-documented, and it changes a little in
3.11, but below is my understanding.  There are probably errors in
what follows.  If someone can correct the errors then I'll publish a
corrected document.

File: module.cmi ------------------------------

Contains the compiled interface for Module, essentially equivalent to
the contents of the *.mli file but in a compiled/binary form which the
compiler can load easily.

Created by: 'ocamlc -c module.mli', or if module.mli doesn't exist
then 'ocamlc -c module.ml' (also by 'ocamlopt -c module.ml').

Used: Whenever the toplevel or compiler uses any symbol Module.foo,
this file is consulted.

File: module.cmo ------------------------------

Contains the bytecode of the implementation of Module.

Created by: 'ocamlc -c module.ml'

Used: When linking bytecode programs, or creating bytecode libraries
(*.cma), or by the toplevel when you use #load, or by Dynlink.

File: library.cma ------------------------------

This is just a set of *.cmo files combined together.

Created by: 'ocamlc -a'

Used: Same as for module.cmo

Files: module.o and module.cmx --------------------

These two files go together.  The *.o file contains compiled native
code in the normal system object file format.  The *.cmx file contains
metainformation about the machine code in the *.o file.

Created by: 'ocamlopt -c module.ml'

Used: When linking native code programs, or creating native code
libraries.

Note(1): You normally never need to specify the *.o files by hand.  On
the command line when the compiler sees a *.cmx file, it looks for the
corresponding *.o file if it needs it.

Note(2): It is thought that the *.cmx file needs to be around even
when linking a library (*.cmxa) file in order to do cross-module
function inlining.  Both the Debian & Fedora packaging rules specify
that *.cmx files be kept around for this reason.  Whether this is
really true or not is not certain.

File: library.a and library.cmxa --------------------

These files go together.  The *.a file contains compiled native code
in the normal system archive format.  The *.cmxa file contains
metainformation.

Created by: 'ocamlopt -a'

Used: Same as for *.o/*.cmx

Note: You normally never need to specify the *.a files by hand.

File: dlllibrary.so and liblibrary.a --------------------

These files are created and used when a bytecode or native library
contains some C code.  'dllXXX.so' is created for use by the toplevel
and contains the compiled C code.  'libXXX.a' is created for use by
compiled standalone programs and also contains the same compiled C
code.

Created by: 'ocamlmklib -o library *.o *.cmo'
        or: 'ocamlmklib -o library *.o *.cmx'

Used: dlllibrary.so is dlopen(2)'d by the toplevel.
      liblibrary.a is linked in standalone programs.

Note: You normally never need to specify these files by hand.  The
*.cma/*.cmxa file contains the necessary information to find these
files if necessary.

----------------------------------------------------------------------

Rich.
--Boundary_(ID_xBgQArLmiLbKbnYhBqS07w)--