tikikun · April 7, 2023 07:54 · Feb 28, 2023 · Feb 28, 2023 · Feb 28, 2023 · Feb 11, 2020
diff --git a/compiling_building_c_cpp_notes.md b/compiling_building_c_cpp_notes.md
@@ -1,6 +1,8 @@
 # Things to remember when compiling/linking C/C++ software
-by Angel Leon. March 17, 2015; 
+by Angel Leon. March 17, 2015;
+
 Updated August 29, 2019.
+
 Updated last on February 27, 2023
 
 ## Include Paths

diff --git a/compiling_building_c_cpp_notes.md b/compiling_building_c_cpp_notes.md
@@ -1,5 +1,7 @@
 # Things to remember when compiling/linking C/C++ software
-by Angel Leon. March 17, 2015; August 29, 2019.
+by Angel Leon. March 17, 2015; 
+Updated August 29, 2019.
+Updated last on February 27, 2023
 
 ## Include Paths
 On the compilation phase, you will usually need to specify the different include paths so that the interfaces (.h, .hpp) which define structs, classes, constants, and functions can be found.

diff --git a/compiling_building_c_cpp_notes.md b/compiling_building_c_cpp_notes.md
@@ -2,7 +2,7 @@
 by Angel Leon. March 17, 2015; August 29, 2019.
 
 ## Include Paths
-On the compilation phase, you will usually need to specify the different include paths so that the interfaces (.h, .hpp) which define structs, classes, constans, and functions can be found.
+On the compilation phase, you will usually need to specify the different include paths so that the interfaces (.h, .hpp) which define structs, classes, constants, and functions can be found.
 
 With `gcc` and `llvm` include paths are passed with `-I/path/to/includes`, you can pass as many `-I` as you need.
 
@@ -20,7 +20,7 @@ These compilation time flags are by convention usually put into a single variabl
 ## Object files
 
 When you compile your .c, or .cpp files, you will end up with object files. 
-These files usually have `.o` extensions in Linux, in Windows they might be under `.obj` extensions.
+These files usually have `.o` extensions on Linux, on Windows they might be under `.obj` extensions.
 
 You can create an `.o` file for a single or for many source files.
 
@@ -34,21 +34,25 @@ When you have several `.o` files, you can put them together as a library, a stat
 
 `libctest.a` will contain `ctest1.o`,`ctest2.o` and `ctest2.o`
 
-**They are created like this in Windows:**
+**They are created like this on Windows:**
 
 `LIB.EXE /OUT:MYLIB.LIB FILE1.OBJ FILE2.OBJ FILE3.OBJ`
 
 When you are creating an executable that needs to make use of a library, if you use these static libraries, the size of your executable will be the sum of all the object files statically linked by the executable. The code is right there along the executable, it's easier to distribute, but again, the size of the executable can be bigger than it needs to... why? because, sometimes, many of the `.o` files, or even the entire `.a` file you're linking against might be a standard library that many other programs need.
 
 ## Shared Libraries (Dynamic Libraries)
 
-So ***shared*** or ***dynamic*** libraries were invented so that different programs or libraries would make external (shared) references to them, since they're "shared" the symbols defined in them don't need to be part of your executable or library, your executable contain symbols whose entry points or offset addresses might point to somewhere within themselves, but they will also have symbols whose entry points are expected to exist on shared libraries which need only be loaded once in a single portion of the operating shared memory, thus not just making the size of your executable as small as it needs to be, but you won't need to load the library for every process/program that needs its symbols.
+So ***shared*** or ***dynamic*** libraries were invented so that different programs or libraries would make external (shared) references to them, since they're "shared" the symbols defined in them **don't need to be part of your executable** or library.
+
+Your executable contain symbols whose entry points or offset addresses might point to somewhere within themselves (symbols you defined in your code), but they will also have symbols defined in shared libraries. Shared libraries are only loaded once in physical memory by the OS, but its symbol's offset are virtually mapped to the memory table of each process, so you'll process will see the same library symbols in different addresses that some other process that uses the library.
+
+Thus, not just making the size of your executable as small as it needs to be, but you won't need to spend more physical memory loading the library for every process/program that needs its symbols.
 
 On Linux shared files exist under the `.so` (shared object) file extension, on Mac `.dylib` (dynamic library), and in Windows they're called `.dll` (dynamic link libraries)
 
 Another cool thing about dynamic libraries, is that they can be loaded during runtime, not just linked at compile time. An example of runtime dynamic libraries are browser plugins.
 
