Ok I see thank you for your answer. Then what would be advantage to use shared objects? My understanding of Go was that is was quite practical to run on different OS'es without libraries problems, this seems to go against that logic.
As I wrote using the first part, it is a mean to share code that external to the system.
Go uses most of the time static libraries that are compiles inside.
So you are fixated with what you have built the binary with.
If you have a bug in a library, you still need to rebuild the binary.
Using shared object you can just deploy that (something that MS does most of the times).
Also it is a way to create plugins. Let's say you have an RPC interface, and you want to be open for many ways to communicate, sometimes GRPC, sometimes REST, pure TCP or whatever.
You can gain that using a shared object, and load it on runtime (it acts a bit different then on compile time) based on a configuration or need.
For example I have a system that communicates with 4 types of different vendors that each communicate in different protocols. But my system does not require to support all of them at the same time, so only the ones I do need to support are loaded using configuration and a library.
Hi,
Thank you.
Yes, the program will fail to load.
Another issue is that different versions might also break it, because the address or ABI were changed.
When it fails, you as a process do not have the ability to control it, only the OS.
Ok I see thank you for your answer. Then what would be advantage to use shared objects? My understanding of Go was that is was quite practical to run on different OS'es without libraries problems, this seems to go against that logic.
As I wrote using the first part, it is a mean to share code that external to the system.
Go uses most of the time static libraries that are compiles inside.
So you are fixated with what you have built the binary with.
If you have a bug in a library, you still need to rebuild the binary.
Using shared object you can just deploy that (something that MS does most of the times).
Also it is a way to create plugins. Let's say you have an RPC interface, and you want to be open for many ways to communicate, sometimes GRPC, sometimes REST, pure TCP or whatever.
You can gain that using a shared object, and load it on runtime (it acts a bit different then on compile time) based on a configuration or need.
For example I have a system that communicates with 4 types of different vendors that each communicate in different protocols. But my system does not require to support all of them at the same time, so only the ones I do need to support are loaded using configuration and a library.
Oh! That is really interesting. I never thought about doing it that way. Thank you!