[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc-patches
Subject:    Re: libiberty as a parameter
From:       Marc Espie <Marc.Espie () liafa ! jussieu ! fr>
Date:       1999-01-31 21:10:52
[Download RAW message or body]

On Sun, Jan 31, 1999 at 12:24:15PM -0800, Richard Henderson wrote:
> On Sun, Jan 31, 1999 at 04:58:46PM +0100, Marc Espie wrote:
> > In a less abstract way, OpenBSD does have a dynamic library flavor of
> > libiberty already installed when gcc/egcs gets built. So specifying
> > LIBIBERTY=-liberty   along is enough to pick it up.
> 
> The only problem is is that libiberty is not unchanging.  Are
> we then supposed to detect when the installed libiberty doesn't
> contain some recently added entry point?

Nope, that's my turf. 

When I continue maintaining egcs for OpenBSD, I'm supposed to know what's
going on, and keep things in synch (which I do). That LIBIBERTY=
just makes things easier from my side.

The casual user who's using snapshots/ releases will just make bootstrap as 
usual.  It can be construed as a first step in the direction of making
libiberty available as a dynamic library, if someone wants to.

Assuming we want at some point to actually have a dynamic libiberty available,
heck, that's one major/minor version numbers are for. The other possibility
would be to make the same arrangements Fortran folks already have, and to
include a version number in libiberty, so that a small configure test can
check whether the pre-existing libiberty is enough, or not...

Actually, I'm thinking more along the way of a bootstrap situation, where the
last bootstrap stage (or make install ?) could install a dynamic libiberty.so,
then make use of that to link all the relevant executables to yield a smaller
footprint.

-- 
	Marc Espie		
|anime, sf, juggling, unicycle, acrobatics, comics...
|AmigaOS, OpenBSD, C++, perl, Icon, PostScript...
| `real programmers don't die, they just get out of beta'

[prev in list] [next in list] [prev in thread] [next in thread]