From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 3B0C0820A1 for ; Tue, 10 Sep 2013 18:53:56 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of adrien@notk.org) identity=pra; client-ip=91.121.71.147; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="adrien@notk.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of adrien@notk.org designates 91.121.71.147 as permitted sender) identity=mailfrom; client-ip=91.121.71.147; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="adrien@notk.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@nautica.notk.org) identity=helo; client-ip=91.121.71.147; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="postmaster@nautica.notk.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAMlNL1JbeUeT/2dsb2JhbABbgweEM78WgSUWdIIlAQEFI1YQCxgCAgUTDgICDwUYHQETE4gGrX2Re4EpjjIHgmk0gQADl3UBkWuDIjo X-IPAS-Result: AgYFAMlNL1JbeUeT/2dsb2JhbABbgweEM78WgSUWdIIlAQEFI1YQCxgCAgUTDgICDwUYHQETE4gGrX2Re4EpjjIHgmk0gQADl3UBkWuDIjo X-IronPort-AV: E=Sophos;i="4.90,879,1371074400"; d="scan'208";a="32313449" Received: from nautica.notk.org ([91.121.71.147]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 10 Sep 2013 18:53:55 +0200 Received: by nautica.notk.org (Postfix, from userid 1003) id 34209C009; Tue, 10 Sep 2013 18:53:55 +0200 (CEST) Date: Tue, 10 Sep 2013 18:53:55 +0200 From: Adrien Nader To: Xavier Leroy Cc: oleg@okmij.org, caml-list@inria.fr Message-ID: <20130910165355.GA17264@notk.org> References: <20130910020157.41613.qmail@www1.g3.pair.com> <522F4CE3.5040507@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <522F4CE3.5040507@inria.fr> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [Caml-list] Accelerating compilation On Tue, Sep 10, 2013, Xavier Leroy wrote: > On 10/09/13 04:01, oleg@okmij.org wrote: > > > So, the real problem to me is ocamlc using RTLD_NOW flag when loading > > shared library. Removing the flag would make linking faster, and less > > painful. > > Sounds reasonable. I can give it a try later, but if anyone feels > like experimenting, please share your findings. > > For the record, the intent of this dynamic loading is to check *at > link-time* that dynamically-loaded stubs provide all the external C > functions needed by the OCaml bytecode program. (As opposed to > failing when the bytecode program is started.) In other words, to > detect this problem as early as if one was doing "ocamlc -custom". > > Adrian Nader adds: > > > That completely breaks for cross-compilation. No matter how hard you > > try, you're going to have troubles loading a PE32 shared library from > > your ELF executable (and even more if you try to load AArch64 on > > MIPS). > > Don't worry, it's only for bytecode. Bytecode executables are already > portable across platforms, so no special cross-compilation support is > needed. For native code, ocamlopt links C stub libraries statically, > delegating the job to the (cross-)linker. IIRC the name for unix-related functions are different for Win32, or maybe that some are missing (non-implemented functions). There was something that broke building the compiler (I'm really having a hard time remembering the details though). It's been months since I last touched that part but in the end it was workable and anyway, I doubt many people will try to use bytecode for Windows anyway. -- Adrien Nader