tree 6faa0f073d3b9adde864dd5cb041ddbd17c793ef
parent 95463b311df79a60e48ad6c6f49a16995e617ae9
author Adam Langley <agl@chromium.org> 1403633712 -0700
committer Adam Langley <agl@chromium.org> 1403633712 -0700

Include some build fixes for OS X.

Apart from the obvious little issues, this also works around a
(seeming) libtool/linker:

a.c defines a symbol:

int kFoo;

b.c uses it:

extern int kFoo;

int f() {
  return kFoo;
}

compile them:

$ gcc -c a.c
$ gcc -c b.c

and create a dummy main in order to run it, main.c:

int f();

int main() {
  return f();
}

this works as expected:

$ gcc main.c a.o b.o

but, if we make an archive:

$ ar q lib.a a.o b.o

and use that:

$ gcc main.c lib.a
Undefined symbols for architecture x86_64
  "_kFoo", referenced from:
    _f in lib.a(b.o)

(It doesn't matter what order the .o files are put into the .a)

Linux and Windows don't seem to have this problem.

nm on a.o shows that the symbol is of type "C", which is a "common symbol"[1].
Basically the linker will merge multiple common symbol definitions together.

If ones makes a.c read:

int kFoo = 0;

Then one gets a type "D" symbol - a "data section symbol" and everything works
just fine.

This might actually be a libtool bug instead of an ld bug: Looking at `xxd
lib.a | less`, the __.SYMDEF SORTED index at the beginning of the archive
doesn't contain an entry for kFoo unless initialised.

Change-Id: I4cdad9ba46e9919221c3cbd79637508959359427