On Wed, 5 Jul 2006, John Baldwin wrote: >>> libbdf.a is built by /usr/src/gnu/usr.bin/binutils/libbfd/Makefile. That >>> should be a fairly simple change to arrange for it to build and install >>> the .so as well. >> >> Installing both libbfd-s certainly would be a good start... As things >> stand, every port needing it -- including various different compilers -- >> builds it own version. This is, largely, explained by the GNU's stupidity >> of bundling a different version with each tool (gdb, compiler), but the >> bundled bfds are not THAT incompatible, and the system-installed version >> can include the compatible superset... > > Actually, in the past this has proven quite difficult, hence the current > arrangment of various tools linking statically against their own private > copy. My recollection is that we got to where we are today precisely because the various GNU tools (gdb, gcc, etc) relied on versions of bfd "as cut" at the point where the tool revisions were released. This meant that they could not share bfd versions between tools, since tools were often released at different dates, and the versions of bfd with different tools were incompatible. The conclusion was that by statically linking the specific compatible versions into the binaries, and by not shipping a specific bfd as part of the base system, we avoided numerous compatibility issues, as well as avoided committing consumers of the system to a particular bfd revision that might be incompatible with what they want to run in the way of their own cross tools, etc. Perhaps the world has changed since that time, but those sound like pretty good reasons to me. So these are my recollections, but since I'm not an expert in our toolchain bits, I could be off in the woods somewhere. Robert N M Watson Computer Laboratory University of CambridgeReceived on Wed Jul 05 2006 - 14:18:10 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:58 UTC