| Summary: | sys-libs/libstdc++-v3 fails if /bin/sh is dash | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Patrick Lauer <patrick> |
| Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | kfm, slyfox |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 526268 | ||
| Attachments: | gentoo-446212.patch | ||
|
Description
Patrick Lauer
2012-12-06 04:45:14 UTC
Created attachment 478546 [details, diff]
gentoo-446212.patch
The offending test is intrinsically broken because it assumes that the version number is to be found immediately after an opening bracket. Here are some sample strings that show this assumption to be erroneous:
Arch: GNU assembler (GNU Binutils) 2.28.0.20170506
Ubuntu Xenial: GNU assembler (GNU Binutils for Ubuntu) 2.26.1
Gentoo: GNU assembler (Gentoo 2.28 p1.2) 2.28
The attached patch does away with this nasty code and, instead, employs the following behaviour:
1) Uses parameter expansion to get the version number i.e. the final word from the line
2) Captures the major and minor fields by way of a simple read statement that splits on .
Sorry, I should have said that the existing code assumes that the version number is to be found immediately after the text, "GNU assembler ", rather than an opening bracket. The supplied patch still stands. Does it still happen? If it does for you please attach full build.log. The leb128 test is still intrinsically broken:
-------------------------------------------------
checking assembler leb128 support...
./configure: 7352: test: GNU: unexpected operator
yes
-------------------------------------------------
Effectively, it is doing this:
$ dash -c 'test GNU assembler \(Gentoo 2 -eq 2 -a 30 -lt 11'
dash: 1: test: GNU: unexpected operator
In my testing, the only difference now is that the erroneous test command doesn't cause the configure phase to take exception, with it carrying on regardless. Brittle, to say the least.
As before, the provided patch stops any erroneous shell code from attempting to be executed and has the test function as intended.
Please attach full build.log. I can't reproduce build failure locally and would like to check the difference. $ LANG=C ls -l /bin/sh lrwxrwxrwx 1 root root 4 Feb 16 22:05 /bin/sh -> dash I cannot. I didn't say that it was still failing. On the contrary: "In my testing, the only difference now is that the erroneous test command doesn't cause the configure phase to take exception, with it carrying on regardless." In summary, the overall build failed when I tested it in 2017 but not when I tested it at the time of my last comment. There's no use in attaching a build log because a) I cannot now reproduce a build failure b) it doesn't provide any insight into the syntactically invalid shell code that is still composed and conveyed to the shell during one of the tests. Regarding (b), I have explained the original issue thoroughly and supplied a patch that remains valid and applicable. There's really not much more that I can say. While the outcome of the test is not important for Gentoo - having, as it does, a modern binutils - it is still a broken test that has previously resulted in build failures. Maybe it will again. I don't use this package so I won't be investigating any further. If proof is still needed, try running:- # ebuild libstdc++-v3-3.3.6-r1.ebuild compile 2>&1 | perl -ne 'print if /leb128 support/../eh_frame/' (In reply to Kerin Millar from comment #6) > I cannot. I didn't say that it was still failing Aha. Then it's not an instance of the original bug reported here. That was probably fixed with a patchset bump in bug #665768 > Regarding (b), I have explained the original issue thoroughly and supplied a > patch that remains valid and applicable I believe that was fixed upstream as: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=b29dc6144f4e0f43b2970a6150393f18026c72ba I'd rather not backport it as long as it does not cause any issues. Closing as OBSOLETE. (In reply to Sergei Trofimovich from comment #8) > I believe that was fixed upstream as: > > https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff; > h=b29dc6144f4e0f43b2970a6150393f18026c72ba > > I'd rather not backport it as long as it does not cause any issues. I see. Yes, the present build deduces that leb128 support is available anyway, so I suppose it matters not at this point. |