| Summary: | sys-devel/bison-3.5.4 - lib/binary-io.h:52:10: error: 'O_BINARY' undeclared (first use in this function) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Dennis Schridde <dschridde+gentoobugs> |
| Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | crabbedhaloablution, firefly_dude0k, gentoo-bz, gentoo, jarausch, jstein |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://lists.gnu.org/archive/html/bug-bison/2020-09/msg00001.html | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
build.log
bison-3.7.1-fcntl-needs-O_BINARY.patch Build log with "make -j1" Build log with "make -j4" |
||
|
Description
Dennis Schridde
2020-04-07 06:25:10 UTC
Build failure persists in sys-devel/bison-3.7.1. Created attachment 653292 [details, diff]
bison-3.7.1-fcntl-needs-O_BINARY.patch
The attached patch fixes the build by having Autoconf require that the system <fcntl.h> defines the O_BINARY and O_TEXT constants or else generate lib/fcntl.h.
*** Bug 735792 has been marked as a duplicate of this bug. *** Just had the same error on bison-3.6.4 which appears to have been marked stable recently so updating the system resulted in failure. "Fixed" by s/O_BINARY/0/ and S/O_FREE/0/ everywhere as these are irrelevant for Linux anyway. Any chance configure can check for these? (In reply to Claudio Calvelli from comment #4) > Just had the same error on bison-3.6.4 which appears to have been marked > stable recently so updating the system resulted in failure. > "Fixed" by s/O_BINARY/0/ and S/O_FREE/0/ everywhere as these are irrelevant > for Linux anyway. > Any chance configure can check for these? I meant O_TEXT of course, not O_FREE... (In reply to Claudio Calvelli from comment #4) > Any chance configure can check for these? That's exactly what my patch in comment #2 does. Did you try it? (In reply to Matt Whitlock from comment #6) > (In reply to Claudio Calvelli from comment #4) > > Any chance configure can check for these? > > That's exactly what my patch in comment #2 does. Did you try it? That patch works - but I would expect that to be in the ebuild before it gets marked stable... I don't know why you hit this but the patch is wrong -- the change was intended. Also, see https://lists.gnu.org/archive/html/bug-bison/2019-08/msg00003.html (In reply to Thomas Deutschmann from comment #8) > I don't know why you hit this but the patch is wrong -- the change was > intended. After running more tests, it seems that when I tested with just "make" it built - with or without the patch. But using "make -j4" it fails with "O_BINARY undeclared", and that seems to be fairly repeatable - "-j4" fail, no "-j" OK. (this is starting from scratch, with no user_patches, just the ebuild as per an "emerge --sync" about 1 hour ago). But this sounds like some weird parallel build issue, so MAKEOPTS=-j1 is always working for you? I don't understand how it could possibly be a parallel build issue. The source code makes use of the O_BINARY macro, which glibc no longer defines in <fcntl.h>. The autoconf script (as shipped) doesn't test the system <fcntl.h> for a definition of O_BINARY, so the lack of such a definition doesn't prevent the build from attempting to use the system <fcntl.h>. The proper fix, a far as I can see, is to make the autoconf script test the system <fcntl.h> for a definition of O_BINARY, so that the build will use its local version of fcntl.h if the system version lacks the needed definition. Parallel build is irrelevant to all of this. (In reply to Thomas Deutschmann from comment #10) > But this sounds like some weird parallel build issue, so MAKEOPTS=-j1 is > always working for you? As far as I've tested, yes "-j1" always works. But it takes some time to test, so I've only done a few times. I've generated build logs with "-j1" (OK) and "-j4" (fail) if comparing them can help anybody. Will attach them in a second. Created attachment 657590 [details]
Build log with "make -j1"
Created attachment 657592 [details]
Build log with "make -j4"
(In reply to Matt Whitlock from comment #11) > Parallel build is irrelevant to all of this. Comparing the build logs, "-j1" runs a "sed" to generate lib/fcntl.h - and "-j4" does not... so parallel build makes all the difference. The patch does not actually work - it only seemed to work because I tested it with "make -j1". The build still fails after applying the patch if I use "make -j4", and the difference is still the same, the Makefile does not generate lib/fcntl.h Now I'm not able to get the build of sys-devel/bison-3.7.1 to fail, even without the patch. Oddly, the build on my system (now) *does* generate lib/fcntl.h, even though configure says "checking for working fcntl.h... yes". I would say that the Autoconf test is wrong/incomplete, as Bison does use the O_BINARY flag, which is no longer defined by glibc's <fcntl.h>. My patch fixes that issue by making the "checking for working fcntl.h" test fail. Evidently whether the Bison build process generates lib/fcntl.h does not depend on whether the "checking for working fcntl.h" Autoconf test passes or fails. I just tried building 3.7.1, and I get the same result. Fails with "-j4" (which is my default in make.conf) and builds OK with "-j1". So for me the problem hasn't been fixed in 3.7. The difference is still the same, lib/fcntl.h does not generated by the parallel build, which suggests some missing dependency somewhere. Looking at the Makefile, nothing seem to depend on lib/fcntl.h, so that would be why "make" hasn't generated it before it's needed And this, I feel, is the real bug - anything which relies on O_BINARY or O_TEXT needs to depend on lib/fcntl.h explicitely in the Makefile (In reply to Claudio Calvelli from comment #17) > Looking at the Makefile, nothing seem to depend on lib/fcntl.h I think that's by design. The intention appears to be that lib/fcntl.h is only generated and used if the system <fcntl.h> is inadequate. It used to be the case that glibc's <fcntl.h> defined O_BINARY (to a dummy value) on Linux, so Bison didn't need to generate its own lib/fcntl.h just for the sake of referencing O_BINARY. That's no longer true since glibc dropped its definition. So, nothing in Bison's Makefile should depend explicitly on lib/fcntl.h, as that file may not need to be generated in all cases. But there *should* be a dependency on whatever target generates all the header files in lib/. (In reply to Matt Whitlock from comment #18) > (In reply to Claudio Calvelli from comment #17) > > Looking at the Makefile, nothing seem to depend on lib/fcntl.h > > I think that's by design. The intention appears to be that lib/fcntl.h is > only generated and used if the system <fcntl.h> is inadequate. It used to be No, the makefile generates lib/fcntl.h every time (from $(BUILT_SOURCES) which in turn is built by "make all") - but not having a dependency means that a parallel build may not generate it before it's used. As a result, gcc uses the system's fcntl.h which doesn't have the test for O_BINARY - this is also the reason why checking for that in configure makes no difference to the result. For a non-parallel build, in the absence of explicit dependencies make builds the targets in the order it sees them in the Makefile, and then it works. For a parallel build, it seems to decide to build some of the .o files before the fcntl.h which they do depend on logically, because the Makefile doesn't have anything to say that it is wrong to do so. This needs to be fixed by upstream to put correct dependencies, however I see 2 possible workaround for the ebuild (and if upstream don't fix the dependencies, can please we have one of them before a newer ebuild is marked stable?) 1. force -j1 in the ebuild, or 2. do a "make lib/fcntl.h" before the "make all" to make sure things are built in the right order (In reply to Claudio Calvelli from comment #19) > 2. do a "make lib/fcntl.h" before the "make all" to make sure things are > built in the right order Wouldn't this only whack *one* mole, so to speak? We're having problems with lib/fcntl.h, but there are many other generated header files that could exhibit the same dependency ordering problem, aren't there? (In reply to Matt Whitlock from comment #20) > Wouldn't this only whack *one* mole, so to speak? We're having problems with > lib/fcntl.h, but there are many other generated header files that could > exhibit the same dependency ordering problem, aren't there? That is absolutely correct... I guess forcing "-j1" is the only workaround right now. It actually seems like Automake is supposed to support exactly this scenario: https://www.gnu.org/software/automake/manual/html_node/Sources.html Indeed, you can see in Makefile.in: all: $(BUILT_SOURCES) $(MAKE) $(AM_MAKEFLAGS) all-recursive So everything listed in $(BUILT_SOURCES) should be made *strictly before* beginning to make the all-recursive target. And we can see that lib/fcntl.h is added to BUILT_SOURCES in lib/gnulib.mk, which is included by lib/local.mk, which is included by the top-level Makefile.am. And we can see that lib/fcntl.h is listed in BUILT_SOURCES in the top-level Makefile.in that Automake generates. So the upshot is that lib/fcntl.h is a dependency of the top-level "all" target. It might be revealing to run a 'make -p' in a prepared Bison build directory just to verify that the 'all' target does in fact depend on lib/fcntl.h. Right, since 3.7.1 was just marked stable and duly failed to build... Seems that the exact combination of switches "make -j4 -l2" (which just happens to be my default) results in the error. Every single time on the system where I had the error the other day. Obviously, the result of the load check will differ on other systems, the same exact combination compiled correctly on another (faster) system, however on there I could get the same error (repeatably) with "make -j4 -l0.5". I note from the OP's build log that they were using "-j6 -l4" which presumably is the precise combination to trigger the error on their system. This would make the bug rather difficult to replicate without borrowing one of the systems where it's been noticed. However I wonder if the package maintainer could be able to replicate the bug with this information. I also wonder if this is actually some weird bug with "make". Oh, I forgot to post to this bug:
I was able to reproduce
> LC_ALL=C tests/bison --version >doc/bison.help.tmp
> make: *** [Makefile:10025: doc/bison.help] Error 139
failure with USE=static and version 3.6.4.
It is working in 3.7.1 for me.
I tried to bisect but even 3.6.4 when built from git sources works for me so I gave up given that 3.7.1 release tarball was working for me.
If you are still running into problems please report upstream. Maybe they can help you to find to root cause.
(In reply to Thomas Deutschmann from comment #24) > If you are still running into problems please report upstream. Maybe they > can help you to find to root cause. FYI - I did report it upstream and it's been fixed in 3.7.2 (just released). Thank you very much! The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=332d144e99865ec163da64f97f50ebf3a107c5d1 commit 332d144e99865ec163da64f97f50ebf3a107c5d1 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2020-09-05 17:37:06 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2020-09-05 17:58:25 +0000 sys-devel/bison: bump to v3.7.2 Closes: https://bugs.gentoo.org/716516 Package-Manager: Portage-3.0.4, Repoman-3.0.1 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> sys-devel/bison/Manifest | 2 + sys-devel/bison/bison-3.7.2.ebuild | 92 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 94 insertions(+) |
