On Oct 29, 2012, at 1:47 PM, Jonathan Wakely wrote: > It compiles fine with gcc if you put it in a file that ends in .cc or > .C or .cpp or any of the other extensions that tell gcc to run the > cc1plus compiler. Please read > http://gcc.gnu.org/onlinedocs/gcc/Invoking-G_002b_002b.html
I didn't see this before... but I'm still not clear why the distinction is important to you. cc1plus is needed. So, gcc can call cc1plus. What can't I use the term "g++" for that path? Isn't that how people think of it? How is the fact that gcc can call cc1plus really significantly important? We all know that gcc and g++ are just front ends. Also, in my original implementation, the new code does get put into both libsupc++ and libstdc++. It appeared to me that libsupc++ is a proper subset of libstdc++. In fact, this link is where I got that idea from: http://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.what_is_libsupcxx Note also that __cxa_guard_* is in the libsupc++ and libstdc++ libraries as well (and not libgcc). Here is the nm output of the libraries after my additions: > nm -Bx libsupc++.a | egrep '__cxa_atexit|__cxa_finalize|__cxa_guard' > 0x000001a8 T .__cxa_guard_abort > 0x000001a8 t .__cxa_guard_abort > 0x000000f0 T .__cxa_guard_acquire > 0x000000f0 t .__cxa_guard_acquire > 0x000001e4 T .__cxa_guard_release > 0x000001e4 t .__cxa_guard_release > 0x00000284 D __cxa_guard_abort > 0x00000284 d __cxa_guard_abort > 0x00000278 D __cxa_guard_acquire > 0x00000278 d __cxa_guard_acquire > 0x00000290 D __cxa_guard_release > 0x00000290 d __cxa_guard_release > 0x00000278 T .__cxa_atexit > 0x00000278 t .__cxa_atexit > 0x00000318 D __cxa_atexit > 0x00000318 d __cxa_atexit > 0x00000080 T .__cxa_finalize > 0x00000080 t .__cxa_finalize > 0x000001fc D __cxa_finalize > 0x000001fc d __cxa_finalize > nm -Bx libstdc++.a | egrep '__cxa_atexit|__cxa_finalize|__cxa_guard' > 0x1009d630 T .__cxa_atexit > 0x1009d630 t .__cxa_atexit > 0x100a9d34 T .__cxa_atexit > 0x100a9d34 t .__cxa_atexit > 0x1009ca3c T .__cxa_finalize > 0x1009ca3c t .__cxa_finalize > 0x1009cbfc T .__cxa_finalize > 0x1009cbfc t .__cxa_finalize > 0x100ccb8c T .__cxa_guard_abort > 0x100ccb8c t .__cxa_guard_abort > 0x100ccbc8 T .__cxa_guard_abort > 0x100ccbc8 t .__cxa_guard_abort > 0x1000d170 T .__cxa_guard_acquire > 0x1000d170 t .__cxa_guard_acquire > 0x1009d9ac T .__cxa_guard_acquire > 0x1009d9ac t .__cxa_guard_acquire > 0x1000d428 T .__cxa_guard_release > 0x1000d428 t .__cxa_guard_release > 0x1009d9fc T .__cxa_guard_release > 0x1009d9fc t .__cxa_guard_release > 0x2002886c D __cxa_atexit > 0x2002886c d __cxa_atexit > 0x2002e650 d __cxa_atexit > 0x20027354 D __cxa_finalize > 0x20027354 d __cxa_finalize > 0x2002dbe4 d __cxa_finalize > 0x2002d270 D __cxa_guard_abort > 0x2002d270 d __cxa_guard_abort > 0x20030600 d __cxa_guard_abort > 0x2002748c D __cxa_guard_acquire > 0x2002748c d __cxa_guard_acquire > 0x2002dccc d __cxa_guard_acquire > 0x200274a4 D __cxa_guard_release > 0x200274a4 d __cxa_guard_release > 0x2002dcd4 d __cxa_guard_release As far as the code, yes... the base code in glibc is C code but it called locking functions that was glibc specific. Since it appeared that I was going to add it to libsupc++ (I guess you prefer that name), I used the locking that is uses. Here is my comment at the top of the file. > /* > * Notes: This code essentially came from glibc version 2.16.0. It is > * "C" code there. I stole mutex_wrapper from guard.cc. > */ Perry
