Date: Wed, 14 Jun 2000 13:26:05 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
cc: djgpp AT delorie DOT com
Subject: Re: Using strip --strip-debug on libraries
In-Reply-To: <3946A07E.98F13651@phekda.freeserve.co.uk>
Message-ID: <Pine.SUN.3.91.1000614132547.29611G-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Tue, 13 Jun 2000, Richard Dawe wrote:

> > A more importtant question is: how did that library wind up with more
> > than a single copy of init.o in it?
> 
> BTW this is from building gmp - there are subdirectories called mp?, e.g.
> mpz, and some of these have a file called init.c, with functions like
> (IIRC) __mpz_init(). So, when you build the library, you end up with three
> files called init.o (from three directories), since the path information
> appears to be discarded. So, when the library is stripped of debug info,
> only one init.o survives, leading to unresolved symbols when you link
> against it.

Hmm, this looks like a bug, then.

Mark, do you have any ideas?  Should Rich report this to the binutils
mailing list?

> Solution:
> 
> find . -name '*.o' -exec strip --strip-debug '{}' ';'
> find . -name '*.o' -exec touch '{}' ';'
> 
> then remake library.

Or simply don't run `strip' on the library in the first place ;-).