Re: Libtool (ld) problem in makefile. Is the GCC 4.0 distribution broken?
site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com User-agent: Thunderbird 1.5 (Macintosh/20051025) 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
These symbols are all defined in the g++-4.0 dynamic libstdc++. /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 -- Martin _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... [] 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.) [] 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 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. This email sent to site_archiver@lists.apple.com
participants (1)
-
Martin Costabel