| Summary: | kde-base/arts-3.4.3-r1 / KDELIB do not emerge | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Henri Magnin <henri.magnin> |
| Component: | [OLD] KDE | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | 2006.0 | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | /var/tmp/portage/arts-3.4.3-r1/work/arts-1.4.3/config.log | ||
|
Description
Henri Magnin
2006-08-13 03:37:58 UTC
Created attachment 94117 [details]
/var/tmp/portage/arts-3.4.3-r1/work/arts-1.4.3/config.log
This is the log file of the ebuild while compiling.
*** This bug has been marked as a duplicate of 67166 *** (In reply to comment #2) > > *** This bug has been marked as a duplicate of 67166 *** > Sorry probably did not search deep enough in the bugs db. SORRY BUT I REOPEN !!!! This has been marked as "SOLVED" and duplicate of 67166, BUT : - I don't clearly see THE solution in 67166 (even, somebody changed some hardware ???!!!! ;-0 ) - I re-emerged the glibc (using THE version proposed by the latest PORTAGE), and USEing 'nptlonly' (i.e. USE="nptlonly" emerge glibc). This is OK, but when emerging kdebase, ... the kdelibs DO NOT COMPILE Is there a FIX for this issue ? If yes, what is it ? NB: I am currently running successfully a 2005.0 on the hardware where I expect a 2006.0, and.... ... don't expect at all to change some hardware !!! -HMag (In reply to comment #4) > - I re-emerged the glibc (using THE version proposed by the latest PORTAGE), > and USEing 'nptlonly' (i.e. USE="nptlonly" emerge glibc). This is OK, That is not OK. Add 'nptlonly' into your /etc/make.conf and `emerge -uDN world` And upgrade your glibc to latest stable (2.3.6-r4) before filing glibc-related bugs. (In reply to comment #6) > And upgrade your glibc to latest stable (2.3.6-r4) before filing glibc-related > bugs. > Thanks guru :-)... This exactly what I say I did, and I actually did, before filing this glibc-related bug. :-)) (In reply to comment #5) > (In reply to comment #4) > > - I re-emerged the glibc (using THE version proposed by the latest PORTAGE), > > and USEing 'nptlonly' (i.e. USE="nptlonly" emerge glibc). This is OK, > That is not OK. Add 'nptlonly' into your /etc/make.conf and `emerge -uDN world` > Thanks a lot for this precision that I did not find in the bug discussions. I launch this tonight and tell you about the final results ASAP. - HMag SORRY AGAIN ! NOT RESOLVED ! I did as advised by very positive and value added comment #5 : QUOTE That is not OK. Add 'nptlonly' into your /etc/make.conf and `emerge -uDN world` END QUOTE This has been OK, BUT... The KDELIB does not emerge again !!! Please READ the output from the makefile below, before tagging bugs as RESOLVED as a reflex !!!. NOTE - If I may suggest, it is probably not related to glibc but to the ebuild or to the makefile ?! ============================================================= rep: /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/libstdc++.la: No such file or directory /bin/sed: can't read /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/libstdc++.la: No such file or directory libtool: link: `/usr/lib/gcc/i686-pc-linux-gnu/3.4.5/libstdc++.la' is not a valid libtool archive make[4]: *** [kspell_aspell.la] Error 1 make[4]: Leaving directory `/var/tmp/portage/kdelibs-3.5.2-r6/work/kdelibs-3.5.2/kspell2/plugins/aspell' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/var/tmp/portage/kdelibs-3.5.2-r6/work/kdelibs-3.5.2/kspell2/plugins' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/kdelibs-3.5.2-r6/work/kdelibs-3.5.2/kspell2' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/kdelibs-3.5.2-r6/work/kdelibs-3.5.2' make: *** [all] Error 2 !!! ERROR: kde-base/kdelibs-3.5.2-r6 failed. Call stack: ebuild.sh, line 1539: Called dyn_compile ebuild.sh, line 939: Called src_compile kdelibs-3.5.2-r6.ebuild, line 127: Called kde_src_compile kde.eclass, line 164: Called kde_src_compile 'all' kde.eclass, line 323: Called kde_src_compile 'myconf' 'configure' 'make' kde.eclass, line 319: Called die !!! died running emake, kde_src_compile:make !!! If you need support, post the topmost build error, and the call stack if relevant. ============================================================= (In reply to comment #9) > rep: /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/libstdc++.la: No such file or > directory > /bin/sed: can't read /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/libstdc++.la: No such > file or directory > libtool: link: `/usr/lib/gcc/i686-pc-linux-gnu/3.4.5/libstdc++.la' is not a > valid libtool archive Could you please `emerge -pv gcc glibc libstdc++-v3` and post the output here? Henri, please have a look at http://www.gentoo.org/doc/en/gcc-upgrading.xml#doc_chap5 Updates affecting GCC or system libs aren't trivial, but this doesn't make it a (KDE) bug. And I don't need to receive emails twice :) (In reply to comment #11) > Henri, please have a look at > http://www.gentoo.org/doc/en/gcc-upgrading.xml#doc_chap5 > Updates affecting GCC or system libs aren't trivial, but this doesn't make it a > (KDE) bug. You are right, I initially posted this bug as a KDE one because it occurred when emerging KDE. But now it is clearly related to gcc or glibc. What is the best category for this ? If required, I will reclassify in the proper 'component'. I will also read gcc-upgrading.xml#doc_chap5. This while, please note that I am not in an upgrading process. I simply wanted to create a fresh new environment (in a chroot) : - starting from scratch with a Stage3, - then SYNCing the portage tree, - then upgrading portage, - and then emerging KDE This is why I should (theoretically) not have any 'upgrade' issue... Nevertheless I will read the doc anyway. - HMag (In reply to comment #11) > Henri, please have a look at > http://www.gentoo.org/doc/en/gcc-upgrading.xml#doc_chap5 > Updates affecting GCC or system libs aren't trivial, but this doesn't make it a > (KDE) bug. Reading this, I have thoughts... I am creating a 2006.0 from scratch in a chrooted environment : $ mount -o bind /proc 2006.0/proc $ mount -o bind /sys 2006.0/sys $ mount -o bind /dev 2006.0/dev $ chroot 2006.0 /bin/bash $ env-update $ source /etc/profile Doing this, I am really running the CHROOTED environment, but using the "father's" kernel, /proc, /sys and /dev. => Is there any risk that in the KDELIB build process, some configuration operations use data from the "live" kernel, or from the "live" /proc, /sys or /dev ??? ...In this case, the build could misconfigure some parameters because of informations go from the wrong source... (In reply to comment #13) > What is the best category for this ? Just use the component "Ebuilds" and the bug wranglers will assign (or dismiss) your bug reports (hopefully) correctly. >If required, I will reclassify in the proper 'component'. No, please leave it as it is. There won't be happen anything about this. Since building and upgrading a system from sources is not always trivial, you have to learn and to live with the pitfalls, when using a distribution like Gentoo. >=> Is there any risk that in the KDELIB build process, some configuration >operations use data from the "live" kernel, or from the "live" /proc, /sys or >/dev ??? There are for sure packages, which rely on specific kernel features, but KDE should build fine. (In reply to comment #10) > (In reply to comment #9) > > rep: /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/libstdc++.la: No such file or > > directory > > /bin/sed: can't read /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/libstdc++.la: No such > > file or directory > > libtool: link: `/usr/lib/gcc/i686-pc-linux-gnu/3.4.5/libstdc++.la' is not a > > valid libtool archive > > > Could you please `emerge -pv gcc glibc libstdc++-v3` and post the output here? > ================================== HERE IT IS ================================== asus / # emerge -pv gcc glibc libstdc++-v3 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-devel/gcc-3.4.6-r1 USE="fortran gtk nls -bootstrap -boundschecking -build -doc -gcj -hardened -ip28 -ip32r10k -multislot -nocxx -nopie -nossp -objc -test -vanilla" 0 kB [ebuild R ] sys-libs/glibc-2.3.6-r4 USE="nls nptl nptlonly -build -erandom -glibc-compat20 -glibc-omitfp -hardened -profile" 0 kB [ebuild R ] sys-libs/libstdc++-v3-3.3.4 USE="nls nptl -build" 0 kB Total size of downloads: 0 kB - HMag I insist again, being sure this is a bug. I sync'ed and upgraded Portage, performed --update -DN world, and does not work yet. No further answer to my last comment (in response to a question). I would like at least to know what I'm doing wrong if this is the case. Note that I had not such problems to get a 2005.0 up and running on the same hardware. Appendix to comment #16 : /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/ does not exist but after --update -DN I have a complete /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/ directory. This is obviously not a kde bug but a pathing problem in your system. Check your /etc/env.d. Jakub, please assign this to the herd that can handle this. (In reply to comment #9) > This has been OK, BUT... The KDELIB does not emerge again !!! > > Please READ the output from the makefile below, before tagging bugs as RESOLVED > as a reflex !!!. NOTE - If I may suggest, it is probably not related to glibc > but to the ebuild or to the makefile ?! OMG, STOP SHOUTING or fix your caps lock! And stop recycling this bug for multiple completely unrelated problems. > libtool: link: `/usr/lib/gcc/i686-pc-linux-gnu/3.4.5/libstdc++.la' is not a fix_libtool_files.sh 3.4.5; emerge -1 libtool There's bug 73435 with only 178 duplicates, you know. Pretty hard to find, huh? *** This bug has been marked as a duplicate of 67166 *** |
