Also another question: how exactly the libraries solve the problem of not needing to upgrade…

Libraries themselves don’t solve the problem of not needing to upgrade contracts. In fact, no approach by itself solves that problem. There is no such thing as a silver bullet!
The singleton properties of a library however make upgrading easier because of: 
- they don’t need any instantiation and state management like contracts do
- contracts can store data, libraries can’t
- contracts will blow up the gas costs of other contracts that include them, libraries won’t
We use them extensively to encapsulate business functionality and attach that seamlessly to types used in contracts. 
In the context of upgrades, there are cases where they’re better and cases where we prefer contracts. See the article section on “Use ‘interfaces’ to decouple inter-contract communication” and notice where we use a function `setTokenLedgerAddress` to enable switching the address of a contract which can be upgraded without relinking and redeploying the contract that uses it.
There are 2 core limitations relevant to upgrades we aim to solve: gas limits and contract dependencies. There just isn’t one approach that solves them both well so we’ve offered a few that *together* form a good working solution.
Hope that helps

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.