Re: [PATCH] Introduce Git.pm (v3)

Junio C Hamano wrote:

Petr Baudis [off-list ref] writes:

quoted

quoted

        cc  -shared -L/usr/local/lib Git.o  -o blib/arch/auto/Git/Git.so ../libgit.a        \
                   -lz -lcrypto     \

        /usr/bin/ld: ../libgit.a(exec_cmd.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
        ../libgit.a: could not read symbols: Bad value
        collect2: ld returned 1 exit status
        make[1]: *** [blib/arch/auto/Git/Git.so] Error 1

This is a real killer.  If we compile everything with -fPIC,
this goes away, but I do not think we want -fPIC for the core
level tools.  At least not until we are ready to do libgit.so.

Hmm, I didn't get that; I guess that's x86-64 specific. :/

So it seems.  Both RH machines I have access at kernel.org and
Debian machines I have locally exhibit that x86-32 is OK and
x86-64 is bad.  They all run libc-2.3.6 except RH x86-32 is at
libc-2.3.4.

Perhaps Git.pm should provide also generic, pure Perl (and slower)
fallback implementation (when for some reason we cannot compile XS).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git