• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Noob asks: Why the diff in symbol names between my dylib and a test executable?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Noob asks: Why the diff in symbol names between my dylib and a test executable?


  • Subject: Re: Noob asks: Why the diff in symbol names between my dylib and a test executable?
  • From: "Clark Cox" <email@hidden>
  • Date: Tue, 28 Oct 2008 19:13:28 -0700

The library was built using GCC's debug STL, and your executable was
not; the two are in different namespaces, and therefore generate
different. When using C++ in libraries, it is very important that
build-settings are as similar as possible between libraries and
clients thereof, as the binary interface for C++ is much more rigid
than with C or Objective-C.

On Tue, Oct 28, 2008 at 6:44 PM, Dan Caugherty <email@hidden> wrote:
> Hey all --
>
> I have a project with two targets: a dynamic library that uses the STL
> (and GCC 4.0 and Xcode v3.0), and a test executable for said library
> (because, to quote a capable software engineer, "unit testing is
> good"). For some reason, the signatures of some of my C++ methods as
> compiled in the library differ from those expected by the linker when
> I build an executable to test the library.
>
> This is the prototype for the method in question:
>
> class elements
> {
>  //..
>
>  elements::iterator
>  find(elements::iterator start, const std::string & eltstring) const;
>  //..
> };
>
> This is the output of "otool -Tv" when run against my library for the
> method in question:
>
> single module
> __ZNK8elements4findEN11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIP7elementN10__gnu_norm6vectorIS4_SaIS4_EEEEEN15__gnu_debug_def6vectorIS4_S8_EEEERKSs
>
> Using c++filt on this humongous string yields:
>
> elements::find(__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<element*,
> __gnu_norm::vector<element, std::allocator<element> > >,
> __gnu_debug_def::vector<element, std::allocator<element> > >,
> std::basic_string<char, std::char_traits<char>, std::allocator<char> >
> const&) const
>
> The output of the failing link attempt (with mangled symbols turned
> on) for the test executable reveals:
>
>  "__ZNK8elements4findEN9__gnu_cxx17__normal_iteratorIP7elementSt6vectorIS2_SaIS2_EEEERKSs",
> referenced from:
>
> And c++filt interprets this string as:
>
> elements::find(__gnu_cxx::__normal_iterator<element*,
> std::vector<element, std::allocator<element> > >,
> std::basic_string<char, std::char_traits<char>, std::allocator<char> >
> const&) const
>
> Clearly, a project and/or target setting is amiss somewhere; the
> library is being built with a debug flag set somewhere while the test
> executable is not. But which settings should I tweak?
>
> Thanks in advance,
> -- Dan Caugherty
>  _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list      (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>



--
Clark S. Cox III
email@hidden
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References: 
 >Noob asks: Why the diff in symbol names between my dylib and a test executable? (From: "Dan Caugherty" <email@hidden>)

  • Prev by Date: Noob asks: Why the diff in symbol names between my dylib and a test executable?
  • Next by Date: Re: application support x86_64 architecture issue
  • Previous by thread: Noob asks: Why the diff in symbol names between my dylib and a test executable?
  • Next by thread: Legacy nibs containing views served by new IB plug-in not recognized
  • Index(es):
    • Date
    • Thread