Junio C Hamano wrote: > Petr Baudis <pasky@xxxxxxx> writes: > >>> 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 - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html