When wxGTK is build against GTK+-2.something Xmule fails to build. The solution is to build wxGTK against GTK+-1.x, e.g. put -gtk2 in USE. Xmule should somehow be dependant on that wxGTK is build like this (I dont if this is possible with the possible portage system), or state that wxGTK should be build againt GTK+-1.x to build. Xmule version 1.5.0 as well as 1.5.1 (not yet in portage) is affected. This bug will probably disappear sometime when a better wxGTK is realased (2.4.1 is out, but only 2.4.0 is in portage(This should probably be tested)). Note: If wxGTK is rebuild, wxPython should be rebuild as well (it blows up).
bit scary for me I'm afraid. needs to go to someone with understanding of wxGTK
not gnome, so i'll take it
what does it actually do when you say it fails to rebuild? some terminal output would help.
this is the output I get with my wxGTK built against GTK2: mfc.h:335: candidates are: void CString::Format(const wxChar*, ...) AddFriend.cpp:136: cannot convert `const wxChar*' to `const char*' for argument `1' to `int atoi(const char*)' AddFriend.cpp:136: cannot convert `const wxChar*' to `const char*' for argument `1' to `int atoi(const char*)' AddFriend.cpp:163: cannot convert `const wxChar*' to `const char*' for argument `1' to `int sscanf(const char*, const char*, ...)' make[3]: *** [AddFriend.o] Error 1 make[3]: Leaving directory `/var/tmp/portage/xmule-1.5.1/work/xmule-1.5.1/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/xmule-1.5.1/work/xmule-1.5.1/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/xmule-1.5.1/work/xmule-1.5.1' make: *** [all] Error 2 !!! ERROR: net-p2p/xmule-1.5.1 failed. !!! Function src_compile, Line 22, Exitcode 2 !!! (no error message)
try re-emerge wxGTK and then try again.
Rebuilding wxGTK (still against GTK2) fixes the problem. My question then is why isn't this version (without unicode) marked "r1" ? This bug (and maybe others) wouldn't even exist since people wouldn't have to guess about rebuilding their wxGTK, it would be done automagically.
i consider removing unicode support a regression rather than something that people should be upgrading to. it is a work around until people who write wxwindows apps use their unicode support. for people who have it working already, they would not need to upgrade to -r1 and for those who it doesn't work for, they would have either gone back to GTK1 version of wxGTK or could re-emerge it. wxGTK 2.4.1 is on the wings to be released to portage soon anyway. that will have unicode switched off unless they support both unicode/ascii at the same time.
