Summary: | net-im/kadu-0.6.5.1 needs net-libs/libgadu with pthread USE flag set | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jacek Trubłajewicz <gothic> |
Component: | Current packages | Assignee: | Dawid Węgliński (RETIRED) <cla> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | mateusz, net-im, reavertm |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
kadu-0.6.5.1 build.log
net-libs/libgadu-1.8.2 configure log emerge --info |
Description
Jacek Trubłajewicz
2009-03-14 23:07:49 UTC
Created attachment 185012 [details]
kadu-0.6.5.1 build.log
Created attachment 185013 [details]
net-libs/libgadu-1.8.2 configure log
Created attachment 185014 [details]
emerge --info
Can you please reproduce it with properly set -march for your processor? athlon64 is for amd64 profile as far as i remember. Please set it to athlon-xp and rebuild libgadu, then try to build kadu. It seems that I was misled by this document: http://en.gentoo-wiki.com/wiki/Safe_Cflags/AMD#Athlon_64 which propose setting march=k8 (which I believe is the same as athlon64) for 32bit Athlon 64 environment. Unfortunately, doing as you said and setting march=athlon-xp, rebuilding libgadu and then kadu, doesn't help. Kadu complains with the same error as it did before. It looks like rather libgadu bug than kadu bug. Kadu checks for definition of #define GG_CONFIG_HAVE_PTHREAD in libgadu.h It does it in two places - in CMakeLists.txt (using grep), and in kady-core/gadu,h. First check may return 'true' even if "#define GG_CONFIG_HAVE_PTHREAD" was commented oyt as grep will accept "// #define GG_CONFIG_HAVE_PTHREAD" as found as well, but that's different story. Second check - the one actually valid, is in gadu.h using #ifndef just below #include <libgadu.h>. Kadu already requires libgadu[pthread], so that from kadu ebuild perspective - all requirements are met. Now the question is - why libgadu (1.8.2) for that user doesn't allow setting pthread USE flag (so that #define GG_CONFIG_HAVE_PTHREAD is present in libgadu.h). For the start - try upgrading your system first - especially gcc and glibc to latest stable and then try rebuilding libgadu. Upgrade below packages to: [ebuild R ] sys-devel/binutils-2.18-r3 USE="nls -multislot -multitarget -test -vanilla" 0 kB [ebuild R ] sys-devel/gcc-4.1.2 USE="fortran gtk mudflap nls (-altivec) -bootstrap -build -d -doc -gcj (-hardened) -ip28 -ip32r10k -libffi (-multilib) -multislot (-n32) (-n64) -nocxx -objc -objc++ -objc-gc -test -vanilla" 0 kB [ebuild R ] sys-libs/glibc-2.8_p20080602-r1 USE="nls -debug -gd -glibc-omitfp (-hardened) (-multilib) -profile (-selinux) -vanilla" didn't help and the problem still occurs. (In reply to comment #6) > Now the question is - why libgadu (1.8.2) for that user doesn't allow setting > pthread USE flag (so that #define GG_CONFIG_HAVE_PTHREAD is present in > libgadu.h). But this symbol (GG_CONFIG_HAVE_PTHREAD) actually IS defined in my libgadu.h: /* Defined if libgadu was compiled and linked with pthread support. */ #define GG_CONFIG_HAVE_PTHREAD Finally I found the cause of this problem, it was another libgadu.h placed in /usr/local/include, I think it was remain from some old overlay kadu ebuild. Thanks for your help and sorry for messing around. Ah lol. No problem. I've been preparing my x86 chroot just while ago to figure it out. Thanks you spoted it out. :) Reopen to close it. :/ And close. *** Bug 271211 has been marked as a duplicate of this bug. *** |