-In Linux `.so` files are created like this:
+In Linux, `.so` files are created like this:
 
 ```
 gcc -Wall -fPIC -c *.c
@@ -67,7 +71,7 @@ In Mac `.dylib` files are created like this:
 
 `clang -dynamiclib -o libtest.dylib file1.o file2.o -L/some/library/path -lname_of_library_without_lib_prefix`
 
-In Windows `.dll` files are created like this:
+In Windows, `.dll` files are created like this:
 
 `LINK.EXE /DLL /OUT:MYLIB.DLL FILE1.OBJ FILE2.OBJ FILE3OBJ`
 
@@ -162,7 +166,7 @@ Undefined symbols for architecture x86_64:
       Network::TxMessage::handle(CNode*, CDataStream&, long long, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&, bool, bool) in libbitcoin_server.a(libbitcoin_server_a-TxMessage.o)
 ```
 
-Here, when I read the code of `Network::TxMessage::handle(...)` there was a call to `FlushStateToDisk`, which was declared in `main.h`, and coded in `main.cpp`. My `TxMessage.cpp` did include `main.h`, compilation was fine, I had a `TxMessage.o` file and a `main.o`, but the linker was complaining.
+Here, when I read the code of `Network::TxMessage::handle(...)` there was a call to `FlushStateToDisk`, which was declared in `main.h`, and coded in `main.cpp`. My `TxMessage.cpp` did include `main.h`, the compilation was fine, I had a `TxMessage.o` file and a `main.o`, but the linker was complaining.
 
 The issue was that `FlushStateToDisk` was declared as a `static`, therefore only visible inside `main.o`, once I removed the `static` from the declaration and implementation the error went away and my executable was linked. Similar things happen when functions are declared in anonymous spaces in other files, even if you forward declare them on your local `.h` 
 

diff --git a/compiling_building_c_cpp_notes.md b/compiling_building_c_cpp_notes.md
@@ -46,7 +46,7 @@ So ***shared*** or ***dynamic*** libraries were invented so that different progr
 
 On Linux shared files exist under the `.so` (shared object) file extension, on Mac `.dylib` (dynamic library), and in Windows they're called `.dll` (dynamic link libraries)
 
-Another cool thing about dynamic libraries, is that they can be linked during runtime, not just compile time. An example of runtime dynamic libraries are browser plugins.
+Another cool thing about dynamic libraries, is that they can be loaded during runtime, not just linked at compile time. An example of runtime dynamic libraries are browser plugins.
 
 In Linux `.so` files are created like this:
 

diff --git a/compiling_building_c_cpp_notes.md b/compiling_building_c_cpp_notes.md
@@ -1,5 +1,5 @@
 # Things to remember when compiling/linking C/C++ software
-by Angel Leon. March 17, 2015.
+by Angel Leon. March 17, 2015; August 29, 2019.
 
 ## Include Paths
 On the compilation phase, you will usually need to specify the different include paths so that the interfaces (.h, .hpp) which define structs, classes, constans, and functions can be found.

diff --git a/compiling_building_c_cpp_notes.md b/compiling_building_c_cpp_notes.md
@@ -165,3 +165,9 @@ Undefined symbols for architecture x86_64:
 Here, when I read the code of `Network::TxMessage::handle(...)` there was a call to `FlushStateToDisk`, which was declared in `main.h`, and coded in `main.cpp`. My `TxMessage.cpp` did include `main.h`, compilation was fine, I had a `TxMessage.o` file and a `main.o`, but the linker was complaining.
 
 The issue was that `FlushStateToDisk` was declared as a `static`, therefore only visible inside `main.o`, once I removed the `static` from the declaration and implementation the error went away and my executable was linked. Similar things happen when functions are declared in anonymous spaces in other files, even if you forward declare them on your local `.h` 
