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.
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
