mailing list of musl libc
 help / color / mirror / code / Atom feed
From: "piranna@gmail.com" <piranna@gmail.com>
To: musl@lists.openwall.com
Subject: Re: static build and dlopen
Date: Wed, 27 Aug 2014 22:07:43 +0200	[thread overview]
Message-ID: <CAKfGGh3frE+-NLWupof2qgb69dXVc0Ce7P+9TuoO4KP1KDY12g@mail.gmail.com> (raw)
In-Reply-To: <CAK4o1WxSLAnGtOv+eVAMP107E0_wxEJ1A82MkDx5soQRvgeN2w@mail.gmail.com>

> If this is really true, and they are static, then you should be able
> to write a loader that has a function called dlopen etc but which is
> not actually the full dynamic linker, just pretends to be, and will
> work from a static binary. It could link in the modules at compile
> time and just return static pointers (I have done this with Lua code,
> pretending to be in a dynamic environment when actually in a static
> one, just return pointers from dlsym calls that are fixed at compile
> time).

I'm not fully sure how Node.js compiled modules works, only that the
standard is to generate them statically linked with no external
dependencies. This leads to have full libraries inside each package
(node-webrtc has a full copy of libjingle, for example...), but has
the advantage that the system is more stable to change of dependencies
or of enviroment, since each "project" is fully isolated from a code
and libraries point of view.

Regarding to your comment, are you suggesting to code a dlopen()
function that mimics the behaviour of the dynamic one, but returning
references to code already statically linked on the executable? If so,
it's the same as if I would tape the node modules to the executable
previously to know what the developer would use, and this is
impossible... Have I misunderstood something?

Good trick anyway, I'll pin your message for reference :-)

-- 
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
Unix."
– Linus Tordvals, creador del sistema operativo Linux


  reply	other threads:[~2014-08-27 20:07 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-27 14:14 piranna
2014-08-27 15:27 ` Szabolcs Nagy
2014-08-27 17:01   ` piranna
2014-08-27 17:20     ` Justin Cormack
2014-08-27 20:07       ` piranna [this message]
2014-08-27 16:43 ` Rich Felker
2014-08-27 17:10   ` piranna
2014-08-27 18:48     ` Laurent Bercot
2014-08-27 20:19       ` piranna
2014-08-27 20:51         ` Rich Felker
2014-08-27 20:59         ` Laurent Bercot
2014-08-27 21:04           ` Rich Felker
2014-08-27 22:54           ` Kurt H Maier
2014-08-27 23:24             ` Laurent Bercot
2014-08-27 23:36               ` Brent Cook
2014-09-01 23:38                 ` piranna
2014-09-02  0:38                   ` Rich Felker
2014-09-02  0:49                     ` piranna

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=CAKfGGh3frE+-NLWupof2qgb69dXVc0Ce7P+9TuoO4KP1KDY12g@mail.gmail.com \
    --to=piranna@gmail.com \
    --cc=musl@lists.openwall.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).