+
+In other cases your code compiles and you get this error linking because your library can't be added using -lfoo, and adding its containing folder to -L doesn't cut it, in this case you just add the full path to the library in your compilation command: `gcc /path/to/the/missing/library.o ... my_source.cpp -o my_executable`
+
+### Reminder: 
+
+**DO NOT EXPORT CFLAGS, CPPFLAGS and the like on your `.bash_profile`/`.bashrc`**, it can lead to unintended building consequences in many projects. I've wasted so many hours due to this mistake.
diff --git a/compiling_building_c_cpp_notes.md b/compiling_building_c_cpp_notes.md
@@ -78,7 +78,7 @@ If all the libraries you need exist in a single folder, you can set the `LD_LIBR
 
 Tip: You should probably stay away from altering your `LD_LIBRARY_PATH`, if you do, make sure you keep its original value, and when you're done restore it, as you might screw the build processes of other software in the system which might depend on what's on the `LD_LIBRARY_PATH`.
 
-# What if libraries are in different folders?
+### What if libraries are in different folders?
 If you have some other `libbar.so` library on another folder outside `LD_LIBRARY_PATH` you can explictly pass the full path to that library `/path/to/that/other/library/libbar.so`, or you can specify the folder that contains it `-L/path/to/that/other/library` and then the short hand form `-lbar`. This latter option makes more sense if the second folder contains several other libraries.
 
 ## Useful tools

diff --git a/compiling_building_c_cpp_notes.md b/compiling_building_c_cpp_notes.md
@@ -78,6 +78,7 @@ If all the libraries you need exist in a single folder, you can set the `LD_LIBR
 
 Tip: You should probably stay away from altering your `LD_LIBRARY_PATH`, if you do, make sure you keep its original value, and when you're done restore it, as you might screw the build processes of other software in the system which might depend on what's on the `LD_LIBRARY_PATH`.
 
+# What if libraries are in different folders?
 If you have some other `libbar.so` library on another folder outside `LD_LIBRARY_PATH` you can explictly pass the full path to that library `/path/to/that/other/library/libbar.so`, or you can specify the folder that contains it `-L/path/to/that/other/library` and then the short hand form `-lbar`. This latter option makes more sense if the second folder contains several other libraries.
 
 ## Useful tools

diff --git a/compiling_building_c_cpp_notes.md b/compiling_building_c_cpp_notes.md
@@ -140,13 +140,27 @@ _class_getInstanceVariable
 _class_getIvarLayout
 ```
 
-### It compiles but it won't link
+### My C++ code compiles but it won't link
 
-Linking is simply linking a bunch of .o files to make an executable. Each one of these .o's may compile on their own, but when one references symbols that are supposed to exist in other .o's and they're not found then you get errors.
+Linking is simply "linking" a bunch of .o files to make an executable. 
+
+Each one of these .o's may be compiled on their own out of their .cpp files, but when one references symbols that are supposed to exist in other .o's and they're not to be found then you get linking errors.
 
 Perhaps through forward declarations you managed your compilation phase to pass, but then you get a bunch of symbol not found errors.
 Make sure to read them slowly, see where these symbols are being referenced, you will see that these issues occur due to namespace visibility in most cases. 
 
 Perhaps you copied the signature of a method that exists in a private space elsewhere into some other namespace where your code wasn't compiling, all you did was make it compilable, but the actual symbol might not be visible outside the scope where it's truly defined and implemented. 
 
-Function symbols can be private if they're declared inside anonymous namespaces, or if they're declared as `static` functions.
+Function symbols can be private if they're declared inside anonymous namespaces, or if they're declared as `static` functions.
+
+An example:
+
+```
+Undefined symbols for architecture x86_64:
+  "FlushStateToDisk(CValidationState&, FlushStateMode)", referenced from:
+      Network::TxMessage::handle(CNode*, CDataStream&, long long, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&, bool, bool) in libbitcoin_server.a(libbitcoin_server_a-TxMessage.o)
+```
+
+Here, when I read the code of `Network::TxMessage::handle(...)` there was a call to `FlushStateToDisk`, which was declared in `main.h`, and coded in `main.cpp`. My `TxMessage.cpp` did include `main.h`, compilation was fine, I had a `TxMessage.o` file and a `main.o`, but the linker was complaining.
+
+The issue was that `FlushStateToDisk` was declared as a `static`, therefore only visible inside `main.o`, once I removed the `static` from the declaration and implementation the error went away and my executable was linked. Similar things happen when functions are declared in anonymous spaces in other files, even if you forward declare them on your local `.h` 
diff --git a/compiling_building_c_cpp_notes.md b/compiling_building_c_cpp_notes.md
@@ -138,4 +138,15 @@ _class_getInstanceMethod
 _class_getInstanceSize
 _class_getInstanceVariable
 _class_getIvarLayout
-```
+```
+
+### It compiles but it won't link
+
+Linking is simply linking a bunch of .o files to make an executable. Each one of these .o's may compile on their own, but when one references symbols that are supposed to exist in other .o's and they're not found then you get errors.
+
+Perhaps through forward declarations you managed your compilation phase to pass, but then you get a bunch of symbol not found errors.
+Make sure to read them slowly, see where these symbols are being referenced, you will see that these issues occur due to namespace visibility in most cases. 
+
+Perhaps you copied the signature of a method that exists in a private space elsewhere into some other namespace where your code wasn't compiling, all you did was make it compilable, but the actual symbol might not be visible outside the scope where it's truly defined and implemented. 
+
+Function symbols can be private if they're declared inside anonymous namespaces, or if they're declared as `static` functions.
diff --git a/compiling_building_c_cpp_notes.md b/compiling_building_c_cpp_notes.md
@@ -61,6 +61,7 @@ gcc -shared -Wl,-soname,libctest.so.1 -o libctest.so.1.0   *.o
  * `-shared` makes the object file created shareable by different executables.
  * `-Wl` passes a comma separated list of arguments to the linker.
  * `-soname` means "shared object name" to use.
+ * `-o <my.so>` means output, in this case the output shared library
 
 In Mac `.dylib` files are created like this:
 

diff --git a/compiling_building_c_cpp_notes.md b/compiling_building_c_cpp_notes.md
@@ -13,7 +13,7 @@ Some software uses macro definition variables that should be passed during compi
 
 ## Compilation flags
 These compilation-time variables are passed using `-D`, 
-e.g. `-DMYSOFTWARE_COMPILATION_VARIABLE` `-DDO_SOMETHING=1` `DDISABLE_DEPRECATED_FUNCTIONS=0`
+e.g. `-DMYSOFTWARE_COMPILATION_VARIABLE` `-DDO_SOMETHING=1` `-DDISABLE_DEPRECATED_FUNCTIONS=0`
 
 These compilation time flags are by convention usually put into a single variable named `CXXFLAGS`, which is then passed to the compiler as a parameter for convenience when you're building your compilation/make script.
 
@@ -56,7 +56,7 @@ gcc -shared -Wl,-soname,libctest.so.1 -o libctest.so.1.0   *.o
 ```
 
  * `-Wall` enables all warnings.
