Re: [PATCH/RFC] Build a shared / renamed / "stable" version of the library?

> Build (and use) libgit.so instead of libgit.a.
> 
> --- 
> 
> I have written this nice Python extension that gives me fast access to
> git objects. Python extensions are built as shared libraries. Linking
> shared and non-shared objects into one library results in a couple of
> linker warnings on i386; other architectures are far less forgiving.
> 
> So the best choice I seem to have is to build a shared libgit.so.
> 
> Unfortunately, libgit doesn't have nice symbol names. I dunno how you
> all would feel about a big patch which renames absoutely every foo()
> function in libgit to be git_foo() instead (or one that #ifdef's them)...
> so I'm taking the easy way out, and use versioned symbols. That should
> prevent symbol name conflicts with other libraries.
> 
> I've had to redefine usage(), error() and die() to git_*(), because
> they're just too conflict-ish. "error" is even a weak symbol in libc. :-/
> 
> To summarize, the choices seem to be:
> - don't do anything => no script language extensions, need to fork off
>   a git program for absolutely everything. Bah.
> - build libgit.a with -fpic'd objects => doesn't work on all
>   architectures.
> - build libgit.shared.a and use that for building script language
>   extensions => works now, but may cause name conflicts down the road.
> - build a "normal" libgit.so => ditto on the name conflicts.
> - build a libgit.so with symbol versions => no name conflicts expected,
>   but works only with the GNU linker.
> - rename all library functions and globals => quite a bit of work,
>   and more typing down the road.
> - add "#define foo git_foo" to all library functions => ugly.
> 
> Opinions?