X-Authentication-Warning:	delorie.com: mailnull set sender to djgpp-workers-bounces using -f
X-Authentication-Warning:	acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date:	Mon, 3 Dec 2001 17:17:30 +0100 (MET)
From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender:	broeker AT acp3bf
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc:	djgpp-workers AT delorie DOT com, Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
Subject:	Re: Building a profiled version of libc
In-Reply-To:	<Pine.SUN.3.91.1011203170523.18561B-100000@is>
Message-ID:	<Pine.LNX.4.10.10112031656530.8155-100000@acp3bf>
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

On Mon, 3 Dec 2001, Eli Zaretskii wrote:

> On Mon, 3 Dec 2001, Hans-Bernhard Broeker wrote:

> > > We cannot update specs until and unless we distribute libc_p.a as part of 
> > > djdev.  If we update specs now, users will be unable to link with -pg, 
> > > since GCC will complain about a missing libc_p.
> > 
> > Not quite. Note that the linux spec reads  
> > 
> > 	... %{profile:-lc_p} %{!profile:-lc}
> > 
> > This means -lc_p only gets called if you link with "-profile", but not
> > with "-pg".  "-pg" only influences the choice of crt1.o startup file.  So
> > "-profile" means more than "-pg": it means you want to profile libc
> > itself, too, not just your own code.
> 
> Yes, but how does this contradict what I said above?  

It does, as long as you read as "update specs" as saying "copy that Linux
snipped cited in the other mail to the DJGPP version of the specs file".  
That would keep -pg working as it always did.  Only -profile would fail if
no libc_p.a was to be found there.

> > We already do have a libc_p in djdev203.zip, IIRC.
> 
> No, you are mistaken.  We have a dummy libpc.a, for compatibility with 
> vintage v1.x Makefile's, but that's a different story.

Must be an old memory, then, maybe from V1.x times.  I'm still quite sure
I did see a libc_p.a, in some version version of DJGPP.  But then, that
may even have been the real thing, not a dummy.

> > A similar trick may still work: provide a dummy libc_p.a in djdev204,
> > and the real one in djpro204 or whatever we call it.
> 
> Why bother?  

Because we probably should avoid end users having to edit spec files.  At
almost all costs.  And overriding the specs file by a djpro204
installation sounds like a FAQ or worse waiting to happen. So a single
specs file but two copies of libc_p.a might be a way out of that.

> We support this today, without any changes and without any dummy
> libraries.

Do we? Of course, the knowledgeable user could just remember to manually
put -lc_p at the end of his link line.  But that's not quite the same as
having -pg do what some might rightfully expect it to. Quoting the
gprof docs, node "Implementation":

--- quote ---
   Number-of-calls information for library routines is collected by
using a special version of the C library.  The programs in it are the
same as in the usual C library, but they were compiled with `-pg'.  If
you link your program with `gcc ... -pg', it automatically uses the
profiling version of the library.
--- ends ----

I.e. DJGPP does not behave as the combined GCC and GPROF docs say it does.
Neither do many current Linux distros, for that matter: the "-profile"
switch implemented by that quoted specs line is completely undocumented,
as far as I'm aware of.

-- 
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -