emerge -e system has stop for the third time (first was because which-2.19 need readline, second because of app-text/xmlto-0.0.18). Reproducible: Always Steps to Reproduce: 1. Installing from scratch gentoo 2007.0 stage1 2. using emerge -e system as standard procedure (there will be problem with "which" and "xmlto" also reported) 3. emerege -s system breaks on "sys-apps/attr-2.4.39", because of some problems with libexpat. 3a. launched attr ebuild manualy in this moment also failes. Actual Results: emerge -e system breaks. Expected Results: emerge -e system will finish with success without breaks I have checked if there is expat installed and I see it is, but in expat-2.0.1 ebuild I have found information: #============================= pkg_postinst() { ewarn "Please note that the soname of the library changed!" ewarn "If you are upgrading from a previous version you need" ewarn "to fix dynamic linking inconsistencies by executing:" ewarn "revdep-rebuild -X --library libexpat.so.0" } #============================================================= I have tried to use "revdep-rebuild -X --library libexpat.so.0" but revdep-rebuild is not recognized at this stage of installation!!! Here is emerge build output: #============================================================ (...) === man5 === gmake[2]: Nothing to be done for `default'. === doc === gmake[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. /bin/gzip --best -c < CHANGES > CHANGES.gz === ea-conv === gmake[2]: Nothing to be done for `default'. === po === gmake[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. /usr/bin/xgettext --language=C --keyword=_ -o attr.pot ../attr/attr.c ../getfattr/getfattr.c ../setfattr/setfattr.c ../libattr/attr_copy_fd.c ../libattr/attr_copy_file.c /usr/bin/xgettext: error while loading shared libraries: libexpat.so.0: cannot open shared object file: No such file or directory gmake[1]: *** [attr.pot] Error 127 make: *** [default] Error 2 [31;01m*[0m [31;01m*[0m ERROR: sys-apps/attr-2.4.39 failed. [31;01m*[0m Call stack: [31;01m*[0m ebuild.sh, line 49: Called src_compile [31;01m*[0m environment, line 2494: Called die [31;01m*[0m The specific snippet of code: [31;01m*[0m emake || die [31;01m*[0m The die message: [31;01m*[0m (no error message) [31;01m*[0m [31;01m*[0m If you need support, post the topmost build error, and the call stack if relevant. [31;01m*[0m A complete build log is located at '/var/tmp/portage/sys-apps/attr-2.4.39/temp/build.log'. [31;01m*[0m The ebuild environment file is located at '/var/tmp/portage/sys-apps/attr-2.4.39/temp/environment'. [31;01m*[0m #================================================================ My use flags: USE="mmx sse sse2 ipv6 unicode cjk bzip2 doc -X nls skey socks5 gmp acl pcre smartcard ldap" and arch.: CFLAGS="-march=i686 -mmmx -msse -msse2 -msse3 -mfpmath=sse -O2 -pipe -fomit-frame-pointer" CXXFLAGS="${CFLAGS}" CHOST="i686-pc-linux-gnu" What should I do to force the installation going (it is the third time I am runing emerge -e system and it is broken), I do not want to run all other ebuilds manualy.
stage1 installs are totally unsupported. *** This bug has been marked as a duplicate of bug 128069 ***
The problem was with USE flag "acl", for te first time in stage1 it is better not to use it to fulfil emerge -e system. because sys-devel/gettext-0.17 with acl requires sys-apps/acl-2.2.45 and acl requires sys-apps/attr-2.4.39, but unfortunately sys-apps/attr-2.4.39, requires sys-devel/gettext-0.17. So we need first emerge sys-devel/gettext-0.17 without acl USE flag. It is also good to do "emerge app-portage/gentoolkit" before "emerge -e system", so you can use for example: revdep-rebuild -X --library libexpat.so.0
(In reply to comment #1) > stage1 installs are totally unsupported. It is why I am using Gentoo, not other distro. I hope stage1 tar.bz2 file will be provided also in future releases. I have used it for the first time in 2004 on my notebook and also now for my VIA low power consumption platform and wish to use stage1 always when need. Nothing more :) Thanks for help (link to duplicated problem).
We don't and won't support stage1 installs; the tarballs are provided solely as a by-product of release media.
(In reply to comment #4) > We don't and won't support stage1 installs; the tarballs are provided solely as > a by-product of release media. Good, so I hope those tar.bzips will be always by-product of release madia. Anyway thanks once more for your todays support at bugzilla (wish not to catch more bugs today).