statically compiling a program takes all of the shared libaries and compiles it into a big binary. meaning if your program relies on gtk, aspell, and like, a bunch of other libraries, you can compile them *directly* into the binary and avoid requiring external dependecies at run time

the command to statically compile a binary is '-static', and that needs to be appended to the c/cpp compiler, which includes gcc/llvm!

the binary i think should be architecture compliant and linux distribution agnostic, meaning you can possibly compile a static binary for ubuntu and it should run on fedora, worked like this last time i tried, however i dont think a static binary will work on both bsd and linux, but i havent tried

the downsides is the binary will be fairly big considering all of its depenencies will be compiled directly into the binary, and poses a security threat if one of the dependencies are compromised, meaning if you have a root kit in one of the shared libaries, it will be infact in the binary (which is the big reason no one really uses static binaries, especially those downloaded from an untrusted source on the internet

this is however good for sharing in close quarters, where some people dont want to download so many dependencies for your software, or if you have custom libraries and depencies you dont want to share with people

again, this can take a 5mb binary and inflate it up to 200mb! considering whats been compiled against it

another downside to statically compiled binaries is its relatively impossible to upgrade or downgrade a shared library linked against it without recompiling the entire program, this is important to note when it comes to security

a few positives to statically compiling binaries is the closed source model it can adhere to, not requiring as many extrnal shared libariies for the end user, and not requiring the user to download a ton of depencies, again, this is at the cost of file space and possibly memory

happy compiling!
unidef