From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id NAA16394 for caml-redistribution; Fri, 16 Oct 1998 13:36:31 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id MAA06535 for ; Fri, 16 Oct 1998 12:35:50 +0200 (MET DST) Received: from relay5.eunet.fr (relay5.eunet.fr [193.107.193.102]) by nez-perce.inria.fr (8.8.7/8.8.7) with SMTP id MAA08028 for ; Fri, 16 Oct 1998 12:35:48 +0200 (MET DST) Received: from relay2.eunet.fr by relay5.eunet.fr (5.65c8d/96.05.03) via EUnet-France id AA00285; Fri, 16 Oct 1998 11:36:00 +0100 (MET) Received: from dassav (dassav.dassault-aviation.fr [193.106.72.131]) by relay2.eunet.fr (8.8.5/8.8.5) with SMTP id MAA27155 for ; Fri, 16 Oct 1998 12:34:42 +0100 (MET) Received: from fnet-ia1.dassault-aviation.fr by dassav (5.x/SMI-SVR4) id AA29840; Fri, 16 Oct 1998 11:28:28 +0100 Received: from fnet-ia1 by fnet-ia1.dassault-aviation.fr (SMI-8.6/SMI-SVR4) id MAA27447; Fri, 16 Oct 1998 12:40:11 +0200 Sender: weis Message-Id: <3627228B.20CE@dassault-aviation.fr> Date: Fri, 16 Oct 1998 12:40:11 +0200 From: Thierry Bravier Organization: Dassault Aviation DGT/DPR/DESA X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4m) Mime-Version: 1.0 To: caml-list@inria.fr Subject: Re: problem with ocamlmktop -output-obj References: <3624D5BE.3060@dassault-aviation.fr> <19981015192243.14795@pauillac.inria.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Xavier Leroy wrote: > > > I have encountered a problem while trying to build a toplevel > > (ocamlmktop) linked with > > - external C code and > > - ML code compiled as a C object (-output-obj and implicitely -custom). > > I have no problem when I build an ordinary batch (non-toplevel) program. > > Is this a limitation of the system or I am doing it wrong ? > > Toplevels need access to their own symbol table, and they look inside > their executable file to find it. The symbol table information is not > available if -output-obj is selected. > > A regular bytecode executable file is composed of several sections: > code, data, symbols, and debug info. Currently, only the first two > are available when a C object is generated instead of a regular > executable file. > > For the same reasons, you can't debug a Caml program built with > -output-obj. > > Hope this helps, > > - Xavier Leroy Thank you for answering I must now face a problem: Thierry Bravier wrote: > I understand it does not make sense to use -output-obj just to call > printf from C. > In fact, I use it to link ML and C++ code; in this case, C++ needs to > compile main() and link itself (as explained in the manual section > `Embedding the Caml code in the C code', ordinary -custom wants to > link but -output-obj builds a linkable .o file which seems to fit my > needs It would be really nice if I could use -custom but ... How can I ask ocamlc -custom to : 1) use a user-provided compiled main() (potentially compiled with C++) 2) link with a user-provided linker (aka g++) 3) I know that internally, some C code is output and compiled (for the external primitives I think), I think this code should still be compiled with the C compiler used to build ocaml. Are there any clues to help me build this toplevel with C++ code without -output-obj ? Thanks -- Thierry Bravier Dassault Aviation - DGT / DPR / DESA 78, Quai Marcel Dassault F-92214 Saint-Cloud Cedex - France Telephone : (33) 01 47 11 53 07 Telecopie : (33) 01 47 11 52 83 E-Mail : mailto:thierry.bravier@dassault-aviation.fr