Following these steps below will help to address most common build issues.
Application Security Testing: An Integral Part of DevOps
If you are working in such a place you probably won't get to create Makefiles on your own. There is a build team for that. Your auto generated version will include "do not modify below this line" disclaimer implying that there's not much to modify above the line either - all required libraries along with macros have already been specified.
Therefore all that is left to do after you finished coding is to run your Makefile. If you haven't modified any library, the linking should go smoothly. But what if you changed one? Suddenly your console is filled with all kind of errors â?? undefined or missing symbols among them. Following these steps below will help to address most common build issues.
-Linking with local libraries you or your colleagues have modified.
Say you modified a library fooLib in somedirectory/yourdirectory. In that case you need to change your Makefile so the linker picks your version of fooLib instead of a production version. You need to make sure that when you run your Makefile, somedirectory/yourdirectory shows up with -I switch and -L switch on the console's link line. -I switch specifies the location of header files and -L switch specifies the location of libraries. You can set -I and -L options either through environmental variables or with macros inside your Makefile. In any case those two switches must be prepended to "somedirectory/yourdirectory" on the link line for the build to succeed. You need as well to comment out any reference to fooLib other than your own in the Makefile.
-Including correct header files
If you only see "somedirectory/yourdirectory" with -L but not with -I switch on the link line, this means that the linker got header files from somewhere else - probably from a production repository. You'll get away with it if you modified fooLib source code but not any of its header files. Let's say you've changed one of the header files foo.h. Say you added one parameter to an existing function. Then without correct path to the header files (â??I directive), you will get link errors. The linker looks for your parameter in foo.h in some remote repository but it's not there.
- Order of libraries in the Makefile
Once I spent half of my Sunday trying to link my code with three libraries I've modified, let's call them fooLib1, fooLib2 and fooLib3. Inside the Makefile I commented out their references to default repository and included my "-I" and "-L" switches to all the three libraries. On their own the libraries happily compiled but my code wouldn't link. The link line looked perfect and still I was getting linking errors. My son who was trying to dislodge me from the laptop so he could play Minecraft observed that I was staring at the same page for 4 hours. The reason for the linker error it turned out was the incorrect order in which fooLib1, fooLib2 and fooLib3 were specified in the Makefile.
The order of the libraries appears counter-intuitive at first. First you specify the code that uses the library then the library itself. If the code in fooLib1 called a function from fooLib2, then fooLib1 must precede fooLib2 in the Makefile. Actually the order of the libraries listed in the original Makefile is a good indicator. You may change the location of the libraries but you must preserve the order.
After your changes are approved, the library code you've changed will eventually end up in your company's production repository. When that happens, you'll revert to the original Makefile and relink. There shouldn't be any more build issues after that.