delorie.com/archives/browse.cgi | search |
X-Authentication-Warning: | delorie.com: mailnull set sender to djgpp-workers-bounces using -f |
From: | Martin Stromberg <Martin DOT Stromberg AT epl DOT ericsson DOT se> |
Message-Id: | <200112021239.NAA08303@lws256.lu.erisoft.se> |
Subject: | Re: Building a profiled version of libc |
To: | djgpp-workers AT delorie DOT com |
Date: | Sun, 2 Dec 2001 13:39:24 +0100 (MET) |
In-Reply-To: | <3C0A1ABF.C95CCFA2@phekda.freeserve.co.uk> from "Richard Dawe" at Dec 02, 2001 12:12:47 PM |
X-Mailer: | ELM [version 2.5 PL3] |
MIME-Version: | 1.0 |
Reply-To: | djgpp-workers AT delorie DOT com |
Errors-To: | nobody AT delorie DOT com |
X-Mailing-List: | djgpp-workers AT delorie DOT com |
X-Unsubscribes-To: | listserv AT delorie DOT com |
> No, the patches allow you to build a profiled version of libc by tweaking > the options in src/gcc.opt. Previously libc compiled with profiling would > cause programs compiled against it to crash. The reason was that the > profiling support was compiled with profiling, which lead to unlimited > recursion in the profiling support code. > > The build system would need more invasive modifications to support > building two different sets of objects for the two libraries. We could > then fix the problem with libemu cleanly - link it against normal libc. Ok. What if we have gcc-profile.opt and gcc-noprofile.opt and let "make" do "cp gcc-profile.opt gcc.opt; make clean; make; cp gcc-noprofile.opt gcc.opt; make clean; make;"? Or add a target "profile" that builds a profiling libc or something like that? Right, MartinS
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |