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

Petr Baudis [off-list ref] writes:

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.

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

On 6/23/06, Jakub Narebski [off-list ref] wrote:

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

Haven't looked at Git.pm. But I have written receive-pack in perl. It
may have some useful functions for Git.pm

Dear diary, on Fri, Jun 23, 2006 at 08:03:23AM CEST, I got a letter
where Jakub Narebski [off-list ref] said that...

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

I fiercely want to avoid this if there is any other possible way to go
about it - this is a path to hell of massive code duplication and
additional work, as the number of routines will grow. If it is question
of spending many developer-hours uselessly duplicating code in a way
that'll be much slower than possible anyway OR building with -fPIC... ;-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.

Dnia piątek 23. czerwca 2006 14:45, napisałeś:

Dear diary, on Fri, Jun 23, 2006 at 08:03:23AM CEST, I got a letter
where Jakub Narebski [off-list ref] said that...

quoted

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

I fiercely want to avoid this if there is any other possible way to go
about it - this is a path to hell of massive code duplication and
additional work, as the number of routines will grow. If it is question
of spending many developer-hours uselessly duplicating code in a way
that'll be much slower than possible anyway OR building with -fPIC... ;-)

I have thought about reimplementing only the parts which are in XS. In C
one would probably write

#if can_asm
 asm (...)
#else
 /* C code equivalent */
#endif

In addition to allowing use of Git.pm for people who cannot compile 
Git.xs, it would be helpful I guess in Git.pm development.

-- 
Jakub Narebski
Poland