Linking wxGTK-2.4.2 against GTK2 causes unpredictable behaviour as described in the provided URL. Unicode support is buggy and causes large memory leaks. The ebuild should at least ewarn that this is the case since these are generally undesirable. For example, xmule depends on wxGTK, however when it is linked against GTK2 it runs at high cpu usage (~20%) after several hours. When linked against GTK1.2, it runs at low cpu usage (~2%). Reproducible: Always Steps to Reproduce: 1.emerge wxGTK with GTK2 2.emerge package depending on wxGTK (ex. xmule) 3.run program for several hours Actual Results: program consumed inordinate amounts of cpu Expected Results: ewarn about buggy support for GTK2 and unicode
Accidentally mis-filed this comment under another wxGTK bug. Running into bug #102921, I think we've a related issue. The audacity ebuild refuses to run if it sees unicode support compiled into wxGTK. The problem is, regardless of whether I enable unicode for wxGTK or not, (using 2.6.1), it seems to compile it in - wx-config --cppflags shows unicode support, according to audacity, and if I force audacity around that check, it fails compilation, as would be expected with wxGTK/unicode.
(In reply to comment #0) > Linking wxGTK-2.4.2 against GTK2 causes unpredictable behaviour > as described in the provided URL. That URL is changed for 2.6 now. > Unicode support is buggy and causes large memory leaks. This was fixed somewhere in 2.5 versions. Most prominent leak was coming from each wxMemoryDC constructiong, which I fixed long time ago. Other leaks others had fixed during 2.5 cycle. > Expected Results: > ewarn about buggy support for GTK2 and unicode Closing as WONTFIX (due to lack of a OUTOFDATE resolution) as a) all amule's in tree depend on wxGTK-2.6* by now b) 2.4 is going out of the tree as soon as possible (bug 145032), and fixing things in it isn't a worthwhile time investment. Thanks for the report though, and sorry that there was no-one to take care of this back when wxGTK 2.4 was still relevant.
