FranciscoPombal wrote: ↑Tue Sep 29, 2020 3:39 pm
There are many reasons for compiling from source. Some of them are:
- Compiling with different flags than the official releases (e.g. enabling more optimization flags/CPU specific instruction flags to get more performance).
- Compiling any commit, including the very latest one, thereby opening up the possibility of enjoying new features even before they make it into an official release
- Making sure the resulting binary is trustworthy. Since you've built it yourself in your machine, you can be sure there were no modifications made to the sources other than those you made yourself. Ultimately, the only way to fully fully trust binaries built by others is if the build is 100% reproducible.
On Windows/macOS, you typically don't have the opportunity to do this very often, due to the nature of those proprietary software ecosystems and the incentives there.
Check out these resources to learn more:
https://www.wired.com/2010/02/Compile_S ... urce_Code/
https://www.makeuseof.com/tag/binary-so ... kages-use/
https://unix.stackexchange.com/question ... ll-package
https://www.reddit.com/r/linuxquestions ... s_package/
https://reproducible-builds.org/
I'm in the process of writing an easier guide for Windows, following the build system improvements that I made a while ago. Stay tuned!
Thank you
your 2nd and 3rd point i was guessing aswell, would it be possible to compile with different libtorrent settings? As there are many things you can change in libtorrent, but u cant access them in qbittorrent?
EDIT: It seems this is exactly what i want, i will go on this compile journey
, i always wondered how to apply the "settings_pack" that is mentioned on libtorrent website.
One question, how/in what format do i enter values in settings_pack?
For example: (i dont know how to edit text in a good way, sorry for this)
// This controls which IP address outgoing TCP peer connections are bound
// to, in addition to controlling whether such connections are also
// bound to a specific network interface/adapter (*bind-to-device*).
// This string is a comma-separated list of IP addresses and
// interface names. An empty string will not bind TCP sockets to a
// device, and let the network stack assign the local address. A
// list of names will be used to bind outgoing TCP sockets in a
// round-robin fashion. An IP address will simply be used to `bind()`
// the socket. An interface name will attempt to bind the socket to
// that interface. If that fails, or is unsupported, one of the IP
// addresses configured for that interface is used to `bind()` the
// socket to. If the interface or adapter doesn't exist, the
// outgoing peer connection will fail with an error message suggesting
// the device cannot be found. Adapter names on Unix systems are of
// the form "eth0", "eth1", "tun0", etc. This may be useful for
// clients that are multi-homed. Binding an outgoing connection to a
// local IP does not necessarily make the connection via the
// associated NIC/Adapter.
outgoing_interfaces,