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=1.0 required=5.0 tests=AWL,SPF_FAIL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id F28E9BC6B for ; Thu, 29 Nov 2007 10:36:58 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAAoXTkfAXQImh2dsb2JhbACPRQEBAQgKKYEP X-IronPort-AV: E=Sophos;i="4.23,228,1194217200"; d="scan'208";a="19802534" Received: from discorde.inria.fr ([192.93.2.38]) by mail4-smtp-sop.national.inria.fr with ESMTP; 29 Nov 2007 10:36:59 +0100 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id lAT9av8R021661 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Thu, 29 Nov 2007 10:36:58 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAFcWTkdQW+UCh2dsb2JhbACPRQEBAQgKKYEP X-IronPort-AV: E=Sophos;i="4.23,228,1194217200"; d="scan'208";a="6302105" Received: from main.gmane.org (HELO ciao.gmane.org) ([80.91.229.2]) by mail3-smtp-sop.national.inria.fr with ESMTP; 29 Nov 2007 10:36:57 +0100 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ixfp9-00040k-KQ for caml-list@inria.fr; Thu, 29 Nov 2007 09:36:47 +0000 Received: from ks300734.kimsufi.com ([91.121.65.225]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 Nov 2007 09:36:47 +0000 Received: from sylvain by ks300734.kimsufi.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 Nov 2007 09:36:47 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Sylvain Le Gall Subject: Re: Is there a way to statically link an ocaml app compiled to native code against glibc? Date: Thu, 29 Nov 2007 09:36:08 +0000 (UTC) Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ks300734.kimsufi.com User-Agent: slrn/0.9.8.1pl2 (Debian) Sender: news X-Miltered: at discorde with ID 474E8839.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; le-gall:01 statically:01 ocaml:01 ocaml:01 statically:01 non-ocaml:01 pointers:01 advices:01 tarball:01 dlopen:01 bug:01 2007,:98 wrote:01 binaries:01 binaries:01 On 29-11-2007, Eric Merritt wrote: > Everyone, > > I have spent quite a bit of time digging around for this on the net > with now luck. We have a pretty simple ocaml app for which we would > like to distribute an executable binary. For the most part this works. > However, we would like to minimize the number of binaries that we are > forced to distribute. We would also like to avoid any confusion on the > part of our users around figuring out which version of glibc they are > using. For example, we would like to avoid distributing a binary for > each version of glibc available. Its more work for us and has a chance > of confusing some of the folks using our work. Considering the > simplicity of our binary it seems like a good solution would be to be > to just statically link against glibc (our only non-ocaml dependency). > So it would be great if someone could give me pointers to docs that > describe how to do this. Extra points if I can easily do this with > OCamlMakefile. If there is another way to accomplish our goals I am > more then willing to entertain them, as there are a lot of potential > problems involved with static linking against glibc. > Other people had already give you some advices on how to achieve a static link against glibc. I would like to WARN you against this. I have some pretty bad experiences with using static glibc in my binaries. It seems to have something to do with the fact that: * top bugs of glibc (in BUGS in the orginal tarball [ **] Closing shared objects in statically linked binaries most of the times leads to crashes during the dlopen(). Hard to fix. ** is medium severity. * whatever you will statically linked, you will always have to load ld-linux.so -- which makes you fall into the top bug of glibc * you will have to include NSS into your code (so it won't be possible to use system NSS). All in all, you could get really strange behavior by using a statically linked glibc into your code. Of course, this also should not happen... Regards, Sylvain Le Gall