Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Sylvain Le Gall <sylvain@le-gall.net>
To: caml-list@inria.fr
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)	[thread overview]
Message-ID: <slrnfkt208.v2a.sylvain@gallu.homelinux.org> (raw)
In-Reply-To: <f69c840c0711281606n710cacc5j1bf6d2a22af5c1f1@mail.gmail.com>

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...

Regards,
Sylvain Le Gall


      parent reply	other threads:[~2007-11-29  9:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-29  0:06 Eric Merritt
2007-11-29  0:18 ` [Caml-list] " Gerd Stolpmann
2007-11-29  5:14 ` Garrett Jones
2007-11-29  9:36 ` Sylvain Le Gall [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=slrnfkt208.v2a.sylvain@gallu.homelinux.org \
    --to=sylvain@le-gall.net \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox