I didn't hear back from Sun about this.

Other gatekeepers: is it OK if I commit configure.patch, it has been reviewed.

Regards,

Doug

From: Gilmore, Doug
Sent: Tuesday, September 21, 2010 12:48 PM
To: '[email protected]'
Subject: FW: [Open64-devel] error when linking libinstr,a (review requests)

Hi Sun,

Is it OK if I check in change in configure.patch?

I held off checking it in since there was the large change
in front of it (libinstr2.patch was actually included in that
change).

Steve reviewed the configure.patch change.

Sorry for the delay, I was out unexpectedly for a few weeks.

Doug

From: Gilmore, Doug
Sent: Wednesday, August 11, 2010 11:23 AM
To: Gautam Chakrabarti; [email protected]; Sun Chan
Cc: Open64-devel
Subject: RE: [Open64-devel] error when linking libinstr,a (review requests)

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:[email protected]]
Sent: Wednesday, August 11, 2010 8:59 AM
To: [email protected]; 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 <[email protected]>
To: Sun Chan <[email protected]>
Cc: Open64-devel <[email protected]>
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 
> <[email protected]<mailto:[email protected]>> wrote:
> > The workaround is to link with -lstdc++.
> >
> > 2010/8/10 Hucheng Zhou 
> > <[email protected]<mailto:[email protected]>>:
> >> 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
[email protected]<mailto:[email protected]>


------------------------------------------------------------------------------
This SF.net<http://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
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/open64-devel

Attachment: configure.patch
Description: configure.patch

Attachment: libinstr2.patch
Description: libinstr2.patch

------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
Open64-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/open64-devel

Reply via email to