Add parlib-compat.c for weak symbols with parlib
authorKevin Klues <klueska@cs.berkeley.edu>
Mon, 9 Nov 2015 22:56:26 +0000 (14:56 -0800)
committerBarret Rhoden <brho@cs.berkeley.edu>
Mon, 16 Nov 2015 23:15:03 +0000 (15:15 -0800)
commit0440a91a5c6f14588c338926a8e5c1de088c8985
treec8c943f5798bb7ec80066b70aa0d24e17e175483
parent8577818aa87cdfa76d0e3b2d278bcdb9c71e71c6
Add parlib-compat.c for weak symbols with parlib

This commit requires a rebuild of glibc (XCC)

Historically, parlib and glibc have been 2 separate entities. In spirit,
however, they both serve to provide low level functionalitity required
by higher level libraries. In theory, all of the functionality we
provide in parlib could (and arguably should) eventually be pushed down
into the akaros port of glibc. However, for now, we have opted to keep
parlib and glibc separate to maintain a faster turn-around time with
building parlib vs. glibc.

Unfortunately, keeping parlib and glibc separate is not very clean when
it comes to building glibc. Glibc is designed to be the lowest level
library on the system, and as such, doesn't like it when it has
unresolved symbols from parlib at link time. Since all executables
eventually link with parlib, this is not a problem (in theory), but
glibc doesn't like it nonetheless, and we have problems building our
cross compiler if any parlib symbols are referenced inside our akaros
port of glibc.

To help with this, I've introduced a new file called parlib-compat.c,
to define weak symbols for any parlib symbol that needs to be accessed
internally by glibc. This way, the symbol will exist at the time libc is
linked (to get our cross compiler build to stop complaining), but those
symbols will be overridden by parlib.a in any final executable that
gets linked.

Unfortunately, this trick only works so long as we leave parlib as a
static library. If we ever decide to make parlib a .so, then we will
have to revisit this and use function pointers at runtime or something
similar. Maybe by then we will have pushed all of parlib's functionality
down into glibc, so the point will be moot anyway.

Signed-off-by: Kevin Klues <klueska@cs.berkeley.edu>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
tools/compilers/gcc-glibc/glibc-2.19-akaros/sysdeps/akaros/Makefile
tools/compilers/gcc-glibc/glibc-2.19-akaros/sysdeps/akaros/Versions
tools/compilers/gcc-glibc/glibc-2.19-akaros/sysdeps/akaros/parlib-compat.c [new file with mode: 0644]