- * `-c` means don't run the linker.
+ * `-c` means compile only, don't run the linker.
  * `-fPIC` means "Position Independent Code", a requirement for shared libraries in Linux.
  * `-shared` makes the object file created shareable by different executables.
  * `-Wl` passes a comma separated list of arguments to the linker.

diff --git a/compiling_building_c_cpp_notes.md b/compiling_building_c_cpp_notes.md
@@ -64,7 +64,7 @@ gcc -shared -Wl,-soname,libctest.so.1 -o libctest.so.1.0   *.o
 
 In Mac `.dylib` files are created like this:
 
-`clang -dynamiclib -o libtest.dylib file1.o file2.o -L/some/other/libraries/to/link/live/here -lname_of_library_without_lib_prefix`
+`clang -dynamiclib -o libtest.dylib file1.o file2.o -L/some/library/path -lname_of_library_without_lib_prefix`
 
 In Windows `.dll` files are created like this:
 

diff --git a/compiling_building_c_cpp_notes.md b/compiling_building_c_cpp_notes.md
@@ -55,12 +55,12 @@ gcc -Wall -fPIC -c *.c
 gcc -shared -Wl,-soname,libctest.so.1 -o libctest.so.1.0   *.o
 ```
 
-`-Wall` enables all warnings.
-`-c` means don't run the linker.
-`-fPIC` means "Position Independent Code", a requirement for shared libraries in Linux.
-`-shared` makes the object file created shareable by different executables.
-`-Wl` passes a comma separated list of arguments to the linker.
-`-soname` means "shared object name" to use.
+ * `-Wall` enables all warnings.
+ * `-c` means don't run the linker.
+ * `-fPIC` means "Position Independent Code", a requirement for shared libraries in Linux.
+ * `-shared` makes the object file created shareable by different executables.
+ * `-Wl` passes a comma separated list of arguments to the linker.
+ * `-soname` means "shared object name" to use.
 
 In Mac `.dylib` files are created like this:
 

diff --git a/compiling_building_c_cpp_notes.md b/compiling_building_c_cpp_notes.md
@@ -55,8 +55,12 @@ gcc -Wall -fPIC -c *.c
 gcc -shared -Wl,-soname,libctest.so.1 -o libctest.so.1.0   *.o
 ```
 
+`-Wall` enables all warnings.
+`-c` means don't run the linker.
 `-fPIC` means "Position Independent Code", a requirement for shared libraries in Linux.
 `-shared` makes the object file created shareable by different executables.
+`-Wl` passes a comma separated list of arguments to the linker.
+`-soname` means "shared object name" to use.
 
 In Mac `.dylib` files are created like this:
 

diff --git a/compiling_building_c_cpp_notes.md b/compiling_building_c_cpp_notes.md
@@ -69,7 +69,9 @@ In Windows `.dll` files are created like this:
 ## Linking to existing libraries
 
 When linking your software you may be faced with a situation on which you want to link against several standard shared libraries.
