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 12:44:42 +0100 (MET)
From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender:	broeker AT acp3bf
To:	djgpp-workers AT delorie DOT com
cc:	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.1011202145038.9372B-100000@is>
Message-ID:	<Pine.LNX.4.10.10112031229310.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 Sun, 2 Dec 2001, Eli Zaretskii wrote:

> 
> On Sun, 2 Dec 2001, Richard Dawe wrote:
> 
> > Our specs file from gcc 3.0.2 just has:
> > 
> > *lib:
> > -lc
> 
> 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.  And, BTW, libc profiling of shared
libraries is disabled by Linux, too, just like we're about to do it for
DXEs: if -shared was specified, all -profile treatment is disabled by the
specs file.

We already do have a libc_p in djdev203.zip, IIRC. It's a dummy, but its
meaning seems to be exactly to pacify GCCs using the older FSF spec file
for DJGPP, which always used to require libc_p.

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.  Then in the specs,
we could have

	%{profile: -lc_p} -lc

This would pull in the dummy or the real libc_p.a, if that's been
installed. The following -lc would then be a placebo, as all open end
should have been fixed by libc_p.a already.

Or maybe we could just bluntly overwrite the 'specs' file with a new one
contained in djpro204.zip, couldn't we?  But then, the confusion this
would cause may not be worth it.

Some Linux distros use a slightly similar approach: their libc_p.so is not
a dummy, but a redirector: it automatically pulls in -lc, and does nothing
else.

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

- Raw text -