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

[Petr Baudis <pasky@suse.cz>]

Dear diary, on Fri, Jun 23, 2006 at 10:57:50AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
> 
> > Also, is there any real problem with just using -fPIC?
> 
> Personally, not really, but I consider it a workaround having to
> compile with -fPIC (being able to compile with -fPIC is a
> feature).

Well, for the .xs you do need an .so and for that you apparently need
-fPIC on most architectures, so there's no way around it.

There's a patch to build libgit.so, would you take it as an excuse to
always compile with -fPIC? ;-)

> Doesn't it have performance implications to use -fPIC when you
> do not have to?

No idea here.

> By the way, you also need to adjust the testsuite so that it
> finds the Perl modules from freshly built tree before
> installing.  I think (but haven't checked yet) the stuff written
> in Python does that already, so you might want to mimic it.

It should be enough to -I../perl/blib/lib -I../perl/blib/arch/auto/Git.


Dear diary, on Fri, Jun 23, 2006 at 02:04:17PM CEST, I got a letter
where "Eric W. Biederman" <ebiederm@xmission.com> said that...
> The question is why are we building with a .so?

To make use of it in Git.pm - it can call libgit routines directly from
inside of Perl, but for that it needs to dynamically link libgit to the
Perl process on the fly (using dlopen()).

We _can_ avoid the .so, but that involved producing a new perl
executable with libgit statically linked to it, which is quite
impractical, so to say.

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