-If all the libraries you need exist in a single folder, you can set the `LD_LIBRARY_PATH` to that folder. ***By common standard all shared libraries are prefix with the word `lib`***. If a library exists in `LD_LIBRARY_PATH` and you want to link against it, you don't need to pass the entire path to the library, you simply pass `-lname` and you will link your executable to the symbols of `libname.so` which should be somewhere inside `LD_LIBRARY_PATH`. 
+If all the libraries you need exist in a single folder, you can set the `LD_LIBRARY_PATH` to that folder. ***By common standard all shared libraries are prefixed with the word `lib`***. If a library exists in `LD_LIBRARY_PATH` and you want to link against it, you don't need to pass the entire path to the library, you simply pass `-lname` and you will link your executable to the symbols of `libname.so` which should be somewhere inside `LD_LIBRARY_PATH`. 
+
+Tip: You should probably stay away from altering your `LD_LIBRARY_PATH`, if you do, make sure you keep its original value, and when you're done restore it, as you might screw the build processes of other software in the system which might depend on what's on the `LD_LIBRARY_PATH`.
 
 If you have some other `libbar.so` library on another folder outside `LD_LIBRARY_PATH` you can explictly pass the full path to that library `/path/to/that/other/library/libbar.so`, or you can specify the folder that contains it `-L/path/to/that/other/library` and then the short hand form `-lbar`. This latter option makes more sense if the second folder contains several other libraries.
 

diff --git a/compiling_building_c_cpp_notes.md b/compiling_building_c_cpp_notes.md
@@ -68,7 +68,7 @@ In Windows `.dll` files are created like this:
 
 ## Linking to existing libraries
 
-When linking your software you may be faced with a situation on which you want to link against several standard share libraries.
+When linking your software you may be faced with a situation on which you want to link against several standard shared libraries.
 If all the libraries you need exist in a single folder, you can set the `LD_LIBRARY_PATH` to that folder. ***By common standard all shared libraries are prefix with the word `lib`***. If a library exists in `LD_LIBRARY_PATH` and you want to link against it, you don't need to pass the entire path to the library, you simply pass `-lname` and you will link your executable to the symbols of `libname.so` which should be somewhere inside `LD_LIBRARY_PATH`. 
 
 If you have some other `libbar.so` library on another folder outside `LD_LIBRARY_PATH` you can explictly pass the full path to that library `/path/to/that/other/library/libbar.so`, or you can specify the folder that contains it `-L/path/to/that/other/library` and then the short hand form `-lbar`. This latter option makes more sense if the second folder contains several other libraries.

diff --git a/compiling_building_c_cpp_notes.md b/compiling_building_c_cpp_notes.md
@@ -99,7 +99,7 @@ Familiarize yourself with the meaning of the symbol types:
  * 
 If the symbol is local (non-external) the symbol type is presented in lowercase letters, for example a lowercase `u` represents an undefined reference to a private external in another module in the same library.
 
-If you're working on Mac and you see that the symbol is preceeded by `+` or `-` it means it's an ObjectiveC method, if you're familiar with ObjectiveC you will know that `+` is for class methods and `-` is for instance methods.
+`nm`'s documentation says that if you're working on Mac and you see that the symbol is preceeded by `+` or `-` it means it's an ObjectiveC method, if you're familiar with ObjectiveC you will know that `+` is for class methods and `-` is for instance methods, but in practice it seems to be a bit more explicit and you will often see `objc` or `OBJC` prefixed to those methods.
 
 `nm` is best used along with `grep` ;)
 

diff --git a/compiling_building_c_cpp_notes.md b/compiling_building_c_cpp_notes.md
@@ -42,7 +42,7 @@ When you are creating an executable that needs to make use of a library, if you
 
 ## Shared Libraries (Dynamic Libraries)
 
-So ***shared*** or ***dynamic*** libraries were invented so that programs would be linked against them, but since they're "shared" they don't need to be part of the executable, your executable will look for symbols expected to exist on a library that will be loaded in a single portion of the operating system's memory, thus not just making the size of your executable as small as it needs to be, but you won't need to load the library for every process/program that needs its symbols.
+So ***shared*** or ***dynamic*** libraries were invented so that different programs or libraries would make external (shared) references to them, since they're "shared" the symbols defined in them don't need to be part of your executable or library, your executable contain symbols whose entry points or offset addresses might point to somewhere within themselves, but they will also have symbols whose entry points are expected to exist on shared libraries which need only be loaded once in a single portion of the operating shared memory, thus not just making the size of your executable as small as it needs to be, but you won't need to load the library for every process/program that needs its symbols.
 
 On Linux shared files exist under the `.so` (shared object) file extension, on Mac `.dylib` (dynamic library), and in Windows they're called `.dll` (dynamic link libraries)
 
