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

From: Petr Baudis <pasky@suse.cz>
Date: Jun 23, 2006, 12:39 UTC
Message-ID: <20060623123904.GL21864@pasky.or.cz>
In-Reply-To: <m1k678yt6m.fsf@ebiederm.dsl.xmission.com>

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...

Show 7 quoted lines

> 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.