[Bug binutils/15920] New: not suitable as a general-purpose header
https://sourceware.org/bugzilla/show_bug.cgi?id=15920 Bug ID: 15920 Summary: not suitable as a general-purpose header Product: binutils Version: 2.24 (HEAD) Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: raphael.manfredi at gmail dot com As included in MinGW and coming directly from binutils 2-23.1 it would seem, the header starts with: /* PR 14072: Ensure that config.h is included first. */ #if !defined PACKAGE && !defined PACKAGE_VERSION #error config.h must be included before this header #endif This is not suitable for a genral-purpose header, intended to be used by standalone applications that do not need to include any "config.h" -- supposedly coming from the binutils compilation environment. The "bfd.h" file seems to be generated automatically, and as such, it should remove any meta-configuration checks done at compile time for the platform, and deliver a file that any application linking with libbfd can include. On my Linux machine, I'm still using binutils-dev 2.22, but I also see checks like "defined (HAVE_STRINGIZE)" in /usr/include/bfd.h, which have no meaning for me since I am not using autoconf for instance. And again, such a check should have been done at meta-configuration time, and the "bfd.h" delivered on my linux platform should be tailored for features available on that platform. This is a sensible thing to do for a library. You cannot make assumptions on the compilation environment the application including the file will use. "autoconf" is not the only meta-configuration tool available, even if it is widely used. The "PR 14072" change breaks things in the current MinGW release because it makes it impossible to include in an application without getting an error. Sure, I can define "PACKAGE" and "PACKAGE_VERSION" to meaningless values, but this will only work for my application. It will still break others, and also defeats meta-configuration packages which attempt to probe for the presence of libbfd: they cannot define PACKAGE before including in their check, because they do not know whether the package they meta-configure for will do that in their code. So they end-up not detecting BFD, despite it being present on the system. I am certain the BFD library can provide a proper interface-definition file for the platform it is being compiled on, and generate the right header that will be publicly visible to interface with the library. For instance, you know whether HAVE_STRINGSIZE is true of false when you compile on Linux, so why perform the check in the header? Since one will only install the generated "bfd.h" file on a Linux machine, there is no problem at all. The same logic should apply to any other OS. My application relies heavily on the BFD library to perform symbolic stack traces. Not being able to compile with BFD means I get hexadecimal stack traces which make debugging impossible, especially on platform like Windows which do not dump core on crashes. -- 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
[Bug binutils/15920] not suitable as a general-purpose header
https://sourceware.org/bugzilla/show_bug.cgi?id=15920 --- Comment #3 from Raphael Manfredi --- Why limit the audience of the library? I fail to see the point of requiring people to go through contorsions to be able to use it when all you need to do is generate a "bfd.h" header clean of any dependency? Since that file is generated, it's not so much a hassle to do, and it is done ONCE instead of having all the customers painfully work around all the safety you are putting in place. I am developing a general-purpose library for which BFD is a much-needed piece. I do not use "autoconf" for configuring my library, I am using "metaconfig". Therefore, my compiling environment is not that of an auto-configured package. The point is not that MinGW should or should not include BFD, the point is to make sure BFD remains a library that can be used by other packages. It will always require some care, but that is true of all non-trivial libraries. However, my main argument is that it should not be artificially made a pain to work with. I fail to see the rationale of making BFD hard to reuse in other packages. -- 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
[Bug binutils/15920] not suitable as a general-purpose header
https://sourceware.org/bugzilla/show_bug.cgi?id=15920 --- Comment #6 from Raphael Manfredi --- 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
[Bug binutils/15920] not suitable as a general-purpose header
https://sourceware.org/bugzilla/show_bug.cgi?id=15920 --- Comment #8 from Raphael Manfredi --- As a side note, all this started with the "config.h" protection because of the HAVE_STRSIZE check in the "bfd.h" header, to conditionally redefine the CONCAT4() macro... Macro which is never used in "bfd.h", and that file is not including any other file either after the CONCAT4 redefinition. Therefore, this leads me to think that the redefinition of CONCAT4 should be moved elsewhere, because this is a portability issue, probably in some auto-configuration file. That is the real root cause that needs fixing. That would make "bfd.h" clean again, and would remove the need to enforce that "config.h" be included before it. -- 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
