English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Is there a way to statically link an ocaml app compiled to native code against glibc?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2007-11-29 (09:36)
From: Sylvain Le Gall <sylvain@l...>
Subject: Re: Is there a way to statically link an ocaml app compiled to native code against glibc?
On 29-11-2007, Eric Merritt <cyberlync@gmail.com> 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...

Sylvain Le Gall