Summary: | <dev-libs/boost-1.48.0 fails to compile with GCC 4.7 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Ryan Hill (RETIRED) <rhill> |
Component: | [OLD] GCC Porting | Assignee: | C++ Team [disbanded] <cpp+disabled> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | arfrever.fta, dev-zero, dilfridge, dlan, hwoarang, jlp.bugs, marduk, SebastianLuther, tdalman, xmw |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 390247 | ||
Attachments: |
build.log
make gcc-4.7 happy compile |
Description
Ryan Hill (RETIRED)
2012-03-11 07:27:33 UTC
Created attachment 304895 [details]
build.log
The fix is included in dev-libs/boost-1.49.0. This has been fixed in 1.49 and I have no interest in backporting this to 1.48. By the time gcc-4.7 hits portage, 1.49 will be in ~testing. Leave porting bugs open until the fix is available please. I need to keep track of what remains to be done. Done. *** Bug 418049 has been marked as a duplicate of this bug. *** Please leave these bugs open to avoid duplicates (like I did) and give people with standard bugzie setups (w/o ALL on every query) a chance to discover them. This subject is not resolved/fixed. Just reso/wont-backport ... Either way it won't show up, and we're not leaving it open indefinitely. Just check the tracker for dups before you file. That's what it's for. *** Bug 424319 has been marked as a duplicate of this bug. *** (In reply to comment #3) > This has been fixed in 1.49 and I have no interest in backporting this to > 1.48. By the time gcc-4.7 hits portage, 1.49 will be in ~testing. And what about packages that depends of boost 1.48 ? Like grive. (In reply to comment #10) > (In reply to comment #3) > > This has been fixed in 1.49 and I have no interest in backporting this to > > 1.48. By the time gcc-4.7 hits portage, 1.49 will be in ~testing. > > And what about packages that depends of boost 1.48 ? Like grive. Don't reply on closed bugs because there is a chance we never see them. Poke grive upstream to support a newer boost. (In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #3) > > > This has been fixed in 1.49 and I have no interest in backporting this to > > > 1.48. By the time gcc-4.7 hits portage, 1.49 will be in ~testing. > > > > And what about packages that depends of boost 1.48 ? Like grive. > > Don't reply on closed bugs because there is a chance we never see them. Poke > grive upstream to support a newer boost. Sorry this bug was not closed How many packages do exclusively depend on <=boost-1.48 ? And: have you openened a bug report for grive ? I just tested grive with boost-1.49-r1 and GCC-4.7.1. No problems here. I just created Bug 426848 for grive. *** Bug 429634 has been marked as a duplicate of this bug. *** Created attachment 320180 [details, diff] make gcc-4.7 happy compile (In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #10) > > > (In reply to comment #3) > > > > This has been fixed in 1.49 and I have no interest in backporting this to > > > > 1.48. By the time gcc-4.7 hits portage, 1.49 will be in ~testing. > > > > > > And what about packages that depends of boost 1.48 ? Like grive. > > > > Don't reply on closed bugs because there is a chance we never see them. Poke > > grive upstream to support a newer boost. > > Sorry this bug was not closed hi, markos, I would be appreciate if you can apply this trival patch which Ryan hill already point out. It's really simple, which won't bring any side effect . I've tested with gcc-4.7.1, it works fine. attached file is the patch, add one line epatch to ebuild also,It would be fine if you still insist keep this bug open, I could put it into my overlay... (In reply to comment #16) > Created attachment 320180 [details, diff] [details, diff] > make gcc-4.7 happy compile > > (In reply to comment #12) > > (In reply to comment #11) > > > (In reply to comment #10) > > > > (In reply to comment #3) > > > > > This has been fixed in 1.49 and I have no interest in backporting this to > > > > > 1.48. By the time gcc-4.7 hits portage, 1.49 will be in ~testing. > > > > > > > > And what about packages that depends of boost 1.48 ? Like grive. > > > > > > Don't reply on closed bugs because there is a chance we never see them. Poke > > > grive upstream to support a newer boost. > > > > Sorry this bug was not closed > > hi, markos, I would be appreciate if you can apply this trival patch which > Ryan hill already point out. It's really simple, which won't bring any side > effect . > I've tested with gcc-4.7.1, it works fine. > attached file is the patch, add one line epatch to ebuild > > also,It would be fine if you still insist keep this bug open, I could put it > into my overlay... I don't mind backporting this to boost-1.48 but is there a reason to fix this version? As far as I can tell, ~testing users should just migrate to 1.49.0 asap. (In reply to comment #17) > (In reply to comment #16) > > Created attachment 320180 [details, diff] [details, diff] [details, diff] > > make gcc-4.7 happy compile > > > > (In reply to comment #12) > > > (In reply to comment #11) > > > > (In reply to comment #10) > > > > > (In reply to comment #3) > > > > > > This has been fixed in 1.49 and I have no interest in backporting this to > > > > > > 1.48. By the time gcc-4.7 hits portage, 1.49 will be in ~testing. > > > > > > > > > > And what about packages that depends of boost 1.48 ? Like grive. > > > > > > > > Don't reply on closed bugs because there is a chance we never see them. Poke > > > > grive upstream to support a newer boost. > > > > > > Sorry this bug was not closed > > > > hi, markos, I would be appreciate if you can apply this trival patch which > > Ryan hill already point out. It's really simple, which won't bring any side > > effect . > > I've tested with gcc-4.7.1, it works fine. > > attached file is the patch, add one line epatch to ebuild > > > > also,It would be fine if you still insist keep this bug open, I could put it > > into my overlay... > > I don't mind backporting this to boost-1.48 but is there a reason to fix > this version? As far as I can tell, ~testing users should just migrate to > 1.49.0 asap. hi markos, as My suggestion, it's better to have... 1) since it still in tree, if you think it useless why not remove it? :-) 2) another reason, package such as libreoffice depends on boost, migrate to 1.49 will cause it re-compile (emerge @preserved-rebuild), it really takes huge time... which may not as the intention of user, so base my own personal experience I'd like to keep boost multi version/slot installed, and emerge libreoffice at *proper* time For slotted packages I think we should fix the latest version in each slot*. There's not much point in having them in the tree if you can't build them. *(within reason of course - I don't expect it to be backported all the way back to 1.35, though I wonder why we still have those versions) Ok, patch applied. Do we still need to keep this bug open? Nah, good to go. |