On 6 Feb, David O'Brien wrote:
> Yes it comes as part of binutils.
Ok.
> 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
http://www.gnu.org/manual/bfd-2.9.1/
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
system.
>> P.S. NetBSD installs shared libbfd:
>>
>http://wuarchive.wustl.edu/systems/unix/NetBSD/NetBSD-release-1-5/src/gnu/lib/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
work."
Yours,
-mi
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
