> From: ruifen Shen [mailto:shenr...@gmail.com]
> Sent: Friday, August 13, 2010 1:40 AM
> To: Jian-Xin Lai
> Cc: Gilmore, Doug; Open64-devel
> Subject: Re: [Open64-devel] error when linking libinstr,a (review requests)
>
> hi, Doug.
> The changes looked fine for SL-target.
Thanks!
>
> By the way, Why does x86 compile libinstr using GNU? Why not using opencc?
Actually Open64 is being used.
Note that for building a component of the compiler proper,
one can just type make in the compiler component build
directory.
This isn't the case for the libraries. The top level make
file overrides make variable settings on the command line
for the sub-make that builds the libraries for a particular
architecture:
$ make >& ob
$ grep "make -C" ob
make -C osprey/targdir/include
make -C osprey/cygnus
make -C osprey/targdir/libspin_4_2_0
...
make -C osprey-gcc-4.2.0
make -C osprey/targdir_lib default BUILD_TARGET=IA32 BUILD_COMPILER=SELF
BUILD_AREA=/scratch/dgilmore/sot-pp2/bo/osprey/targdir_lib MACHINE_TYPE=IA32
BUILD_ABI=I32BIT BUILD_ARCH=IA32 BUILD_HOST=IA32
make -C osprey/targdir_lib2 default BUILD_TARGET=X8664 BUILD_COMPILER=SELF
BUILD_AREA=/scratch/dgilmore/sot-pp2/bo/osprey/targdir_lib2 MACHINE_TYPE=X86_64
BUILD_ABI=I64BIT BUILD_ARCH=X8664 BUILD_HOST=IA32
make -C osprey-gcc-4.2.0/gcc \
...
make -C osprey-gcc-4.2.0/x86_64-redhat-linux/libstdc++-v3 \
$
Thus it is currently the case that when remaking a library
component, just typing make is not appropriate (this hasn't
changed with the introduction using configure).
At some point I think we should add make include files
generated by configure that are located in the generated
targdir_lib{,2} directories that contain the settings for
the make variables that are currently being set on the
command line that makes the libraries for a particular
architecture. Doing this would allow a component library
rebuild by just typing make in the build directory associated
with the library.
Doug
> 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
