Dear diary, on Fri, Jun 23, 2006 at 10:57:50AM CEST, I got a letter where Junio C Hamano <junkio@xxxxxxx> said that... > Petr Baudis <pasky@xxxxxxx> 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@xxxxxxxxxxxx> 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. - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html