Re: GMP build on OSX

[Vincent Lefevre <vincent@vinc17.org>]

On 2007-01-26 17:03:16 +0100, Bill Allombert wrote:
> My personnal experience with ppc46 is that 32bit and 64bit libraries are
> not separated while they have conflicting API which make really hard to
> use them. Liniking a 32bit program with a 64bit library is fatal, and so
> is the converse.

You can't link a 32-bit program with a 64-bit library or the opposite
(if one tries to force to do that, one immediately gets an error). So,
there's no problem: the linker chooses the first library that matches
the architecture/ABI. The non-separation is not necessarily a problem
either due to fat binaries. For instance:

prunille:~> otool -fv /usr/lib/libSystem.B_profile.dylib
Fat headers
fat_magic FAT_MAGIC
nfat_arch 4
architecture ppc
    cputype CPU_TYPE_POWERPC
    cpusubtype CPU_SUBTYPE_POWERPC_ALL
    offset 4096
    size 8765788
    align 2^12 (4096)
architecture ppc64
    cputype CPU_TYPE_POWERPC64
    cpusubtype CPU_SUBTYPE_POWERPC64_ALL
    offset 8773632
    size 2163798
    align 2^12 (4096)
architecture i386
    cputype CPU_TYPE_I386
    cpusubtype CPU_SUBTYPE_I386_ALL
    offset 10940416
    size 7440384
    align 2^12 (4096)
architecture x86_64
    cputype CPU_TYPE_X86_64
    cpusubtype CPU_SUBTYPE_X86_64_ALL
    offset 18382848
    size 1890375
    align 2^12 (4096)

> Probably neither (directly). Blanking pages is the duty of the
> kernel and occurs when memory is requested. It is probably caused by
> the malloc library (normally part of the C library) . Maybe you
> could try alternative malloc libraries or alternative OS.

Page-zeroing should be done by the kernel for obvious security reasons.
This means that whatever C library is used, pages will be zeroed. So,
changing the malloc library probably won't have any effect, unless the
default library does reads/writes or something else to make sure that
the memory is really allocated (and not just address space like under
Linux). But I don't know what the policy is under Mac OS X and I've
never done any test about that.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)