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.
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 think its because with most programs to just get stuff up and running, you dont really care much about optimization. that stuff comes last yk. Cleaning up your source and optimizations come after u have a working product.
@@honkhonk8009 Programming optimizations are separate from static/dynamic linking. Lots of people have been telling me however that the actual reason this is the case is because the Rust ABI (Application Binary Interface) is not stable, and that having a stable ABI would severely restrain the ability of the language to be changed, which goes against the goals of the core team. I did ask myself if it would be possible for Rust to ever become stable enough for the ABI to be as stable, though I know nothing about ABIs unfortunately
Hi , it will be really great if you make a video on complete compile process for c or cpp , like what does the -i flag does , whats pkg-config what is linking, how to create a linker script for embedded programming etc . Its very hard to find resources explaining all these and i really want to know the ins and outs
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.
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?
There's a way to change that path for each executable, as far as i know, and desktop entries (icons) usually also include a LD_LIBRARY_PATH at execution. But for most of the time its completely useless to have an shared library, unless you want to preserve the same functionality across the whole system (libc's are a good example of this) or you want to make some sort of plugin system (GIMP and Xfce panel plugins are a good example of this).
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?
hello i know this is 2 months ago, but i think i can reply to the second question in a simplified way not making it address independent will make it look for the same addresses in ram every time, that might not work depending on your program, using that flag makes it set the address table at link time for the program
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.
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
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
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!
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?
The problem is that the Pico only takes one file as input and doesn't do runtime linking. You could link your library into your program at compile time by producing archive files (libtest.a instead of libtest.so). Then your CMakeLists file would pull them in to the UF2 file.
Thanks for the content. I did benefit from this channel
i hope you do more C videos, particularly ones involving pointers on structures, unions, or arrays
Thanks! I knew how to write libraries, but i never completely understood what is happening under the hood. Now i understand at least more!
Pretty good content, man. Keep it up.
Appreciate it!
Awesome video. I had wondered for years how shared libraries worked. Thanks alot.
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.
Shared libraries are very useful, especially when implementing Python in C!
Thank you, I've been struggling with this for a while!
Thank you so much for this video, very well explained and putting into practice really made the difference! 🎉
i learn so much here - thank you for your channel
Your videos are awesome, thank you so much!
Glad you like them!
Just found you. Great expo.
why did i discover this old gold video so late!
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 think its because with most programs to just get stuff up and running, you dont really care much about optimization. that stuff comes last yk.
Cleaning up your source and optimizations come after u have a working product.
@@honkhonk8009 Programming optimizations are separate from static/dynamic linking. Lots of people have been telling me however that the actual reason this is the case is because the Rust ABI (Application Binary Interface) is not stable, and that having a stable ABI would severely restrain the ability of the language to be changed, which goes against the goals of the core team.
I did ask myself if it would be possible for Rust to ever become stable enough for the ABI to be as stable, though I know nothing about ABIs unfortunately
Thank you for this useful video!
Awesome video man!!
Nice explanation.
Glad it was helpful!
Hi , it will be really great if you make a video on complete compile process for c or cpp , like what does the -i flag does , whats pkg-config what is linking, how to create a linker script for embedded programming etc . Its very hard to find resources explaining all these and i really want to know the ins and outs
This was so good! Thanks!
you are the best 👏👏👏...
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.
Great , thank you!
You are welcome!
I would suggest that you zoom in more, for those of us that watch on phones.
It was a good video, thanks! Do you have a video about static libraries? ❤
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?
There's a way to change that path for each executable, as far as i know, and desktop entries (icons) usually also include a LD_LIBRARY_PATH at execution.
But for most of the time its completely useless to have an shared library, unless you want to preserve the same functionality across the whole system (libc's are a good example of this) or you want to make some sort of plugin system (GIMP and Xfce panel plugins are a good example of this).
Great!!!
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?
hello i know this is 2 months ago, but i think i can reply to the second question in a simplified way
not making it address independent will make it look for the same addresses in ram every time, that might not work depending on your program, using that flag makes it set the address table at link time for the program
Very nice !!
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.
It's how GCC works, that's why the library has to be named starting with lib.
!
can i have some
Awesome
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
Actualy it includes everyhing at that path to your include path so you could include like this:
#include "folder/header.h"
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
Linker will set a static location where the so is located. If it changes, you get so not found. Check with 'ldd' command
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?
Thank you!
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.
Generally they would be in some header file that you have to declare in your main.c
You misspelled “maintenance”. Didn’t know if you realized that 3 years after the fact. Haha
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!
2) The declarations are necessary but often put into header files. Like printf probably is declared somewhere in stdio.h
@@thediaclub4781 Thanks a lot for kind reply!!!
thank you!
thanks !
Fico muito grato por ter acesso a um conteúdo de qualidade de maneira totalmente gratuita. Obrigado de coração
DWM?
build a shared library for android is so painful
I see you are not a ricer.
Base I3.
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 ?
In my macbook, after I renamed the libmy_math into libmmath, the linker can't work, it still looked for libmy_math obj but not libmmath
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?
The problem is that the Pico only takes one file as input and doesn't do runtime linking. You could link your library into your program at compile time by producing archive files (libtest.a instead of libtest.so). Then your CMakeLists file would pull them in to the UF2 file.