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
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

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 ;-).

- Raw text -