lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: [KinoSearch] [Lucy] Re: [kinosearch-commits] r5736 - trunk/perl/buildlib/KinoSearch
Date Sun, 24 Jan 2010 04:02:03 GMT
On Sat, Jan 23, 2010 at 08:58:07PM -0600, Peter Karman wrote:
> yes, leaving the flag off is fine. 

OK, good.

I broke PowerPC builds by adding -march=i486, though.  Natch.

So we're not done yet.

> The only time I've needed it was on a 32-bit CentOS Linux system, and then I
> just set CFLAGS myself.

Same here.  A quick test on a Debian Etch system seems to indicate that it's
not necessary there.  However, when I was researching this, I saw on the gcc
list that the default target is i386, which many people think is whack.

I think we could solve this for any one machine by adding -march=native, but
that would mess up the packagers.

OK, what about your suggestion of scanning cppsymbols? On my custom-compiled
vanilla debugging Perl on CentOS 5.2, I see lots of "i386".  So, we could try
this hack: if it says it's i386, tell it "Haha nice try -- use the i486
instruction set at least."

I don't know to what extent we can trust $Config{cppsymbols}, though.  The
output below from my PowerPC Mac Mini seems highly suspect.

Screw it.  I'm giving up.

The only time that atomic intrinsics get used right now are when adding new
classes to VTable_registry, which is a LockFreeRegistry.  That happens
infrequently enough that performance is not a concern and we can fall back to
pthread mutexes on systems where atomics are not made available via system

Marvin Humphrey

yogi:perl marvin$ perl -MConfig -le 'print join("\n", split / /, $Config{cppsymbols})'

View raw message