[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 27 Aug 2014 22:07:43 +0200
From: "piranna@...il.com" <piranna@...il.com>
To: musl@...ts.openwall.com
Subject: Re: static build and dlopen
> 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
