Make TeamTalk server a static, position independent executable

[tech10]

If the TeamTalk server itself were a static binary built as a position independent executable, this would allow for use on alternate Linux distributions such as Alpine, which don't use glibc and have no official support for glibc in its repositories.

Also, if such an executable were built, it could allow for a container with only the TeamTalk server as an executable within, for anyone with security concerns that doesn't want to run the server with exposure to the rest of their system.

The down side would be that the binary could be larger, though how much larger is difficult to know for sure. I don't see that as much of a disadvantage, though. I think there would be more advantages to this.

[bear101]

Is this still relevant. Can't you use Docker instead?

[tech10]

Docker is not always as light weight as running the application directly. For instance, if I were to run it on Alpine Linux, I would have to install glibc from an unofficial repository in order to run the application, something that I'm not always comfortable with. If I did use Docker, then I'd have to run it and rely on its container management system. Docker can use more than 100MB of ram without running any containers in itself, so I don't utalize it.

Also, if you did want to run the server in a Docker container, utalizing the scratch image to place the executible in, perhaps to enhance security, will only work if the server is compiled as a static executible, not linked externally against libc.

For static linking to a library on Linux, you can check out Musl which should work well.

[bear101]

Is this issue still relevant? In v5.10 tt5srv has been limited to these dependencies:

# ldd TeamTalk5/Server/tt5srv
	linux-vdso.so.1 (0x00007fff129f2000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f31df6a5000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f31df47d000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f31dfb26000)

[tech10]

Yes, it's still a relevant issue, as it's still dynamically linked against some glibc libraries. This would still limit which distributions you can run the server on, to those which utilize glibc. See the original issue post for the reasons behind why I think the server being a static build for Linux would be an advantage.