Re: [OT] On `ad hominem' - OS X users

[A complimentary Cc of this posting was sent to
Sherm Pendley
<spamtrap@xxxxxxxxxxx>], who wrote in article <m1wsh38q14.fsf@xxxxxxxxxxx>:
Okay, here's the deal.

A lot of thanks...

But GP/Pari uses assembler by default, and chooses which assembler to
use at config time. Even if one specifies the architecture directly,
one can still only build for a single architecture at a time. But, as
I said, Mac OS X's Perl wants to build them all at once... The result
on my Intel Mac is x86 mnemonics being passed to the PPC assembler,
which naturally doesn't know what to do with them. I haven't tested
it, but presumably the reverse would be true when building on a PPC
Mac.

So the first question is: would

make realclean
perl Makefile.PL machine=none
etc

avoid this problem? Aha, I see that you tested it, and it works...

In theory, one could build the library twice; once natively, and once
cross-compiled. Then, a tool called "lipo" is used to "glue" the two
"skinny" libraries into one "fat" library. I didn't bother doing that,
for two reasons. First, the "perl Makefile.PL machine=none" recipe for
producing a C-only library works, and passes its tests on my machine.
Second, since I'm not a math geek, the C-only library that's produced
that way is good enough for me.

This question is orthogonal to geekiness: the C-only build is
functionally identical, only slower... So it is related more to how
much money you spent on your CPU...

For what it's worth, libffi works around these issues by building all
of its assembler files regardless of what architecture it's being
built on or for, and uses #ifdef macros to conditionally compile only
the correct code. Thus, the decision is made at compile time rather
than config time, and it's made correctly for each of the multiple
compile passes that are made to produce a "fat" binary.

I will try to think about this...

BTW: how easy is it to remove multi-arch support from the compiler flags?

Thanks again,
Ilya
.