Is it a good idea to link my program to statically compiled libc?

I would like to distribute my program knowing full well what it links to (no shared libraries), so I wouldn't get any head-aches later on. I successfully did it for SDL2, GL3W and Nuklear, but I'm not so sure what to do with libc. What do you think? Would there be any disadvantages
when linking libc statically? The advantage would be clear and obvious: my program would be 100% self-contained.

Other urls found in this thread:

midipix.org
twitter.com/AnonBabble

The only reason DLLs still exist is to work around licenses.

>not musl
disgusting

But glibc exists under LGPL which allows linking to them. So I suppose you think that statically linking to glibc is a good idea?

Also, I think there are other reasons that do not interest me:
> free updates without breaking the ABI (security, bug fixes, optimizations)
> smaller binary distribution size
Does it work on Mac and Windows? How hard would it be to port to iOS and Android?

What do you think about this?

midipix.org

forget about it, it's GPL

>implying i know shit
Looks really good.
It's always good when it's easier to write for multi-platform

That's a good thing, right?

My program is closed-source commercial proprietary software.

No one will never know...

Fuck, I might risk it.

...

>only people who would care are freetards
>freetards don't run proprietary software

Stallman will personally break into your home and rape you.

musl libc

dynamically linking libc.so is nearly required by all features taking indirectly advantage of libdl.so or of ld.so -i.e. using dynamic linking-, in particular the NSS related functions (like getpwent and getaddrinfo and many others (nsswitch.conf & nss).

Plus, dynamically linking libc is much more efficient because the RAM is nearly shared by all processes using libc.so and the executable size is smaller; and most importantly, upgrading libc.so is easier.

So don't be a faggot and steal stallman's baby.

>Interchangeable components
>Can be independently updated
>Reduces redundant copies of code (at least on Linux systems)
>Runtime linking
>Easier/faster development
No, that's not the only reason.

Stallman runs all proprietary software in a virtual machine under Windows and runs them through a disassembler. He's memorized all the ASM for every GPL program and library. If he even sees any semblance of similar syscalls, he will shut your ass down with a C&D, forcing you to GPL your program.

>Interchangeable components that shouldn't be interchanged because it leads to defects and vulnerabilities
>Can be independently updated, but shouldn't for reason #1
>Reduces redundant copies of code (at least on Linux systems) but blows up net size, since each program comes with a different or even modified version and the compiler can't remove unused stuff
>Runtime linking/Easier/faster development but the mechanisms are that fragile, compiler dependent and shitty that most software goes back to scripting extensions and ipc mechanisms

You can't link glibc statically for a variety of reasons which include how it was architectured. You will have a ton of headaches if you try to use glibc.

Use musl instead. Has a more friendly license for what you want to do.

Link statically.

You can just distribute it along the binary and have a start script which tells it to use the copy in the current directory and not the system.

>Interchangeable components

From: Rob Pike
Subject: mmap and shared libraries
Date: Wed, 5 Nov 2008 17:23:54 -0800

When Sun reported on their first implementation of shared libraries,
the paper they presented (I think it was at Usenix) concluded that
shared libraries made things bigger and slower, that they were a net
loss, and in fact that they didn't save much disk space either. The
test case was Xlib, the benefit negative. But the customer expects us
to do them so we'll ship it.

So yes, every major operating system implements them but that does not
mean they are a good idea. Plan 9 was designed to ignore at least
some of the received wisdom.

When Jerry is right, he is right.