Link error adding library built with Clang to iOS app built with GCC

Question

I'm trying to add the Dropbox Sync API (v1.1.2) to an iOS app built with Marmalade (v6.3). I'm getting the following link error:

Undefined symbols for architecture armv7:
"___udivmodsi4", referenced from:
_sqlite3BitvecSet in libDropbox.a(sqlite3.o)
_sqlite3BitvecClear in libDropbox.a(sqlite3.o)
_sqlite3BitvecTest in libDropbox.a(sqlite3.o)
ld: symbol(s) not found for architecture armv7

Googling for pertinent parts of that error message finds a number of users of a certain SQLCipher library experiencing the same issue, and suggestions that the problem is caused by an inconsistency of the compilers used to build that library and the various projects using it.

As the build system for our project is set up by the Marmalade toolset, changing the compiler (currently a version of GCC 4.4 supplied by Marmalade, I believe) is not an option, I think.

Can anyone tell me more precisely what is going wrong? Are there any other workarounds to this problem?

Answer 1

The other answer is correct. However, for this specific problem (if these are the only linker errors you are getting) I see two workarounds:

1. Grab the source from sqlite3 that includes sqlite3BitvecSet and compile those functions in your own project to override the library. They will pick up whatever divmod support is offered by your own compiler.
2. Implement your own udivmodsi4. You don't have to implement bitwise division (although you can go get that basic C implementation from the GCC source). You just have to implement it in native operations and let your compiler call whatever internal support it needs.

This is untested, but should give you the basic idea. You may need more underscores on the name to match the behavior/naming of the other build environment:

unsigned long
udivmodsi4(unsigned long num, unsigned long den, int modwanted)
{
    if (modwanted)
        return num % den;
    else
        return num / den;
}

Answer 2

On processors like ARM, with relatively simple instruction sets, some more complex operations are mapped on to function calls rather sequences of instructions. When you link using the "correct" compiler, the implementations of these are pulled in and it works! You on't normally see it.

The obvious solution here would be to use marmalade to compile the dropbox library, then it will use a compatible compiler.

The question then, I guess, is whether there is a reason you are not doing this to start with? Current Marmalade compilers don't support ARC. I guess that would be a reason not to compile under ARC.