# Things to remember when compiling/linking C/C++ software

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.

With gcc and llvm include paths are passed with -I/path/to/includes, you can pass as many -I as you need.

In Windows, cl.exe takes include paths with the following syntax:
/I"c:\path\to\includes\ you can also pass as many as you need.

Some software uses macro definition variables that should be passed during compile time to decide what code to include.

## Compilation flags

These compilation-time variables are passed using -D,
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.

## 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.

You can create an .o file for a single or for many source files.

## Static Library 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:

ar -cvq libctest.a ctest1.o ctest2.o ctest3.o

libctest.a will contain ctest1.o,ctest2.o and ctest2.o

They are created like this in 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.

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:

gcc -Wall -fPIC -c *.c
gcc -shared -Wl,-soname,libctest.so.1 -o libctest.so.1.0   *.o

• -Wall enables all warnings.
• -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.
• -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:

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:

LINK.EXE /DLL /OUT:MYLIB.DLL FILE1.OBJ FILE2.OBJ FILE3OBJ

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 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.

### 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

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.

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 😉

Find all Undefined symbols

nm -u libMacOSXUtilsLeopard.jnilib
_CFRelease
_LSSharedFileListCopySnapshot
_LSSharedFileListCreate
_LSSharedFileListInsertItemURL
_LSSharedFileListItemRemove
_LSSharedFileListItemResolve
_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  ### 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 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. 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 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. # # 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) 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. In Windows, cl.exe takes include paths with the following syntax: /I"c:\path\to\includes\ you can also pass as many as you need. Some software uses macro definition variables that should be passed during compile time to decide what code to include. ## Compilation flags These compilation-time variables are passed using -D, 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. ## 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. You can create an .o file for a single or for many source files. ## Static Library 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: ar -cvq libctest.a ctest1.o ctest2.o ctest3.o libctest.a will contain ctest1.o,ctest2.o and ctest2.o They are created like this in 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. 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: 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: 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: 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 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 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. ## 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. 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 😉 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
__objc_empty_cache
__objc_empty_vtable
_calloc
_class_getInstanceMethod
_class_getInstanceSize
_class_getInstanceVariable
_class_getIvarLayout


# [SOLVED] Gradle: How to increase the Java Compiler’s available Heap Memory

The documentation is not very clear on what all the available options are…
after much Googling and many different attempts finally figured out how to raise the maximum heap of the compiler from within the gradle.build script.

[pastacode lang=”java” manual=”apply%20plugin%3A%20%E2%80%98java%E2%80%99%0A%0AcompileJava%20%7B%0A%2F%2Fraise%20heap%0Aoptions.fork%20%3D%20%E2%80%98true%E2%80%99%0Aoptions.forkOptions.with%20%7B%0AmemoryMaximumSize%20%3D%20%E2%80%9C2048m%E2%80%9D%0A%7D%0A%7D” message=”” highlight=”” provider=”manual”/]

Update:
So I’ve noticed this works great on MacOSX, but it doesn’t work at all on Windows 8.

The solution to increasing the JVM’s Heap has been to remove those options from gradle.build script and add a new file on the same folder as where your gradle.build file lives called ‘gradle.properties’

These are the contents that made it work for both Mac and Windows (I’ve still not tested this on my linux box)

[pastacode lang=”java” manual=”org.gradle.jvmargs%3D-Xms256m%20-Xmx1024m” message=”” highlight=”” provider=”manual”/]

# How to actually build bitcoin on Mac OSX 10.9.1

First of all, if you have Macports, do yourself a favor and get rid of it.

Then make sure you have Homebrew installed and all the packages installed by it up to date.

1. Let’s install all the dependencies for Bitcoin hacking.

brew install autoconf automake berkeley-db4 boost miniupnpc openssl pkg-config protobuf qt libtool

2. Make sure you have the right OpenSSL version installed. Type the following on your terminal:

openssl version

you should see “OpenSSL 1.0.1f 6 Jan 2014.”

if you see an older version, do

brew update brew upgrade

OpenSSL should be upgraded, you may or may not have to issue a “brew link openssl” or even a “brew link --overwrite openssl” if it’s giving you trouble.

3. Now, let’s configure, and make. I strongly suggest you add the boost library path when configuring, otherwise you may get nasty “Undefined symbols for architecture x86_64” compilation errors. During the time I wrote this, homebrew had installed boost 1.55 in my system, and the boost lib path was /usr/local/Cellar/boost/1.55.0/lib so I invoked the following:

./configure --with-boost-libdir=/usr/local/Cellar/boost/1.55.0/lib

After that I just issued a

make

And I was done.

If you want to hack the bitcoin-qt client like me, head to src/qt/, there should be a bitcoin-qt executable there now.

Enjoy

# building cgminer from source on OSX

so you cloned the cgminer repo from github to build on your OSX machine and you get this bullshit error

\$ ./autogen.sh readlink: illegal option -- f usage: readlink [-n] [file ...] usage: dirname path touch: /ltmain.sh: Permission denied Use of chdir('') or chdir(undef) as chdir() is deprecated at /usr/local/bin/autoreconf line 670. Configuring... ./autogen.sh: line 10: /configure: No such file or directory 

readlink works differently in OSX and the current version of the autogen.sh script seems like it wasn’t tested on OSX (wonder why didn’t they use a simple bs_dir=pwd, the answer is probably canonical paths and what not).

To keep moving along, open the autogen.sh script and just change the value of the bs_dir variable to the full real path of where you have cloned the cgminer source code.

then execute your autogen script, make sure to enable compilation flags for your ASIC hardware, in my case I remember seeing ‘icarus’ on a binary build of cgminer I tried before, so I did

./autogen.sh --enable-icarus

you might want to enable all of them if you’re not sure what hardware you have or you will have in the future as you may not like the joys of building software (check out the the README for all the –enable-xxx options available)

If you’re getting errors on your configuration script due to missing dependencies, I strongly recommend you use Homebrew to install these packages (if you are using Macports or Fink, I strongly suggest you completely remove that crap from your computer and go 100% with brew, it works really well if you’re building a lot of code on a regular basis):

brew install autoconf automake autoreconf libtool openssl curses curl

brew, at the point of this writing didn’t have libcurl, so that one you will have to download, ./configure, make and sudo make install yourself from here http://curl.haxx.se/download.html (I used version 7.34 when I did it)

after that the autogen script should work, and then you should be just one ‘make’ away from your goal.

# Parque Central – Base Jumping from the Twin Towers in Caracas

During the summer of 2008, a couple of Venezuelan Parachute Base Jumpers (Carlos and Pedro) got together with Propela Productions to make a short film about an extreme dream of the jumpers, Jump from the Base of one of the Twin Towers of Parque Central in Caracas, Venezuela.

They format published in YouTube was divided in 2 parts, this is part 2. You can see Part One here.

Very nicely planned, produced, executed and edited (to my taste).

Let’s keep an eye on these guys, anybody knows if they have a site? I just got this from Nosgoth