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

Dear diary, on Fri, Jun 23, 2006 at 10:57:50AM CEST, I got a letter
where Junio C Hamano [off-list ref] said that...

Petr Baudis [off-list ref] writes:

quoted

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" [off-list ref] 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.