hi, Doug. The changes looked fine for SL-target. By the way, Why does x86 compile libinstr using GNU? Why not using opencc?
2010/8/13 Jian-Xin Lai <laij...@gmail.com> > In libinstr2.patch, there are some changes in SL-specified code, can > guys in SL review that change? > > 2010/8/11 Gilmore, Doug <doug.gilm...@amd.com>: > > Sorry I should have sent these patches sooner for review. > > > > > > > > Here are two patches to address this issue, along with some > > > > cleanup of the configuration of library builds and the addition of > > > > a convenience install rule that can be used during development. > > > > > > > > libinstr2.patch: > > > > - Fixes the debug build problem of the instrumentation library. > > > > > > > > configure.patch: > > > > - Added configure option: > > > > --with-build-lib-optimize=DEFAULT|DEBUG > > > > > > > > Note that --with-build-optimize=DEBUG will now only enable debugging > > > > in the compiler build. > > > > > > > > The --help comment for --with-build-lib-optimize, notes > > > > that --with-build-lib-optimize=DEBUG is not well tested. > > > > > > > > Note that with this change compiler/library builds configured with > > > > --with-build-lib-optimize=DEBUG can now be used for performance > > > > testing. > > > > - Breakup install rule into two rules, one for the GNU > > > > FEs (slow) and one for the compiler (fast), thus > > > > rebuilding and installing a component of the compiler > > > > can done via: > > > > > > > > make && make -C ../../.. install_compiler > > > > > > > > instead of: > > > > > > > > make && make -C ../../.. install > > > > > > > > Doug > > > > > > > > From: Gautam Chakrabarti [mailto:gautam.c...@yahoo.com] > > Sent: Wednesday, August 11, 2010 8:59 AM > > To: s...@cup.hp.com; Sun Chan > > Cc: Open64-devel > > Subject: Re: [Open64-devel] error when linking libinstr,a > > > > > > > > As Steve mentioned, libinstr2 is C++ code, but it does not use STL. > libinstr > > still contains the original code before PathScale's change (as Sun said) > and > > uses STL -- probably the old code needs to be removed. libinstr2 > is supposed > > to not link with libstdc++, and should be built with -fno-exceptions and > > other flags as Steve already said. The debug build is broken. > > > > > > > > Gautam > > > > > > > > > > > > ________________________________ > > > > From: Steve Ellcey <s...@cup.hp.com> > > To: Sun Chan <sun.c...@gmail.com> > > Cc: Open64-devel <Open64-devel@lists.sourceforge.net> > > Sent: Wed, August 11, 2010 8:40:16 AM > > Subject: Re: [Open64-devel] error when linking libinstr,a > > > > 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 > > > > > > > > > ------------------------------------------------------------------------------ > > 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 > > > > > > > > -- > Regards, > Lai Jian-Xin > > > ------------------------------------------------------------------------------ > 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 > -- Best Regards. Shen Ruifen tel: 010-51266989-226
------------------------------------------------------------------------------ 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