@@ -71,4 +71,64 @@ In Windows `.dll` files are created like this:
 When linking your software you may be faced with a situation on which you want to link against several standard share libraries.
 If all the libraries you need exist in a single folder, you can set the `LD_LIBRARY_PATH` to that folder. ***By common standard all shared libraries are prefix with the word `lib`***. If a library exists in `LD_LIBRARY_PATH` and you want to link against it, you don't need to pass the entire path to the library, you simply pass `-lname` and you will link your executable to the symbols of `libname.so` which should be somewhere inside `LD_LIBRARY_PATH`. 
 
-If you have some other `libbar.so` library on another folder outside `LD_LIBRARY_PATH` you can explictly pass the full path to that library `/path/to/that/other/library/libbar.so`, or you can specify the folder that contains it `-L/path/to/that/other/library` and then the short hand form `-lbar`. This latter option makes more sense if the second folder contains several other libraries.
+If you have some other `libbar.so` library on another folder outside `LD_LIBRARY_PATH` you can explictly pass the full path to that library `/path/to/that/other/library/libbar.so`, or you can specify the folder that contains it `-L/path/to/that/other/library` and then the short hand form `-lbar`. This latter option makes more sense if the second folder contains several other libraries.
+
+## Useful tools
+
+Sometimes you may be dealing with issues like `undefined symbol` errors, and you may want to inspect what symbols (functions) are defined in your library.
+
+On Mac there's `otool`, on Linux/Mac there's `nm`, on Windows there's `depends.exe` (a GUI tool that can be used to see both dependencies and the symbol's tables. Taking a look at the "Entry Point" column will help you understand clearly the difference between symbols linking to a shared library vs symbols linking statically to the same library)
+
+### Useful command options
+
+***See shared library dependencies on Mac with `otool`***
+```
+otool -L libjlibtorrent.dylib 
+libjlibtorrent.dylib:
+	libjlibtorrent.dylib (compatibility version 0.0.0, current version 0.0.0)
+	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
+	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
+```
+
+***See shared symbols with `nm` (Linux/Mac)***
+With nm, you can see the symbol's name list.
+Familiarize yourself with the meaning of the symbol types: 
+ * `T` (text section symbol) 
+ * `U` (undefined - useful for those `undefined symbol` error), 
+ * `I` (indirect symbol). 
+ * 
+If the symbol is local (non-external) the symbol type is presented in lowercase letters, for example a lowercase `u` represents an undefined reference to a private external in another module in the same library.
+
+If you're working on Mac and you see that the symbol is preceeded by `+` or `-` it means it's an ObjectiveC method, if you're familiar with ObjectiveC you will know that `+` is for class methods and `-` is for instance methods.
+
+`nm` is best used along with `grep` ;)
+
+***Find all Undefined symbols***
+```
+nm -u libMacOSXUtilsLeopard.jnilib
+_CFRelease
+_LSSharedFileListCopySnapshot
+_LSSharedFileListCreate
+_LSSharedFileListInsertItemURL
+_LSSharedFileListItemRemove
+_LSSharedFileListItemResolve
+_NSFullUserName
+_OBJC_CLASS_$_NSArray
+_OBJC_CLASS_$_NSAutoreleasePool
+_OBJC_CLASS_$_NSDictionary
+_OBJC_CLASS_$_NSMutableArray
+_OBJC_CLASS_$_NSMutableDictionary
+_OBJC_CLASS_$_NSString
+_OBJC_CLASS_$_NSURL
+__Block_copy
+__NSConcreteGlobalBlock
+__dyld_register_func_for_add_image
+__objc_empty_cache
+__objc_empty_vtable
+_calloc
+_class_addMethod
+_class_getInstanceMethod
+_class_getInstanceSize
+_class_getInstanceVariable
+_class_getIvarLayout
+```
diff --git a/compiling_building_c_cpp_notes.md b/compiling_building_c_cpp_notes.md
@@ -71,4 +71,4 @@ In Windows `.dll` files are created like this:
 When linking your software you may be faced with a situation on which you want to link against several standard share libraries.
 If all the libraries you need exist in a single folder, you can set the `LD_LIBRARY_PATH` to that folder. ***By common standard all shared libraries are prefix with the word `lib`***. If a library exists in `LD_LIBRARY_PATH` and you want to link against it, you don't need to pass the entire path to the library, you simply pass `-lname` and you will link your executable to the symbols of `libname.so` which should be somewhere inside `LD_LIBRARY_PATH`. 
 
