Date: Wed, 20 Mar 2013 20:49:51 +0100 From: Dimitry Andric <dim@FreeBSD.org> To: deeptech71 <deeptech71@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: net/xmlrpc-c-devel port with GCC 4.8 Message-ID: <45FF4CDD-66C2-4AA5-8A8D-B39677A4D6B1@FreeBSD.org> In-Reply-To: <514A05FB.7020608@gmail.com> References: <514A05FB.7020608@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 20, 2013, at 19:54, deeptech71 <deeptech71@gmail.com> wrote: > /usr/local/lib/gcc48/include/c++/bits/locale_facets.h:869: undefined = reference to `std::ctype<char>::_M_widen_init() const' > [...] > /usr/local/lib/gcc48/include/c++/bits/stl_list.h:1550: undefined = reference to = `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'= > [...] >=20 > I worked around this by adding "/usr/local/lib/gcc48/libstdc++.so" to = the make-rule. Weird. Why does this work? Should it? The link step is erroneously pulling in /usr/lib/libstdc++.so by default. Since that is an older version of libstdc++, it does not contain the symbols you listed. As you saw, forcing the link stage to use gcc 4.8's version of libstdc++ at least produces an executable. However, there is very likely still a problem at runtime, because the resulting executable probably does not have the correct rpath entry. This is a general problem with the gcc ports: they should all pull in their own version(s) of libstdc++.so instead of using the default linker path. And possibly add rpath entries, to make sure the correct version of libstdc++.so is used at runtime.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45FF4CDD-66C2-4AA5-8A8D-B39677A4D6B1>