Bruce Dubbs wrote: > Dan Nicholson wrote: > >> I'm not a programmer, but this is my guess. In order for gdb to be >> able to properly debug binaries, it needs to link libbfd.a and >> libiberty.a into the gdb binary. It builds its own since it can't >> depend on the host and it may be tied to specific versions of libbfd >> and libiberty. The fact that they're installed seems to be a flaw >> since running gdb shouldn't depend on static libraries being present >> on the host. > > I signed up on the gdb mailing list and asked why the libraries are > installed over binutils' libraries. Maybe we'll get an answer.
I did get an answer from David Jacobowitz: Binutils and GDB are maintained in the same CVS repository. In general, you should use whichever copy of the shared libraries is newer, but it's rarely a big deal. For all these I would just stick with the copy from binutils. GDB will never use the shared versions anyway; it always uses its own copies. ---------- I also asked how to deal with the library/header/info files installation. The response: I believe all of those directories have configure options to disable installation. Try --disable-install-libbfd and --disable-install-libiberty. Opcodes is keyed off BFD. ----------------- When testing, I found that the --disable-install-libiberty switch is not honored (libiberty.a is still installed). I also found that --disable-install-libbfd did not disable installation of the bfd-info* files. These switches are not documented AFAICT. I also tried out the undocumented switch --disable-nls and it worked properly. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
