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