Statically linking libraries is, more often than not, the right way to go. In theory, shared libraries are nice but in practice, not a lot of sharing can actually take place. To ensure better portability, most developers will distribute the necessary shared libraries along with their application because they cannot be sure that the system that the app is installed on will have the necessary versions of the shared libraries. This fact nullifies the arguments around disk and RAM usage. In the case of containers, the entire file system is shipped with the application. Including all shared libraries.

i hope you do more C videos, particularly ones involving pointers on structures, unions, or arrays

Awesome video. I had wondered for years how shared libraries worked. Thanks alot.

Thanks! I knew how to write libraries, but i never completely understood what is happening under the hood. Now i understand at least more!

Thanks for the content. I did benefit from this channel

Thank you, I've been struggling with this for a while!

Shared libraries are very useful, especially when implementing Python in C!

Awesome video man!!

This was so good! Thanks!

i learn so much here - thank you for your channel

Thank you for this useful video!

Pretty good content, man. Keep it up.

Your videos are awesome, thank you so much!

Just found you. Great expo.

Great , thank you!

Very nice !!

you are the best 👏👏👏...

Great!!!

Thank you!

Nice explanation.

It was a good video, thanks! Do you have a video about static libraries? ❤

thank you!

thanks !

Great video, i found it very interesting, but there are too many concepts for just one video, i hope that you could make another video or course for explain this concepts more deppeer.

Awesome

Can you selectively load them in the program or does the selection of the library that provides the functions have to be done at compile time?

Fun fact ─ related to shared libraries, but not quite C: Rust, as nice of a language as it is, doesn't link its standard library dynamically. Meaning that each time you do any kind of executable, it takes at least 3 MB of space from the get go because Rust's standard library has been appended. There is still a -prefer-dynamic compiler flag, but it is statically linked by default. I'm not informed enough to know why it's like that. Maybe in the future it will become mature enough to prefer dynamic by default, because that would definitely optimize a lot of space, given how much programs are being written in Rust these days.

I would suggest that you zoom in more, for those of us that watch on phones.

It feels a bit clumsy but I suppose that is to explain it better what is happening. But in a production environment I assume it's done so that the end user who will run the program, doesn't need to include the library path every time? Perhaps the library is installed in the default library path by an installer?

Great video! When linking, is it always necessary to set the LD_LIBRARY_PATH environment variable? I was able to link and run a test program without doing so, and I'm wondering what the general conditions are for needing to vs not needing to set it

Fico muito grato por ter acesso a um conteúdo de qualidade de maneira totalmente gratuita. Obrigado de coração

How to include sub-directories in Visual Studio? I have to include many header files, which are in different sub-directories. Is there a way in Visual Studio (I am using 2013 edition) to set one include path that Visual Studio will search also the sub-directories for header files? My Project is in C/C++. Add the "base folder" to the project (project properties -> Configuration Properties -> C/C++ -> Additional Include Directories, "additional include directories") I have tried the above option but it is not possible for me to add each and every directory followed by a semicolon. I have total 60 + different C C++ sub-directories

Thanks for the great video! 2 questions would like to confirm: 1) so from your video, this .so library will be linked at run time, not pre-compiled in the executable main, right? 2) and you don't need to include this shared object library? but you have to put declaration? Thanks a lot!

I have two questions. 1. At 11:45 -L is specified during the gcc command to "let the linker know where to find the shared library". But regardless you still need to set the envvar LD_LIBRARY_PATH. is this because the linker and loader are not the same? 2. During the compilation of the shared library you specified fpic to "make it address independent" what are the consequences of not specifying this? And similarly why exactly do we need to specify this?

If you hadn't declared these functions in main.c, would it succeeded? I think that it wasn't necessary, but I don't know exactly.

You probably don't read this given that it is a 2 years old video. The -lmmath part at 11m38s is confusing. The name of the library is mmath. If you use an option (-l) then usually you would have a space after it to give the string but you typed it without a space and it works.

You misspelled “maintenance”. Didn’t know if you realized that 3 years after the fact. Haha

!

DWM?

Sob, I can’t watch damn videos with loud ass keyboards … they cringe me so hard idk why… but can you show give a link to the info you explained might be??

Thanks for the good content! Just wondering why you name your shared object as `libmy_math.so` but the linker are finding `libmmath.so` ? How the naming match to each other ?

Great vid! How would we do this for the Pico? I was able to get the lib created with arm-none-eabi-gcc -o libtest.so -fpic -shared -s test.c ? What would have to be done in the CMakeLists.txt file?