On  6 Feb, David O'Brien wrote:
> On Wed, Feb 06, 2002 at 03:46:22PM -0500, Mikhail Teterin wrote:
>> > dynamically linked libiberty would be a nightmare.
>> > libbfd  and  libiberty  do  not   have  version  numbers,  are  not
>> > maintained  (i.e. there  is  no official  releases). every  project
>> > includes its own libiberty and imho an attempt to find least common
>> > denominator will fail
>> Well, they come to FreeBSD as part of the binutils, right?
> NO!

Is that a "NO!" as in "no, it does not come as part of the binutils", or

> Max told you  what a nightmare it  would be. He is  110% right.

Max only objected to using dynamic versions of this two libraries, BTW.

> PLEASE take  some advice from two  people that are experienced  in the
> issues.

I'd like to take any advice, but  it has to be founded. Plenty of pieces
of the FreeBSD project are "a  nightmare" -- including the binutils, and
the  compilers, and  the whole  Alpha  port, to  name  a few  -- if  the
postings  to this  mailing  lists  (including those  from  you) are  any
indication. Yet,  we (including  you) do them  anyway, because  they are
worth it (for whatever reasons).

I'm  trying to  persuade the  audience, that  installing the  libbfd and
libiberty  (which we  build anyway!)  into  /usr/lib is  also worth  the
trouble, because it will help add  new software through the ports system
-- like the  gcj-compiler, or different versions of GCC,  etc. (With all
available targets enabled, preferably.)

I mean, I can add arm-aout or arm-elf binutils to the system through the
devel ports,  or mingw --  all with their own  libbfd, but I  don't have
access to  the native version,  which is built as  part of the  base OS,
just never installed? Is not this a bit ridiculous?


P.S. NetBSD installs shared libbfd:

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to