"compiling" libraries

Compilation translates human-readable source code into machine-readable object code. It's something you have to do to execute the code, unless it's an interpreted language that interprets the actual source code rather than bytecode, such as JavaScript. In the case of a language like C, the object code is machine code: the native language of the CPU (think assembly). In interpreted languages like Python or Java, the object code is bytecode native to the interpreter.

Usually, when you're sent a binary (e.g. from the Trisquel repo), it's already compiled in the way that produces the best-optimized binary. Re-compiling won't do any harm, but it won't do any good either unless the person who compiled the binary cannot be trusted to give you the binary that actually corresponds with the source code.

>Are libraries compiled? Is there any sort of optimization that can be done to them?

It depends on programming language and implementation. For C and C++ which are the most common non-web (server side or client side) programming languages, libraries are compiled very similarity as how programs are compiled to executables. Almost all optimizations that can be used when compiling to executables can be used when compiling libraries. A notable exception is that when compiling native-code dynamically loaded libraries (Also called “shared libraries”, they have the file name extension “.so”), the machine code must be position independent (search for “position-independent code”) which is done with -fpic in GCC, that disables some optimizations.

Some programming languages have native-compiling, bytecode-compiling and interpreting implementations; for example: Common Lisp and Scheme.|

>I know you can compile an executable and if you turn on compiler optimizations it might speed it up but also might make bugs and limits it to one processor.

This is a misconception. You should raise your standard for what you think you know (research better before thinking you know something).

Optimization doesn't introduced bugs unless the compiler is buggy. If a program (whether executable or a library) is correct, then a correct compiler will produce a correct output (executable, shared library, bytecode, etcetera). Optimization sometimes trigger bugs (or it may hide bugs that would otherwise appear).

In GCC only some optimization options enable or disable instructions. It doesn't limit the program to only one CPU, but to the set of processors that implement those instructions. The main option to enable instructions is “-march”. Use “-march=local” if you will only run that executable or library in the CPU that you are using to compile it.

When compiling with GCC, the main optimization options are “-On” with a number in the range 0-3 in place of n (the higher, the more it will optimize, up to 3). “-O2” is the usual default option. As far as I know, using these optimizations options (the ones mentioned in this paragraph) will not enable more instructions, so you can use “-O3” without losing compatibility with CPUs that would be compatible otherwise.

When I use GCC, I usually compile with optimization options “-s -O3 -march=native -fomit-frame-pointer”. Consult the manual for more information.

Changelog 2015-03-17 18:46 UTC: Change “to only one process” to “to only one CPU”.

Rule of thumb: trust the developer who makes the package (especially if he or she is a Debian/Ubuntu/Trisquel developer).

I've been using debian wheezy 7.8 for almost a week now - only the main repo. It works great (xfce DE). They really need to get rid of the contrib and non-free repos and stop suggesting "install flash player" in iceweasel. Other then that, it is a completely free OS by default. And one can easily keep it free. Just don't enable the two non-free repos and don't install nothing proprietary on it.