Summary: | sci-physics/root-5.34.00: fails to build with glibc-2.16 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Diego Elio Pettenò (RETIRED) <flameeyes> |
Component: | New packages | Assignee: | Andrew Savchenko <bircoph> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bircoph, sci-physics |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://tinderboxlogs.s3.amazonaws.com/tbamd64.excelsior.flameeyes.eu/sci-physics%3Aroot-5.34.00%3A20120717-015450.html | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 424737 |
Description
Diego Elio Pettenò (RETIRED)
2012-07-17 10:39:01 UTC
This is not a parallel build issue. (Have you tried with -j1 anyway?) /tmp/portage/sci-physics/root-5.34.00/work/root/build/rmkdepend/main.c:64:12: error: conflicting types for 'fchmod' In file included from /tmp/portage/sci-physics/root-5.34.00/work/root/build/rmkdepend/def.h:42:0, from /tmp/portage/sci-physics/root-5.34.00/work/root/build/rmkdepend/main.c:30: /usr/include/sys/stat.h:298:12: note: previous declaration of 'fchmod' was here It looks like a glibc issue: /usr/include/sys/stat.h. As for now glibc-2.16 is not supported, because it is not yet keyworded for any architecture. (And I can't ruin any of mine systems by installing an unsupported version of the core system library.) If you will have this problem with glibc-2.15-r2 or less, feel free to reopen this bug. I can't reproduce it with glibc-2.15-r2. P.S. I'm planning to update root to 5.34.01 soon. You are welcome to check this issue with a new version then. Okay, let's start with "I don't care if it's not supported by _you_, but glibc-2.16 _is_ being tested and supported, so this is _not_ INVALID if it's failing with glibc-2.16. No I didn't test with -j1 because if I had to try everything failing with -j1 it would probably not be able to test anything meaningfully, that's why there was a "?" in the subject. The correct fix of course would be _not_ redeclaring fchmod. Until glibc-2.16 will be keyworded it is impossible for me to test root build with glibc-2.16. Without proper testing fixing this only problem will do nothing, because similar or other glibc-related build issues may appear. I'll fix this bug when glibc-2.16 will be keyworded if this will be still actual for in-tree root version at that moment. According to Gentoo Devmanual, not keyworded => not supported. It's not keyworded _because we know it breaks stuff_ and we want to fix it _before we keyword it_. Now instead of trying to tell _the QA lead_ what is and isn't supported, what about setting up a chroot with glibc 2.16 and try to build it there? (In reply to comment #4) > Now instead of trying to tell _the QA lead_ what is and isn't supported, Rules are supposed to be the same for everyone. > what about setting up a chroot with glibc 2.16 and try to build it there? I don't have CPU/time resources for a full chroot right now. Will look later at this issue. The problem is that you don't understand the rules. Stating something is "not supported" does not mean "close as INVALID a valid bug because you don't want to spend time to fix it now". It means "patch welcome" if it's something that's _never_ going to be supported or "okay, as soon as I have time" if it's just a matter of time. In the case of _any_ base system package that is masked _for testing_, whoever opens the bug, it is _not_ invalid. You might not put high priority on it but _you keep it open or we won't really know if there are issues with the package or not_. fixed with a patch from fedora |