https://sourceware.org/bugzilla/show_bug.cgi?id=15920
--- Comment #6 from Raphael Manfredi <raphael.manfredi at gmail dot com> --- On my Debian machine, "dpkg -L binutils-dev" yields the following files: /usr/include/plugin-api.h /usr/include/bfdlink.h /usr/include/bfd.h /usr/include/libiberty.h /usr/include/ansidecl.h /usr/include/symcat.h /usr/include/dis-asm.h /usr/include/demangle.h /usr/lib/libiberty_pic.a /usr/lib/libbfd.a /usr/lib/libopcodes.a /usr/lib/libiberty.a /usr/share/doc/binutils-dev /usr/lib/libopcodes.so /usr/lib/libbfd.so If there's no ABI stability, don't provide a .so, just the .a as we don't want to dynamically link against it. If there is no API stability, then why not define one? The BFD "component" (since you insist it's not a library) seems stable enough to get a general-purpose API. Clearly draw the line between features that are sufficiently high-level to require an API, and those that must rather stay confidential. The documentation in https://sourceware.org/binutils/docs/bfd/ seems to be a good start for a public API... Capitalizing on the effort required to come-up with BFD in the first place is not only a tribute to the team, it's also saving engineering cycles for other projects because these projects have a way to access program symbols easily, meaning easier debugging during development, better code quality. Everybody wins. I understand committing a public API is a responsibility, meaning harder work because then you have to think about backward compatibility, etc... It's also something that I see worth doing. If you don't want to make everything visible, choose a subset that's been stable for the last 10 years. I'm sure most of the application-level features could be made available via a stable API. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
