"/usr/bin/objcopy" --set-section-flags .debug_str=contents, debug
just curious. Why do debug builds of boost on gcc use this? What does it mean? I'm just wondering. I've never seen it needed for any other build. g++ -g is all that I've ever seen used to build a debug version of anything. "/usr/bin/objcopy" --set-section-flags .debug_str=contents,debug
Neal Becker wrote:
Why do debug builds of boost on gcc use this? What does it mean? I'm just wondering. I've never seen it needed for any other build. g++ -g is all that I've ever seen used to build a debug version of anything.
"/usr/bin/objcopy" --set-section-flags .debug_str=contents,debug
See http://thread.gmane.org/gmane.comp.lib.boost.build/9680 for a discussion of the subject. Markus
Markus Schöpflin wrote:
Neal Becker wrote:
"/usr/bin/objcopy" --set-section-flags .debug_str=contents,debug
See http://thread.gmane.org/gmane.comp.lib.boost.build/9680 for a discussion of the subject.
Thanks for bringing this to our attention. I was unaware of objcopy and the reason for using it. Earlier this year, I tried to replace my Yacc parser with Spirit. One of its unwanted side effects was extremely long link times for a debug executable. The problem in ld with the zillion symbols created by templates explains those long times. Before starting to use objcopy myself, I tried to find out whether the ld bug has been fixed. I couldn't find anything in the binutils archives, so instead I retried linking my code with the Spirit parser (from 1.33.0). The long link time has disappeared, so I am providing anecdotal evidence that binutils-2.15.92.0.2-5 (Fedora Core 3) has fixed the ld bug. It would be nice to hear a definitive statement that the need for objcopy went away with binutils version whatever. If objcopy is only needed for older binutils, perhaps the gcc-tools option should be defined so that the default is for current binutils, which do not need objcopy. Eventually, fewer and fewer users will need that option to support older versions of binutils. Of course, documentation would be nice. I don't see any mention of --no-objcopy in tools/build/v1/gcc-tools.html (in the released 1.33.0). -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
Richard Hadsell wrote:
Before starting to use objcopy myself, I tried to find out whether the ld bug has been fixed. I couldn't find anything in the binutils archives, so instead I retried linking my code with the Spirit parser (from 1.33.0). The long link time has disappeared, so I am providing anecdotal evidence that binutils-2.15.92.0.2-5 (Fedora Core 3) has fixed the ld bug. It would be nice to hear a definitive statement that the need for objcopy went away with binutils version whatever.
It may take some digging through the binutils and gcc bug base to find when it was fixed. A query to the maintainers might be faster :-)
If objcopy is only needed for older binutils, perhaps the gcc-tools option should be defined so that the default is for current binutils, which do not need objcopy. Eventually, fewer and fewer users will need that option to support older versions of binutils.
Yes, we should do that for BBv2.
Of course, documentation would be nice. I don't see any mention of --no-objcopy in tools/build/v1/gcc-tools.html (in the released 1.33.0).
Hm, it's on lines 379-384 for me. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera wrote:
Hm, it's on lines 379-384 for me.
I guess it didn't make it into the release. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
Richard Hadsell wrote:
Rene Rivera wrote:
Hm, it's on lines 379-384 for me.
I guess it didn't make it into the release.
I was talking about the release. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera wrote:
Richard Hadsell wrote:
Rene Rivera wrote:
Hm, it's on lines 379-384 for me.
I guess it didn't make it into the release.
I was talking about the release.
My tools/build/v1/gcc-tools.html has only 132 lines. I got it from the tar.bz2 download. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
Richard Hadsell wrote:
My tools/build/v1/gcc-tools.html has only 132 lines. I got it from the tar.bz2 download.
Ah, silly me... I didn't notice the context :-( No, you are correct I was referring to the code, not the docs. I would bet that there's a bunch of stuff that's not documented. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
* Richard Hadsell (hadsell@blueskystudios.com) [20050815 22:41]:
(from 1.33.0). The long link time has disappeared, so I am providing anecdotal evidence that binutils-2.15.92.0.2-5 (Fedora Core 3) has fixed
I've been doing RPM packages for SUSE Linux since 1.30.2 (packages have been part of SUSE Linux since version 9.0) and have patched out the use of objcopy from day one. So binutils 2.14.90.0.5 already had this bug fixed. Philipp -- Philipp Thomas <pth AT suse.de> Research & Development SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuremberg, Germany
participants (5)
-
Markus Schöpflin -
Neal Becker -
Philipp Thomas -
Rene Rivera -
Richard Hadsell