# emerge x11-base/xorg-x11-7.0-r1 ... ... ... make[1]: Leaving directory `/var/tmp/portage/libXt-1.0.2/work/libXt-1.0.2' make: *** [all] Error 2 !!! ERROR: x11-libs/libXt-1.0.2 failed. Call stack: ebuild.sh, line 1539: Called dyn_compile ebuild.sh, line 939: Called src_compile ebuild.sh, line 1248: Called x-modular_src_compile x-modular.eclass, line 327: Called x-modular_src_make x-modular.eclass, line 322: Called die !!! emake failed !!! If you need support, post the topmost build error, and the call stack if releva nt.
Created attachment 91218 [details] My emerge --info
> !!! If you need support, post the topmost build error Well sorry, but you did cut off all the important info.
Created attachment 91219 [details] emerge libXt
(In reply to comment #2) > > !!! If you need support, post the topmost build error > > Well sorry, but you did cut off all the important info. > Sorry, someone was daydreaming...
Created attachment 91223 [details] emerge libXt -- complete
Created attachment 91224 [details] emerge libXt -- complete
(Re)emerge x11-libs/libSM...
Created attachment 91226 [details] Emerge x11-libs/libSM Reemergeing x11-libs/libSM fails!
(In reply to comment #8) > Created an attachment (id=91226) [edit] > Emerge x11-libs/libSM > > Reemergeing x11-libs/libSM fails! Do the same for libICE.
OK, what I did: emerge libXt => fails emerge libSM => fails emerge -e xorg-x11 did it! But I don't know why ;-) Soo now emerging libICE didn't made any difficulties. I should have made this before "emerge -e xorg-x11".
Good to hear that it's fixed. Still not sure what's causing this...
Created attachment 93093 [details] configure log checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for x86_64-pc-linux-gnu-g77 option to produce PIC... -fPIC checking if x86_64-pc-linux-gnu-g77 PIC flag -fPIC works... yes checking if x86_64-pc-linux-gnu-g77 static flag -static works... yes checking if x86_64-pc-linux-gnu-g77 supports -c -o file.o... yes checking whether the x86_64-pc-linux-gnu-g77 linker (/usr/x86_64-pc-linux-gnu/bin/ld -m elf_x86_64) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking for x86_64-pc-linux-gnu-pkg-config... no checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for XT... configure: error: Package requirements (sm x11 xproto kbproto) were not met: No package 'x11' found No package 'kbproto' found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables XT_CFLAGS and XT_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. !!! Please attach the following file when filing a report to bugs.gentoo.org: !!! /var/tmp/portage/libXt-1.0.2/work/libXt-1.0.2/config.log !!! ERROR: x11-libs/libXt-1.0.2 failed. Call stack: ebuild.sh, line 1539: Called dyn_compile ebuild.sh, line 939: Called src_compile ebuild.sh, line 1248: Called x-modular_src_compile x-modular.eclass, line 329: Called x-modular_src_configure x-modular.eclass, line 316: Called econf '--prefix=/usr' '--datadir=/usr/share' ebuild.sh, line 541: Called die !!! econf failed !!! If you need support, post the topmost build error, and the call stack if relevant.
This appears to just be a problem with the dependency graph portage builds. When I emerged libXt directly without packages that depend on libXt it got all the dependencies in the right order and compiled fine. The errors and log above (in my previous post) were during a fresh AMD64 install. I'd suggest either reopening the bug or making a new one, but with my past experiences here I'm guessing the consensus will just be that users are smart enough to figure out what dependencies are missing and emerge them themselves.
(In reply to comment #13) > experiences here I'm guessing the consensus will just be that users are smart > enough to figure out what dependencies are missing and emerge them themselves. > I think so ;) This is a semi-known problem, and there are some Portage patches that are supposed to alleviate some cases of this problem. However, it appears that sometimes packages don't install all their files. This headache should only happen once, since we're sticking with modular after this point.
