Mailing Lists: Apple Mailing Lists

Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Libtool (ld) problem in makefile. Is the GCC 4.0 distribution broken?



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:
http://lists.apple.com/mailman/options/darwin-dev/email@hidden

This email sent to email@hidden
References: 
 >Libtool (ld) problem in makefile. Is the GCC 4.0 distribution broken? (From: Paul Archibald <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.