A common set of linkage failures looks something like this:
Undefined first referenced symbol in file rtxCtxtSetMemHeap /opt/asn1c-v613/c/libgcc3/libasn1ber.a(obj.o) rtxFileReadBinary /opt/asn1c-v613/c/libgcc3/libasn1ber.a(rtb.o)
The two symbols rtxCtxtSetMemHeap and rtxReadFileBinary are defined in our common runtime library. Users always report these failures with the point that they are, in fact, linking against the common runtime, like this:
gcc -o executable -L/opt/asn1c-v613/c -lasn1rt -lasn1ber
The failure in this case occurs because the link order is incorrect. Link order in gcc is significant:
A library which calls an external function defined in another library should appear before the library containing the function.
In this case, we would want to link the application as follows:
gcc -o executable -L/opt/asn1c-v613/c -lasn1ber -lasn1rt
It is not uncommon for programs that manage makefiles (like Eclipse, for example) to improperly link our libraries, so one of the first places to look is the makefile generated by the IDE.