On  6 Feb, David O'Brien wrote:
> Yes it comes as part of binutils.

> No we  should not  go down  this path. You've  already been  told that
> there is no official libiberty or bfd release.

Well, the following URL


for example, seems  to imply, that there  was, in fact, at  some point a
release 2.9.1 of bfd... It does not  quite match the bfd, that's part of
-current --  because of your  work on  bringing the binutils-3.x  in. So
there is _something_...

> Every software  package that needs either  comes with its own  copy --
> that always has  bug fixes or minor changes from  all the other copies
> out there.

Well,  that would  be a  porter's job  to figure  out which  changes the
package relies on,  or which it simply  did not bother to  sync with the
bfd, that comes with binutils. Plenty  of packages come bundled with the
third-party software, and a good port  makes them build with the already
installed versions  of such  software (like zlib,  OpenSSL) or  with the
version available from another port (like c-client).
>> 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,
> Why is binutils a nightmare?? I don't find it to be one.

You edited out  the rest from my  list of examples. Ok. You  did want to
drop Alpha, because  supporting the compiler on it  seemed too difficult
at  some point  -- how  is that  for  an example?  Or do  you claim  the
proposed addition is the most nightmarish of them all?
> HOW will it help to add software?  What is so wrong with compiling the
> bundled libiberty  or bfd that comes  with each of the  "new software"
> when building  them? What  is so  wrong with  having libiberty  or bfd
> statically linked into the "new software"?

It is _inelegant_  and is inconsistent with our use  of shared libraries
for most of the rest of the system. Look, we wanted ssh and we added it.
It requires  OpenSSL and we added  it. Do we link  OpenSSL staticly into
ssh and/or not install -lssl into /usr/lib?
> I frankly just don't see what "problem" it is you are trying to solve.

I  want libbfd  (and  libiberty) to  be  installed as  part  of the  OS.
Preferably -- in both, static  and dynamic fashions, consistent with the
rest of the libraries.
>> 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?
> Why is it ridiculous?
Because FreeBSD's  base source  already includes  the libbfd  source and
builds the library  during build. It just does not  install it, for some
reason. If all targets are enabled, this cross-toolchain ports would not
even need their own versions of this libraries, most likely...

> Personally I don't think a cross-toolchain build should be installing
> those bits.

And  in my  opinion, they  should not  even be  building those  bits for
themselves. I  mean, I would've come  up with a port  of this libraries,
but it  just seems silly to  port something, that's already  in the base

>> P.S. NetBSD installs shared libbfd:
> Of the two -- bfd and libiberty, bfd is the one we would have the most
> success at installing as a shared lib in /usr/lib.

Alright! One step at a time...  I understand, that this is an additional
burden for  you as Mr. Binutils,  but let's admit, this  might be useful
and move  it from  "NO!" to  "May be,  some day,  when someone  does the



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

Reply via email to