On Sun, 17 Feb 2008, chromatic wrote: > On Sunday 17 February 2008 17:13:37 James E Keenan wrote: > > > > /usr/bin/ld: multiple definitions of symbol _Parrot_conv_i2_i > > > myops_ops.o definition of _Parrot_conv_i2_i in section (__TEXT,__text) > > > /usr/local/lib/libparrot.dylib(core_ops.o) definition of > > > _Parrot_conv_i2_i /usr/bin/ld: multiple definitions of symbol > > > _Parrot_conv_u2_i > > > myops_ops.o definition of _Parrot_conv_u2_i in section (__TEXT,__text) > > > /usr/local/lib/libparrot.dylib(core_ops.o) definition of > > > _Parrot_conv_u2_i collect2: ld returned 1 exit status > > > > This looks suspicious. > > Compiling with gcc and linking with g++ looks more suspicious to me. Is that > really how things work on Darwin? > > I'm fairly certain C and C++ have very different ABIs.
It should be fine. In general, some of the libraries to be linked with parrot are written in C (e.g. -lparrot itself, most system libraries, etc.) but others may have been written in C++ (e.g. icu). Using C++ as a linker seems the most robust way to deal with this situation. I'd expect in the future that more and more extensions will come to rely on C++ libraries, so this will become more of an issue in the future than it is now. The problem here looks relatively simple: The symbol _Parrot_conv_i2_i is defined in two places: myops_ops.o and /usr/local/lib/libparrot.dylib(core_ops.o) That '/usr/local/lib/libparrot.dylib' shouldn't be there. It's probably a remnant of an old installation. Uninstalling the old libparrot should fix this problem. This is also a good example of why parrot shouldn't be installed at present, and why I think attempts to make it easy to install (e.g via yum, macports, rpm, apt-get, etc.) are not a good idea at this time. -- Andy Dougherty [EMAIL PROTECTED]