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

From: Jakub Narebski <jnareb@gmail.com>
Date: Jun 23, 2006, 06:03 UTC
Message-ID: <e7g079$8qt$1@sea.gmane.org>
In-Reply-To: <7vk678fpqy.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano wrote:

Show 20 quoted lines

> Petr Baudis <pasky@suse.cz> 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