-If you have some other `libbar.so` library on another folder outside `LD_LIBRARY_PATH` you can explictly pass the full path to that library `/path/to/that/other/library/libbar.so`, or you can specify the folder that contains it `-L/path/to/that/other/library` and then the short hand form `-lbar`. If you have just one library, you can specify the full path to it.
+If you have some other `libbar.so` library on another folder outside `LD_LIBRARY_PATH` you can explictly pass the full path to that library `/path/to/that/other/library/libbar.so`, or you can specify the folder that contains it `-L/path/to/that/other/library` and then the short hand form `-lbar`. This latter option makes more sense if the second folder contains several other libraries.
diff --git a/compiling_building_c_cpp_notes.md b/compiling_building_c_cpp_notes.md
@@ -69,4 +69,6 @@ In Windows `.dll` files are created like this:
 ## Linking to existing libraries
 
 When linking your software you may be faced with a situation on which you want to link against several standard share libraries.
-If all the libraries you need exist in a single folder, you can set the `LD_LIBRARY_PATH` to that folder. ***By common standard all shared libraries are prefix with the word `lib`***. If a library exists in `LD_LIBRARY_PATH` and you want to link against it, you don't need to pass the entire path to the library, you simply pass `-lname` and you will link your executable to the symbols of `libname.so` which should be somewhere inside `LD_LIBRARY_PATH`. If you have some other library on another folder outside `LD_LIBRARY_PATH` you can also specify the complete path to the library file using `-L/path/to/that/other/libfoo.so`
+If all the libraries you need exist in a single folder, you can set the `LD_LIBRARY_PATH` to that folder. ***By common standard all shared libraries are prefix with the word `lib`***. If a library exists in `LD_LIBRARY_PATH` and you want to link against it, you don't need to pass the entire path to the library, you simply pass `-lname` and you will link your executable to the symbols of `libname.so` which should be somewhere inside `LD_LIBRARY_PATH`. 
+
+If you have some other `libbar.so` library on another folder outside `LD_LIBRARY_PATH` you can explictly pass the full path to that library `/path/to/that/other/library/libbar.so`, or you can specify the folder that contains it `-L/path/to/that/other/library` and then the short hand form `-lbar`. If you have just one library, you can specify the full path to it.
diff --git a/compiling_building_c_cpp_notes.md b/compiling_building_c_cpp_notes.md
@@ -67,3 +67,6 @@ In Windows `.dll` files are created like this:
 `LINK.EXE /DLL /OUT:MYLIB.DLL FILE1.OBJ FILE2.OBJ FILE3OBJ`
 
 ## Linking to existing libraries
+
+When linking your software you may be faced with a situation on which you want to link against several standard share libraries.
+If all the libraries you need exist in a single folder, you can set the `LD_LIBRARY_PATH` to that folder. ***By common standard all shared libraries are prefix with the word `lib`***. If a library exists in `LD_LIBRARY_PATH` and you want to link against it, you don't need to pass the entire path to the library, you simply pass `-lname` and you will link your executable to the symbols of `libname.so` which should be somewhere inside `LD_LIBRARY_PATH`. If you have some other library on another folder outside `LD_LIBRARY_PATH` you can also specify the complete path to the library file using `-L/path/to/that/other/libfoo.so`
diff --git a/compiling_building_c_cpp_notes.md b/compiling_building_c_cpp_notes.md
@@ -60,8 +60,10 @@ gcc -shared -Wl,-soname,libctest.so.1 -o libctest.so.1.0   *.o
 
 In Mac `.dylib` files are created like this:
 
-`clang -dynamiclib -o libtest.dylib file1.o file2.o -L/some/other/libraries/to/link/live/here`
+`clang -dynamiclib -o libtest.dylib file1.o file2.o -L/some/other/libraries/to/link/live/here -lname_of_library_without_lib_prefix`
 
 In Windows `.dll` files are created like this:
 
-`LINK.EXE /DLL /OUT:MYLIB.DLL FILE1.OBJ FILE2.OBJ FILE3OBJ`
+`LINK.EXE /DLL /OUT:MYLIB.DLL FILE1.OBJ FILE2.OBJ FILE3OBJ`
+
+## Linking to existing libraries
diff --git a/compiling_building_c_cpp_notes.md b/compiling_building_c_cpp_notes.md
@@ -59,6 +59,7 @@ gcc -shared -Wl,-soname,libctest.so.1 -o libctest.so.1.0   *.o
 `-shared` makes the object file created shareable by different executables.
 
 In Mac `.dylib` files are created like this:
