On Wed, 2010-08-11 at 00:18 -0700, Sun Chan wrote: > this make no sense. Pathscale already changed the library to C > implementation. I believe the changes have been merged > Sun > > On Tue, Aug 10, 2010 at 11:38 PM, Jian-Xin Lai <laij...@gmail.com> wrote: > > The workaround is to link with -lstdc++. > > > > 2010/8/10 Hucheng Zhou <zhou.huch...@gmail.com>: > >> Hi: > >> When I tried to use fbo, there is an error when linking libinstr.a: > >> /home/zhc/open64-install//lib/gcc-lib/x86_64-open64-linux/4.2/libinstr.a(profile_interface.o):(.gnu.linkonce.d.DW.ref.__gxx_personality_v0+0x0): > >> undefined reference to `__gxx_personality_v0' > >> Thanks.
The x86 platform builds libinstr from the sources in osprey/instrumentation/libinstr2, and those are C++ sources. $ ls osprey/instrumentation/libinstr2/ Exported libinstr.vs profile_interface.h Makefile.gbase profile.cxx utils.h dump.cxx profile.h vector.h dump.h profile_aux.h hash_map.h profile_interface.cxx I don't know if anyone uses instrumentation/libinstr/ but those sources are in C++ too. There doesn't actually seem to be many diffs between these two directories. It looks like we have a local fix here to instrumentation/libinstr2/Makefile.gbase that hasn't been merged back yet. This fix sets CXXFLAGS when BUILD_OPTIMIZE is set to DEBUG in order to include -fno-exceptions when building in DEBUG mode. I believe the current sources will work now if you don't build this library in DEBUG mode. Steve Ellcey s...@cup.hp.com ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Open64-devel mailing list Open64-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/open64-devel
