From owner-cvs-user  Mon Mar 13 21:59:42 1995
Return-Path: cvs-user-owner
Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA01928 for cvs-user-outgoing; Mon, 13 Mar 1995 21:59:42 -0800
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id VAA01922; Mon, 13 Mar 1995 21:59:23 -0800
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id OAA10323; Tue, 14 Mar 1995 14:42:37 +1000
Date: Tue, 14 Mar 1995 14:42:37 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199503140442.OAA10323@godzilla.zeta.org.au>
To: phk@ref.tfs.com, rgrimes@gndrsh.aac.dev.com
Subject: Re: cvs commit: src/release/compat20 libgcc.so.261.0.uu
Cc: CVS-commiters@freefall.cdrom.com, cvs-user@freefall.cdrom.com,
        phk@freefall.cdrom.com, pst@shockwave.com
Sender: cvs-user-owner@freebsd.org
Precedence: bulk

>As to how this is to be provided, and what measures we have to take to 
>comply with the ($#^#&$%@&ing) GPL, is to be determined.  I will have no 
>problems checking out the source code for this, (cvs co -t RELEASE20) during
>the "make release" and include it in the "compat20" if that is the solution.

Just restore the previous libgcc Makefile and use it to create
libgcc.so.261.0 as before and change it to put less objects in libgcc.a 

This only works because libgcc*.c hasn't changed since before FreeBSD-2.0R.
If it had changed earlier then we would have already fought this battle.

I'm worried about the same problem for our own libraries.  I don't like
having to keep old library binaries that I can't rebuild.  If we were
less sloppy about incrementing the library version numbers then we
might have already fought battles over this.  There might be dozens of
versions and shared libraries occupying more space than they save in
executables.

Bruce