[Pythonmac-SIG] No arbitrary precison math on Mac-tel say it ain't so!

[Daniel Lord]

On Apr 22, 2006, at 12:36, Alex Martelli wrote:
> It's not just gmpy, but anything that needs to be linked as - 
> bundle, whatever that means exactly.  The workings of ld are  
> slightly arcane -- I did already ask for advice from colleagues who  
> I thought SHOULD know; for example, Matt Austern, who besides  
> authoring "Generic programming and the STL" and shepherding library  
> standards for the next generation of C++, led the gcc 4 group at  
> Apple, focusing on many optimizations therefor... *he* easily  
> admits that linking on MacOSX (as soon as dylibs, bundles,  
> frameworks, and the interplay of their namespaces and constraints  
> enters the picture) is something he never fully fathomed (no real  
> need for him to delve into that, it appears).  autoconf and friends  
> are even scarier (to me, at least)...;-).

Yup. Just ran into it with pcre (see below). Building pcre for i386  
separately works, but trying the old ' -arch ppc -arch i386 ' CFLAGS  
trick is what appears to precipitate the failure.

	gcc -arch ppc -arch i386 -O2 -g -I. -Ipcre-6.6 -o .libs/pcretest  
pcretest.o  ./.libs/libpcre.dylib ./.libs/libpcreposix.dylib /Users/ 
daniello/Project/Python-Builds/pcre/.libs/libpcre.dylib
	/usr/bin/ld: for architecture ppc
	/usr/bin/ld: warning ./.libs/libpcre.dylib cputype (7, architecture  
i386) does not match cputype (18) for specified -arch flag: ppc (file  
not loaded)
	/usr/bin/ld: warning ./.libs/libpcreposix.dylib cputype (7,  
architecture i386) does not match cputype (18) for specified -arch  
flag: ppc (file not loaded)
	/usr/bin/ld: warning /Users/daniello/Project/Python-Builds/ 
pcre/.libs/libpcre.dylib cputype (7, architecture i386) does not  
match cputype (18) for specified -arch flag: ppc (file not loaded)
	/usr/bin/ld: Undefined symbols:
	_pcre_callout
	_pcre_compile
	_pcre_config
	_pcre_copy_substring
	_pcre_dfa_exec
	_pcre_exec
	_pcre_free
	_pcre_free_substring
	_pcre_free_substring_list
	_pcre_fullinfo
	_pcre_get_stringnumber
	_pcre_get_substring
	_pcre_get_substring_list
	_pcre_info
	_pcre_maketables
	_pcre_malloc
	_pcre_stack_free
	_pcre_stack_malloc
	_pcre_study
	_pcre_version
	collect2: ld returned 1 exit status
	lipo: can't open input file: /var/tmp//ccYAMG1B.out (No such file or  
directory)
	make: *** [pcretest] Error 1

So I did a little reading, and at least for my problem above the  
answer is in the man page for ld:

UNIVERSAL FILE SUPPORT
        The link editor  accepts  ``universal''  (multiple- 
architecture)  input
        files,  but  always  creates a ``thin'' (single- 
architecture), standard
        Mach-O output file.  The architecture is specified  using   
the  -arch
        arch_type option.  If this option is not used, ld(1) attempts  
to deter-
        mine the output architecture by examining the first object  
file encoun-
        tered  on the command line.  If it is a ``thin'' file, its  
architecture
        determines that of the output file.  If  the  first  input   
file  is  a
        ``universal''  file,  the  ``best''  architecture for the  
host is used.
        (See the explanation of the -arch option, below.)

        The compiler driver cc(1) handles  creating  universal   
executables  by
        calling  ld(1)  multiple  times and using lipo(1) to create a  
``univer-
        sal'' file from the results of the ld(1) executions.

So the answer, IMHO and I could be wrong since I am very new to this,  
is one of two choices:
1) use 'ld' to produce two separate builds and then use 'lipo' to  
weld them together as a 'FAT' dylib or
2) To use 'cc' to build the dylibs and it takes care of teh seprate  
building and 'lipo-ing'

Or maybe I have this wrong and the errros only seem the same and they  
are really dissimilar.