Re: Libtool (ld) problem in makefile. Is the GCC 4.0 distribution broken?
Re: Libtool (ld) problem in makefile. Is the GCC 4.0 distribution broken?
- Subject: Re: Libtool (ld) problem in makefile. Is the GCC 4.0 distribution broken?
- From: Martin Costabel <email@hidden>
- Date: Thu, 15 Dec 2005 01:08:45 +0100
Paul Archibald wrote:
[]
$(TARGET): $(OBJECTS)
# this is the original libtool line
libtool -dynamic -M -single_module -o $@ $^ -lstdc++ -lc -lgcc > map
strip -x $@
Don't use libtool directly for linking, use g++.
[]
The result of making this is...
>>> begin output >>>
ld: for architecture ppc
ld: Undefined symbols:
__ZN9__gnu_cxx18__exchange_and_addEPVii
__ZNSs4_Rep20_S_empty_rep_storageE
__ZNSs4_Rep9_S_createEmmRKSaIcE
__ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base
__ZSt28_Rb_tree_rebalance_for_erasePSt18_Rb_tree_node_baseRS_
__ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_
__ZNSt15_List_node_base4hookEPS_
__ZNSt15_List_node_base6unhookEv
__ZSt18_Rb_tree_incrementPSt18_Rb_tree_node_base
libtool: internal link edit command failed
make: *** [../libJEngine.jnilib] Error 1
So, what is going on here? What are these symbols? Are they STL/template
symbols? (Do I care a lot? Not really, I just want this to work.)
These symbols are all defined in the g++-4.0 dynamic libstdc++.
[]
Where are these undefined symbols defined? Am I missing a library or a
header, and if so, which one and how would I find out? (Even if the
problem IS the GCC distribution, I am still curious how I would
determine where to find the definitions of undefined symbols. Metrowerks
supplies a "Find Library" facility which can be used to find symbols.
Does GCC have something like that?)
A simple recursive "grep" in /usr/lib shows where they are mentioned,
and with "nm" you can see where they are defined.
(One thing that helped a lot was to use the Disk Utility.app to repair
the file permissions on my drive. Before I did that (thanks to whoever
suggested that, I forget where I saw it), libtool choked on the
-llstdc++ -lc -lgcc section of the makefile, asserting that lstdc++ and
gcc were not found and could not be included. After fixing file
permissions, that error went away. I think everyone should run fix
permissions.)
Nothing could be further from the truth. Whoever gave you this advice
didn't know that repair permissions is actually broken on Tiger. What it
did for you was to make some symbolic links in /usr/lib that should only
be there if you chose gcc-3.3 as compiler and not if you selected
gcc-4.0. Two of these links are
/usr/lib/libstdc++.a -> gcc/darwin/default/libstdc++.a
/usr/lib/libgcc.a -> gcc/darwin/default/libgcc.a
and, in /usr/lib/gcc/darwin
default -> 3.3
All of these links disappear if you run "gcc_select 4.0" and they
reappear (correctly) if you run "gcc_select 3.3", but also (incorrectly)
if you run repair permissions.
These symlinks do, indeed, make the "-lstdc++ -lgcc" flags for
/usr/bin/libtool not choke, by linking to the static gcc-3.3 versions of
libstdc++ and libgcc. But in this case, not choking is a bug. What
should be linked in are the dynamic version of libstdc++ and the static
version of libgcc, both from gcc-4.0, both to be found in
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/, and both automatically
(without need of a -l flag) linked in if you use g++ for linking instead
of libtool.
--
Martin
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden