| Summary: | x11-libs/libXt missing x11-libs/libSM dependency | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Andre Gluecksmann <email> |
| Component: | New packages | Assignee: | Gentoo X packagers <x11> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | major | ||
| Priority: | High | ||
| Version: | 2006.0 | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
My emerge --info
emerge libXt emerge libXt -- complete emerge libXt -- complete Emerge x11-libs/libSM configure log |
||
|
Description
Andre Gluecksmann
2006-07-08 10:29:39 UTC
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. |
