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