Timeline for Is it good practice to statically link libstdc++ and/or libgcc when creating distributable binaries for Linux?
Current License: CC BY-SA 4.0
8 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Jan 30, 2019 at 11:22 | audit | Suggested edits | |||
Jan 30, 2019 at 11:23 | |||||
Jan 16, 2019 at 6:08 | vote | accept | Robert Fraser | ||
Jan 9, 2019 at 10:45 | comment | added | Lie Ryan | I think one piece of context you haven't really provided here is what the native JNI library actually does. If the native library is simply a computational optimisation (e.g. vector instructions), then you might not actually depend on libc at all. If it is used to call kernel features that aren't supported by Java (e.g. fork) then static linking libc means you'll be depending directly on the Linux kernel. If the part of libc that you used is dependant on system configuration (e.g. dns lookup, passwd file), then you'll be even more dependant on using the particular libc version of the distro. | |
Jan 9, 2019 at 6:30 | answer | added | GrandmasterB | timeline score: 8 | |
Jan 8, 2019 at 13:55 | answer | added | Lie Ryan | timeline score: 1 | |
Jan 8, 2019 at 13:31 | comment | added | Robert Fraser | So as far as I understand there are 3 things to worry about. Libstdc++ (static link), libc (never static link) and libgcc (which comtains pthreads and stuff). The old link says this shouldn't be linked on GNU systems, understandably, but then alpine is broken. | |
Jan 8, 2019 at 13:14 | comment | added | cauchi | I think you answered your own question. The first line of link starts with "Statically linking to libstdc++ is fine". For the reasons you give and the reasons in the article I would link statically libstdc. Maybe not for libc. | |
Jan 8, 2019 at 9:54 | history | asked | Robert Fraser | CC BY-SA 4.0 |