[Bug binutils/15920] New: <bfd.h> not suitable as a general-purpose header

[raphael.manfredi at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=15920

            Bug ID: 15920
           Summary: <bfd.h> 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 <bfd.h> 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 <bfd.h> 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 <bfd.h> 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 <bfd.h> 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.