+
 `clang -dynamiclib -o libtest.dylib file1.o file2.o -L/some/other/libraries/to/link/live/here`
 
 In Windows `.dll` files are created like this:

diff --git a/compiling_building_c_cpp_notes.md b/compiling_building_c_cpp_notes.md
@@ -50,7 +50,16 @@ Another cool thing about dynamic libraries, is that they can be linked during ru
 
 In Linux `.so` files are created like this:
 
-``
+```
+gcc -Wall -fPIC -c *.c
+gcc -shared -Wl,-soname,libctest.so.1 -o libctest.so.1.0   *.o
+```
+
+`-fPIC` means "Position Independent Code", a requirement for shared libraries in Linux.
+`-shared` makes the object file created shareable by different executables.
+
+In Mac `.dylib` files are created like this:
+`clang -dynamiclib -o libtest.dylib file1.o file2.o -L/some/other/libraries/to/link/live/here`
 
 In Windows `.dll` files are created like this:
 

diff --git a/compiling_building_c_cpp_notes.md b/compiling_building_c_cpp_notes.md
@@ -38,4 +38,20 @@ When you have several `.o` files, you can put them together as a library, a stat
 
 `LIB.EXE /OUT:MYLIB.LIB FILE1.OBJ FILE2.OBJ FILE3.OBJ`
 
-The cool thing about `.a` libraries is that they're self contained, the problem is that you end up using more space to distribute them, and perhaps, some of the libraries that are inside the `.a` file.
+When you are creating an executable that needs to make use of a library, if you use these static libraries, the size of your executable will be the sum of all the object files statically linked by the executable. The code is right there along the executable, it's easier to distribute, but again, the size of the executable can be bigger than it needs to... why? because, sometimes, many of the `.o` files, or even the entire `.a` file you're linking against might be a standard library that many other programs need.
+
+## Shared Libraries (Dynamic Libraries)
+
+So ***shared*** or ***dynamic*** libraries were invented so that programs would be linked against them, but since they're "shared" they don't need to be part of the executable, your executable will look for symbols expected to exist on a library that will be loaded in a single portion of the operating system's memory, thus not just making the size of your executable as small as it needs to be, but you won't need to load the library for every process/program that needs its symbols.
+
+On Linux shared files exist under the `.so` (shared object) file extension, on Mac `.dylib` (dynamic library), and in Windows they're called `.dll` (dynamic link libraries)
+
+Another cool thing about dynamic libraries, is that they can be linked during runtime, not just compile time. An example of runtime dynamic libraries are browser plugins.
+
+In Linux `.so` files are created like this:
+
+``
+
+In Windows `.dll` files are created like this:
+
+`LINK.EXE /DLL /OUT:MYLIB.DLL FILE1.OBJ FILE2.OBJ FILE3OBJ`
diff --git a/compiling_building_c_cpp_notes.md b/compiling_building_c_cpp_notes.md
@@ -2,7 +2,7 @@
 by Angel Leon. March 17, 2015.
 
 ## Include Paths
-On the compilation phase, you will usually need to specify the different include paths so that the interfaces (.h, .hpp) can be found.
+On the compilation phase, you will usually need to specify the different include paths so that the interfaces (.h, .hpp) which define structs, classes, constans, and functions can be found.
 
 With `gcc` and `llvm` include paths are passed with `-I/path/to/includes`, you can pass as many `-I` as you need.
 

diff --git a/compiling_building_c_cpp_notes.md b/compiling_building_c_cpp_notes.md
@@ -1,4 +1,5 @@
 # Things to remember when compiling/linking C/C++ software
+by Angel Leon. March 17, 2015.
 
 ## Include Paths
 On the compilation phase, you will usually need to specify the different include paths so that the interfaces (.h, .hpp) can be found.

diff --git a/compiling_building_c_cpp_notes.md b/compiling_building_c_cpp_notes.md
@@ -27,7 +27,7 @@ You can create an `.o` file for a single or for many source files.
 
 When you have several `.o` files, you can put them together as a library, a static library. In Linux/Mac these static libraries are simply archive files, or `.a` files. In windows, static library files exist under the `.lib` extension. 
 
-They are created like this in Linux/Mac:
+**They are created like this in Linux/Mac:**
 
 `ar -cvq libctest.a ctest1.o ctest2.o ctest3.o`