This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: libiberty as a parameter
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'