• 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
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]

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


  • Subject: Noob asks: Why the diff in symbol names between my dylib and a test executable?
  • From: "Dan Caugherty" <email@hidden>
  • Date: Tue, 28 Oct 2008 21:44:21 -0400

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

  • Follow-Ups:
    • Re: Noob asks: Why the diff in symbol names between my dylib and a test executable?
      • From: "Clark Cox" <email@hidden>
  • Prev by Date: Re: Can't include objective c file in carbon project
  • Next by Date: Re: Noob asks: Why the diff in symbol names between my dylib and a test executable?
  • Previous by thread: Re: Custom Platforms for Xcode
  • Next by thread: Re: Noob asks: Why the diff in symbol names between my dylib and a test executable?
  • Index(es):
    • Date
    • Thread