libiberty as a parameter

[Marc Espie]

On Wed, Feb 03, 1999 at 10:20:42PM -0700, Jeffrey A Law wrote:
>   > Okay, take this as the first step in that direction...
> I'm not sure taking this step *now* is a good idea.
Well, I can live with having to apply a small patch to my own version of egcs
anyways :)

>   > I can't invest the time into making the full multi-lib shebang. This is a
>   > bit similar with libstdc++.so not getting found when it is not ldconfig'ed as
>   > root, only more so, since the executables that depend on libiberty do get
>   > run during bootstrap.
> Err, how is it similar to the ldconfig problem?
Worse, in fact. Problem is for people who want to install egcs without being
root. When libstdc++ is dynamic, it will get linked with -L, but not found
without the proper -R mechanism. However, it isn't used anywhere within the
build process, so you can still live with a small specs adjustment after the
fact. On the other hand, libiberty is used for critical executables that
get used during stage 3. So if the dynamic linker can't find them, no more
automatic bootstrap. And hard-coding the path to the dynamic library is
something which is frowned upon, as far as the libstdc++ discussion
established...

> Aren't you actually introducing a ldconfig-like problem by linking against
> a shared libiberty.sl?
This is a problem I can live with when I am building my own system, as I have
much more control about where everything is, and when it gets built.
Basically, make build on OpenBSD starts by:
- installing current include files,
- rebuilding & installing all libraries,
- building the rest of the world.

> I'd also be interested in how you're going to manage to keep the various copies
> of libiberty straight after an install.  gdb, binutils, egcs, and other
> packages all include a similar, but subtly different version of libiberty
> due to different release schedules.

Easier for me than it is for you :)

First, most subtle libiberty changes are portability problems. They are hard
to deal with in the large scheme of things, as you want to be sure that it
won't break on any architecture. But I only have to make sure it works on
OpenBSD. There might be some tweaking involved, such as making sure autoconf
yields the right defines for the current libibert. Nothing major.
Second, libiberty is not a large piece of code, and it's relatively
self-contained. It's reasonably easy to hunt for differences, and performs
a few minor adjustments if needed.

Finally, I would say that the only part of libiberty which may be trouble
is the C++-demangler. But this is one area where I definitely want to synch
with egcs, if I want my system to perform well for C++. 

I would say there will be a few interface details, I'm prepared to cope with
that... 

OpenBSD has some other problems to take care of right now, which are quite
a bit harder to solve unfortunately (outdated assembler, full support for
threads library...)
-- 
	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'