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]
