Re: Creating a statically linked executable for a LuaJIT+C program
- From: Coda Highland <chighland@xxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Sun, 28 Oct 2012 21:51:57 -0700
On Sun, Oct 28, 2012 at 9:33 PM, John Spencer
<maillist-luajit@xxxxxxxxxxx> wrote:
>>>> You can link libc dynamically and the rest statically.
>>>
>>>
>>> this sounds like A Bad Idea. if you dynamically link one component,
>>> you can as well just dynamically link everything, because you'll
>>> lose the advantages of static linking.
>>
>>
>> The libc ABI is extremely stable, much more so than other libraries.
>>
>
> i'd say it is extremely fragile because the ugly headers of glibc will pull
> in a lot of hideous internal __prefixed functions.
> also there's the split in multiple separated libraries like libc, libm,
> libpthread, libdl. if you depend for example on dlopen, and glibc decides to
> move it from -ldl into -lc, you lost.
While this would theoretically be true, it WON'T. POSIX isn't the only
standard glibc is beholden to -- LSB is a relevant standard as well,
and although glibc is the defining example of the LSB standard it
isn't going to go and violate its own rules, because that would break
LSB-compliant distributions.
> in any case, there are linux systems based on non-glibc, and your binary
> will never work on them.
And in light of the previous note, this comment is simply false. Your
beloved musl libc is very nearly compliant with the LSB libc ABI. Most
binaries linked against musl libc will continue to work if libc.so is
suddenly replaced with glibc, and applications using an appropriate
subset of glibc will work if libc.so is suddenly replaced with musl.
musl's author even explicitly said that being able to run proprietary
binary video drivers that link to glibc is a very nice perk and that
musl will try to support it when possible.[1]
/s/ Adam
[1] http://www.openwall.com/lists/musl/2012/07/25/5
Other related posts:
