[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 27 Aug 2014 19:01:37 +0200
From: "piranna@...il.com" <piranna@...il.com>
To: musl@...ts.openwall.com
Subject: Re: static build and dlopen
>> thought libuv is calling to the system dlopen() function, it's said,
>> the musl stub for static builds, making it impossible to load the
>> Node.js compiled modules :-(
>
> dlopen does not work from a statically linked binary
>
> (it can be made to work but it's more complicated than it seems:
> the entire libc should be linked into the application so all
> interfaces are present a loaded module may require which partly
> defeats the purpose of static linking and there are toolchain
> issues with this so it is not implemented)
(facepalm) Ok, didn't though about this use case where the dynamically
loaded module would use components of the host binary.
>> So I ask, does the dlopen() stub really makes sense (the linker is
>> intelligent enought to remove unused code on static builds...)? Is
>> there any alternative I can do? Is there a flag to allow to use the
>> real dlopen() function on static builds, or could it be possible to
>> add it? If not, could I be able to use an external dlopen library (and
>> could I be able to integrate it easily)?
>>
>
> if the loaded modules depend on the libc api (or transitively any
> external dependency) then naive dlopen cannot work with static
> linking and there is no way around this
>
> (btw the same applies to all module systems that can load libraries
> written in c, eg. if you tried a statically linked python you would
> have the same issue: it works if all dependencies are linked in, it
> fails if you load libraries at runtime)
The de-facto standard in Node.js is that all the compiled modules are
static ones (.a files) with no external dependencies at all, just to
make it simpler to move to another environments. This contrast to how
Python works, where compiled modules are dynamic ones (.so). I'm
honestly not sure what are the low-level details of Node.js compiled
modules, but the general idea of Node.js modules is make them as
independent as possible and left to Node.js require() function to
manage the dependencies, so probably this would also apply to compiled
ones... Only point left here is if in fact .node files are in fact .a
files with a different extension or if they are wrapped someway, so in
that case dlopen() is efectively loading .a files (that would be a
surprise to me, but would left open the door to solve this problem...)
>> Oh, and if you are thinking about it: yes, this is a farily similar
>> use case as when compiling OS kernels (at least hybrid ones, like
>> Linux) where you need to compile them statically so it can boot and
>> also has support to load compiled modules on runtime, since in this
>> case, Node.js is in fact the "kernel" and Linux is just a somewhat HAL
>> layer :-P
>
> neither the kernel nor the loaded kernel modules depend on the libc
They don't depend on general-purpose libc, but they are compiled with
klibc or other stripped down versions... :-D
--
"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.
