Re: Building a library using as universal for 10.3.9 ppc from
Re: Building a library using as universal for 10.3.9 ppc from
- Subject: Re: Building a library using as universal for 10.3.9 ppc from
- From: Greg Guerin <email@hidden>
- Date: Sat, 22 Jul 2006 13:57:59 -0700
Brant Sears wrote:
> ..a list of name-mangled symbols...
Ref: <http://lists.apple.com/archives/xcode-users/2006/Jul/msg00624.html>
To find a name-unmangler, I did this:
apropos mangl
It kicked out c++filt, which I then applied as:
sort mangled.txt | uniq | c++filt >unmangled.txt
The result was this list:
- - - - -
__gnu_cxx::__exchange_and_add(int volatile*, int)
std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_Rep::_S_empty_rep_storage
std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&)
std::_List_node_base::hook(std::_List_node_base*)
std::_List_node_base::unhook()
std::basic_streambuf<char, std::char_traits<char> >::seekoff(long long, std::_Ios_Seekdir, std::_Ios_Openmode)
std::_Rb_tree_increment(std::_Rb_tree_node_base const*)
std::_Rb_tree_insert_and_rebalance(bool, std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::_Rb_tree_node_base&)
___cxa_atexit
_snprintf$LDBLStub
_sscanf$LDBLStub
- - - - -
If any of those are symbols your source is using, or is a symbol being
expanded by a macro, then the fault lies in the source.
If none of them occur in your source or the macro-expanded version of the
source, then my first guess is that GCC 3.3 isn't really being used to
compile your source.
My second guess is that GCC 3.3 is being used to compile, but the wrong
headers are being included, and they have some macros or other decl's that
can't be resolved, so are left dangling. Doing a preprocess pass piped to
a grep for the symbols at fault might show that. The idea is to search the
preprocessed but uncompiled source, to see if there are any source
references. Another possibility is applying 'nm' to the compiled but
unlinked object-files, to see if any of the unresolved symbols show up at
that point.
My third guess is that GCC 3.3 is being used, the correct headers are being
included, but the linkage phase isn't linking against the 10.3.9 SDK. You
might be able to find some clues about that by using 'otool -L' to see what
other libs are dylinked into yours, and comparing the versions of those
dependent libs against what the actual 10.3.9 libs are. That will make
more sense if you look at the output of 'otool -L' and note the "current
version" numbers of the referenced libs.
My last guess is that something even more subtly wrong is going on, and
you'd have to track down where those name-mangled symbols reside (i.e. in
which library, under which SDK), in order to get a clue of how they're
appearing in your compiled executable. The 'nm' command will list symbols
from a lib, and 'find' will traverse a subtree.
I have a feeling the solution will either be a simple "D'oh!"
forehead-slapper, or something so subtle it borders on being Evil.
-- GG
_______________________________________________
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