Summary: | sys-devel/gcc-4.6.3 with sys-libs/glibc-2.16 works on host but fails in openvz container with same configuration - libquadmath: configure: error: cannot run C compiled programs. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Joakim <moonwalker> |
Component: | [OLD] Development | Assignee: | Gentoo VPS Team (OBSOLETE) <vserver-devs+disabled> |
Status: | RESOLVED NEEDINFO | ||
Severity: | normal | CC: | tomwij |
Priority: | Normal | ||
Version: | 10.0 | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=437496 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log.tgz
gcc-build-logs.tar.bz2 |
Description
Joakim
2013-01-03 11:24:20 UTC
Created attachment 334170 [details]
build.log.tgz
build.log was compressed with # tar -czf build.log.tgz build.log
Created attachment 334172 [details]
gcc-build-logs.tar.bz2
Comment on attachment 334170 [details]
build.log.tgz
Why did you stick it in a tar archive?
*** This bug has been marked as a duplicate of bug 437496 *** (In reply to comment #3) > Comment on attachment 334170 [details] > build.log.tgz > > Why did you stick it in a tar archive? Because it's 6mb as plain text and only 1mb is allowed or have I missed something? (In reply to comment #4) > > *** This bug has been marked as a duplicate of bug 437496 *** And I'm not sure if I agree about this, it may produce the same error but the fundamentals are different. Both gcc and glibc works perfectly with the current kenel configuartion in the base node, the problem arises inside of the vz container, which uses the same kernel configuration. So I suspect this to probably be a openvz bug. Sorry if I'm wrong but I cannot accept that a perfectly working system stops working when gcc/glibc is upgraded and the resolution is set to be Invalid, doesn't sound right to me. I can of course still be wrong, but then I hope someone can explain this better so it's possible to solve the problem? > the problem arises inside of the vz container, which uses the same kernel configuration
While the kernel configuration might be the same, who knows the USE flags are different; not using multilib on the host and then using multilib inside the container is enough to make a difference. Telling us it is the same kernel configuration isn't the right response when the other bug tells you to "have x86 support in the kernel", can you please verify whether your multilib USE flags differ between host and container as well as how this setting is set in your container kernel?
(In reply to comment #7) > > the problem arises inside of the vz container, which uses the same kernel configuration > > While the kernel configuration might be the same, who knows the USE flags > are different; not using multilib on the host and then using multilib inside > the container is enough to make a difference. Telling us it is the same > kernel configuration isn't the right response when the other bug tells you > to "have x86 support in the kernel", can you please verify whether your > multilib USE flags differ between host and container as well as how this > setting is set in your container kernel? Well these things are not so easy to know when you aren't a developer, just that things break break after upgrading from one minor version to another. Not sure if this is the correct way to answer what you ask for, but this is for the hardware node: merc ~ # equery h multilib * Searching for USE flag multilib ... [IP-] [ ] sys-apps/sandbox-2.6:0 [IP-] [ ] sys-devel/gcc-4.5.4:4.5 [IP-] [ ] sys-devel/gcc-4.6.3:4.6 [IP-] [ ] sys-libs/glibc-2.16.0:2.2 merc ~ # equery u glibc [ Legend : U - final flag setting for installation] [ : I - package is installed with flag ] [ Colors : set, unset ] * Found these USE flags for sys-libs/glibc-2.16.0: U I - - debug : Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see http://www.gentoo.org/proj/en/qa/backtraces.xml - - gd : build memusage and memusagestat tools - - profile : Adds support for software performance analysis (will likely vary from ebuild to ebuild) - - systemtap : enable systemtap static probe points - - vanilla : Do not add extra patches which change default behaviour; DO NOT USE THIS ON A GLOBAL SCALE as the severity of the meaning changes drastically merc ~ # equery u gcc [ Legend : U - final flag setting for installation] [ : I - package is installed with flag ] [ Colors : set, unset ] * Found these USE flags for sys-devel/gcc-4.6.3: U I - - bootstrap : !!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used during original system bootstrapping [make stage2] - - build : !!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used for creating build images and the first half of bootstrapping [make stage1] + + cxx : Builds support for C++ (bindings, extra libraries, code generation, ...) - - doc : Adds extra documentation (API, Javadoc, etc). It is recommended to enable per package instead of globally + + fortran : Adds support for fortran (formerly f77) - - gcj : Enable building with gcj (The GNU Compiler for the Javatm Programming Language) - - go : Build the GCC Go language frontend. - - graphite : Add support for the framework for loop optimizations based on a polyhedral intermediate representation - - gtk : Useful only when building GCJ, this enables Abstract Window Toolkit (AWT) peer support on top of GTK+ + + mudflap : Add support for mudflap, a pointer use checking library - - multislot : Allow for SLOTs to include minor version (3.3.4 instead of just 3.3) + + nls : Adds Native Language Support (using gettext - GNU locale utilities) - - nopie : Disable PIE support (NOT FOR GENERAL USE) - - nossp : Disable SSP support (NOT FOR GENERAL USE) + + nptl : Enable support for Native POSIX Threads Library, the new threading module (requires linux-2.6 or better usually) - - objc : Build support for the Objective C code language - - objc++ : Build support for the Objective C++ language - - objc-gc : Build support for the Objective C code language Garbage Collector + + openmp : Build support for the OpenMP (support parallel computing), requires >=sys-devel/gcc-4.2 built with USE="openmp" - - test : Workaround to pull in packages needed to run with FEATURES=test. Portage-2.1.2 handles this internally, so don't set it in make.conf/package.use anymore - - vanilla : Do not add extra patches which change default behaviour; DO NOT USE THIS ON A GLOBAL SCALE as the severity of the meaning changes drastically and this is for the container node in question: sql / # equery h multilib * Searching for USE flag multilib ... [IP-] [ ] sys-apps/sandbox-2.6:0 [IP-] [ ] sys-devel/gcc-4.4.7:4.4 [IP-] [ ] sys-devel/gcc-4.5.4:4.5 [IP-] [ ] sys-devel/gcc-4.6.3:4.6 [IP-] [ ] sys-libs/glibc-2.16.0:2.2 sql / # equery u glibc [ Legend : U - final flag setting for installation] [ : I - package is installed with flag ] [ Colors : set, unset ] * Found these USE flags for sys-libs/glibc-2.16.0: U I - - debug : Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see http://www.gentoo.org/proj/en/qa/backtraces.xml - - gd : build memusage and memusagestat tools - - profile : Adds support for software performance analysis (will likely vary from ebuild to ebuild) - - systemtap : enable systemtap static probe points - - vanilla : Do not add extra patches which change default behaviour; DO NOT USE THIS ON A GLOBAL SCALE as the severity of the meaning changes drastically sql / # equery u gcc [ Legend : U - final flag setting for installation] [ : I - package is installed with flag ] [ Colors : set, unset ] * Found these USE flags for sys-devel/gcc-4.6.3: U I - - bootstrap : !!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used during original system bootstrapping [make stage2] - - build : !!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used for creating build images and the first half of bootstrapping [make stage1] + + cxx : Builds support for C++ (bindings, extra libraries, code generation, ...) - - doc : Adds extra documentation (API, Javadoc, etc). It is recommended to enable per package instead of globally + + fortran : Adds support for fortran (formerly f77) - - gcj : Enable building with gcj (The GNU Compiler for the Javatm Programming Language) - - go : Build the GCC Go language frontend. - - graphite : Add support for the framework for loop optimizations based on a polyhedral intermediate representation - - gtk : Useful only when building GCJ, this enables Abstract Window Toolkit (AWT) peer support on top of GTK+ + + mudflap : Add support for mudflap, a pointer use checking library - - multislot : Allow for SLOTs to include minor version (3.3.4 instead of just 3.3) + + nls : Adds Native Language Support (using gettext - GNU locale utilities) - - nopie : Disable PIE support (NOT FOR GENERAL USE) - - nossp : Disable SSP support (NOT FOR GENERAL USE) + + nptl : Enable support for Native POSIX Threads Library, the new threading module (requires linux-2.6 or better usually) - - objc : Build support for the Objective C code language - - objc++ : Build support for the Objective C++ language - - objc-gc : Build support for the Objective C code language Garbage Collector + + openmp : Build support for the OpenMP (support parallel computing), requires >=sys-devel/gcc-4.2 built with USE="openmp" - - test : Workaround to pull in packages needed to run with FEATURES=test. Portage-2.1.2 handles this internally, so don't set it in make.conf/package.use anymore - - vanilla : Do not add extra patches which change default behaviour; DO NOT USE THIS ON A GLOBAL SCALE as the severity of the meaning changes drastically And they look pretty much the same to me. So bottom line, same USE on HW node and container, former compiles and work fine, latter breaks, which makes me suspect it's something that has to do with openvz, but there ends my ability and I suppose the idea is that developers take over or? OK here is some more, first Hardware node and then vz Virtual Container and the only difference is (-nocxx%) at end of VC gcc USE HW merc ~ # emerge -pqv '=sys-devel/gcc-4.6.3' [ebuild R ] sys-devel/gcc-4.6.3 USE="cxx fortran mudflap (multilib) nls nptl openmp (-altivec) -bootstrap -build -doc (-fixed-point) -gcj -go -graphite -gtk (-hardened) (-libssp) -multislot -nopie -nossp -objc -objc++ -objc-gc {-test} -vanilla" merc ~ # emerge -pqv '=sys-libs/glibc-2.16.0' [ebuild R ] sys-libs/glibc-2.16.0 USE="(multilib) -debug -gd (-hardened) -profile (-selinux) -systemtap -vanilla" VC sql / # emerge -pqv '=sys-devel/gcc-4.6.3' [ebuild R ] sys-devel/gcc-4.6.3 USE="cxx fortran mudflap (multilib) nls nptl openmp (-altivec) -bootstrap -build -doc (-fixed-point) -gcj -go -graphite -gtk (-hardened) (-libssp) -multislot -nopie -nossp -objc -objc++ -objc-gc {-test} -vanilla (-nocxx%)" sql / # emerge -pqv '=sys-libs/glibc-2.16.0' [ebuild R ] sys-libs/glibc-2.16.0 USE="(multilib) -debug -gd (-hardened) -profile (-selinux) -systemtap -vanilla" > I suppose the idea is that developers take over
Indeed, this bug seems sufficiently different from the suggested duplicate since you are in a different situation and have shown that the configuration is mostly the same and thus the problem / solution lies elsewhere (and might thus be caused by the openvz container).
I have assigned this bug to the maintainers of gcc and have put the openvz maintainers in CC.
inside the openvz container, run: $ echo 'main(){puts("HI");}' | gcc -m32 -x c - -o a.out $ ./a.out HI (In reply to comment #11) > inside the openvz container, run: > $ echo 'main(){puts("HI");}' | gcc -m32 -x c - -o a.out > $ ./a.out > HI sql / # echo 'main(){puts("HI");}' | gcc -m32 -x c - -o a.out sql / # ./a.out -bash: ./a.out: No such file or directory (In reply to comment #12) your install is broken then if you want to use a multilib profile, then you must have a glibc & gcc built & installed w/multilib support, as well as the kernel support enabled. if any of those pieces are missing, then that simple test will fail with "no such file or directory". *** This bug has been marked as a duplicate of bug 437496 *** (In reply to comment #13) > (In reply to comment #12) > > your install is broken then > > if you want to use a multilib profile, then you must have a glibc & gcc > built & installed w/multilib support, as well as the kernel support enabled. > > if any of those pieces are missing, then that simple test will fail with "no > such file or directory". > > *** This bug has been marked as a duplicate of bug 437496 *** Well I can understand the logic in that, but what I don't understand is why this becomes an issue now but haven't been so before, because I haven't changed anything, just updated from one version to the other, same USE flags as with the previous build and both gcc and glibc have built once, but then don't build again. If my install is broken it must have become so then when glibc-2.16.0 and/or gcc-4.6.3 built the first time, not building properly and how do I get out of this catch-22? I still cannot see how this is a dupe of bug 437496, more than an easy way out... This is clearly openvz releated or the hw node would have been broken too. (In reply to comment #14) i don't know anything about openvz. i don't see anything broken on the toolchain side. |