Menu
▾
▴
#2022 4.0.0: <bfd.h> header not suitable as-is as a general header
open
nobody
Support
none
component_package
False
2013-09-02
2013-08-31
No
The following lines must be removed from the /mingw/include/bfd.h file to allow it to be perused by applications.
/* 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 bug should be filed with the upstream binutils package maintainer. It is wrong of them to include the header in the install package. None the less, I don't think this header should be delivered in the binutils -bin file either. But I'm close to delivering a new version which does not include the header in the -bin file but that new version will not ``fix'' the bfd.h bug since it is an upstream issue.
What makes you think bfd.h is supposed to be a general-use header? It certainly isn't installed as such, either for the native gcc on my LinuxMint Debian box, or for my mingw32-gcc cross-compiler.
I suspect that the correct resolution here is that bfd.h should not be installed as a general-use header.
Keith,
/usr/include/bfd.h on my Linux machine (as supplied by binutils-dev) is a general-purpose header intended to be used as such by C programs. It is almost similar to the one I find in MinGW.
It correctly worked in previous MinGW versions. I noticed the bug because my program would no longer properly compile with the newest MinGW install and I traced it down to the incorrect bfd.h file.
Hmm. It isn't installed for me, when I perform a stock build and install for the mingw32 target, from the upstream binutils-2.23.1 sources. I don't know how Chris, who built our distribution but is unfortunately no longer associated with the project, got it into the bin archive. If, as it appears, he simply copied the private-use header from the source distribution, that would be wrong.
The omission from a stock install suggests that the binutils folks may not intend this as a public-use header. If that is the case, then any project using it may be expected to take care of certain preliminaries, but I cannot say this with any authority; you need to raise the issue with the binutils project directly.
I installed MinGW with the "devel" option (the one that includes MSYS, I do not remember how it is called). I need the BFD library in the MinGW distribution because I rely on it to be able to print meaningful stack traces on Windows.
Right now, I'm using an older MinGW install to be able to produce Windows binaries, but I would love to be able to use the latest MinGW. If you tell me it will not include the BFD library (I mean "binutils-dev" here), then it's a regression against older MinGW installs, don't you think?
The newest MinGW C startup runtime has a bug BTW. One of its routines (dirname() I think, when constructing argv[]) is calling free() on something not allocated by malloc(). I know because my program redefines malloc() and free() and my free() asserts that the pointers it gets must be allocated by malloc() or friends like posix_memalign(). I cannot qualify it further because I no longer use the newest MinGW due to the BFD compile bug.
This is off-topic for this ticket; you should raise a new report, please. It would also be appreciated, if you could pin the issue down more precisely. If it does occur in dirname(), then free() is called on a buffer which is allocated by strdup(), which will call MSVCRT.DLL's malloc() to allocate that buffer. If you replace free(), then you probably also need to replace every other MSVCRT.DLL routine which might return a buffer allocated by MSVCRT.DLL's malloc().
I just read through binutils PR14072, which led me to PR14243. My interpretation of this is that the binutils folks intend bfd.h as a private-use header. They recognise that other projects may use it, but they will not revert the change, introduced in 1.23.x, which causes this issue; their view is that it should become the responsibility of such client projects to properly address the inclusion issue -- "
#define PACKAGE" or "#define PACKAGE_VERSION" before you "#include <bfd.h>" should suffice.Yes, of course one can do such convolutions. But that's strange -- I know it's not your decision: Either the file is private, and it should not need to be included, and another file should provide the necessary interface definitions, or it's public and it should be cleaned up. But requiring people to define these symbols beforehand is just silly. That's rather bad library design.
In any case, the aim of MinGW is to provide a suitable environment to compile UNIX programs on Windows. On UNIX, I have not yet seen a system where I need to do this. And I've been using BFD for quite some time. So their change will break many programs, and this is a gratuitous change: defining PACKAGE is a workaround, proving that the inclusion of "config.h" serves no purpose to parse the remaining of the file.
Anyway, I'll continue to stick with an older MinGW environment until the BFD folks realize their mistake and roll it back.
FWIW, I tend to agree with you. However, it does seem clear that the binutils folks do consider the header to be private. In any case, I simply don't have time to argue the case with them; if you feel strongly enough about it, then you'll need to do that yourself.
Just for follow-up, the inclusion of the bfd.h header was provided by the binutils-2.23.1-mingw32-bin file; yes really!! Yea, I know but ... it is also included by the --enable-install-libbfd configure option so for one system to have it and another not could be common. The question I have is should MinGW continue to provide it?
Okay. I don't normally build with
--enable-install-libbfd, but I addedto my build configuration script, and rebuilt. Sure enough, that got libbfd.a and its headers installed, but not as public facilities; they landed in
${prefix}/x86_64-unknown-linux-gnu/mingw32/liband${prefix}/x86_64-unknown-linux-gnu/mingw32/includerespectively, and these most definitely are not in my mingw32-gcc's default search paths.It still isn't clear, to me, how you justify publishing these as public facilities.
The BFD library is required to get symbolic stack dumps in case of crashes on Windows, and it is important because Windows does not support core dumps. Therefore, it is not possible to perform post-mortem core dumps via gdb.
UNIX programs ported to Windows should therefore welcome the presence of the BFD library in that environment!
GDB already has it's own private bfd library embedded in the source so providing it in MinGW binutils isn't necessary. The bfd library wasn't really meant for general use and including it in your source package is what is normal. I don't see a reason for us to continue to carry it. Give me a better reason than MinGW looks prettier with it. I'm thinking of adjusting binutils configure options to exclude including the library because I see no real good reason to carry it from outside of a package.
For the record, I filed the following bug to binutils:
https://sourceware.org/bugzilla/show_bug.cgi?id=15920
I added my comments to that ticket.
And, on the basis of what I see there so far, I'm inclined to support pulling libbfd from the MinGW.org binutils binary distribution. Everything I'm seeing, from the binutils maintainers' perspective, suggests that libbfd.a isn't intended for general use, but rather that it should be embedded as a private sub-project when needed. As such, any client project needs to fulfil certain prerequisites for including bfd.h as a private header; among those is a requirement to predefine macros which suggest that config.h -- another header which is always private, by convention -- has been included beforehand.
I'll create an update for binutils-2.23.2 after I get gdb done. After which I'll close this ticket.
And gdb installs libbfd even without a configure option to do so; as well as libiberty and libopcodes. All three are meant to be private libraries.
Forcing projects to embed the BFD library source in their code is the worst engineering decision one can make. This means painfully updating it everytime the mainstream library changes, for every project. This means artificially inflating the amount of source code each project has to carry.
Packaging a nice BFD library in MinGW is adding value. Debian manages to have a nice binutils-dev package that provides libbfd.a. You should at least provide the BFD library to developers!