GNOME Bugzilla – Bug 612019
Alphabetical sorting not working in OSX Snow Leopard 10.6.x
Last modified: 2012-11-16 17:55:34 UTC
I am using Gimp and Pan in Apple OSX 10.6.x (Snow Leopard). When using the "File -> Open" dialog, it does not sort items in alphabetical order. For example, it will list things in this order: AAA BBB DDD CCC FFF EEE This problem has been researched by a maintainer of Gimp for OSX. It was found that disabling "HAVE_CARBON" in "glib/gunicollate.c" fixes the sorting bug. The thread is here: http://sourceforge.net/tracker/index.php?func=detail&aid=2898204&group_id=211713&atid=1018863 Can you correct this in the mainline glib source and release a new version? Thanks.
Confirming bug and solution from a tester using fink (building everything from source). Carbon isn't 64bit, so shouldn't be using it on that type of platform (need to distinguish "carbon library is available" from "it has routines we can use in selected arch/bitsize" I think?). Or at least some features in the sources need a more direct test for some needed feature rather than piggybacking on the HAVE_CARBON token.
(gimp punted this as NOTGNOME, thinking it was a bug in OSX lib itself rather than a bug or inconsistent handling of a self-sane OSX situation, in Bug #609242)
*** Bug 609242 has been marked as a duplicate of this bug. ***
ping? MacPorts has had to drag this patch along for a long time now. Seems trivial to actually fix it in glib upstream, and the change obviously has no side-effects for linux users.
(a) there is no patch. I guess comment 0 *implies* that the solution is just removing all the ifdef CARBON code, but we don't have machines to test that on, so we don't know. (b) the code was added for a reason. In particular, bug 531403. So, why does that not apply? Do we need the CARBON code for older OS X, and not for newer? (I don't know what our policy is on how far back we care about OS X releases...)
Sorry, thought the patch was already linked. Here's MacPorts's patch: http://trac.macports.org/browser/trunk/dports/devel/glib2-devel/files/patch-glib_gunicollate.c.diff?rev=64477 that implements the change suggested in the comments of 2010-01-24 18:27:10 UTC and 2010-01-26 20:59:48 UTC on the originally-linked SF tracker item. The MacPorts tracker items of theirs to this bugzilla are: http://trac.macports.org/ticket/23959 http://trac.macports.org/ticket/29051 one of which also recommends an #ifdef to only make the change on 64bit builds. It's not too surprising that Carbon isn't working right on 64bit I guess. Wonder if the "bug" is that there's a cast in gunicollate.c that isn't not respectful of some datatype size on 64bit--totally speculating, I don't know the collation-key process at all.
Testing further, that macports patch (avoiding code added in response to Bug #531403) re-activates that bug's behavior (not surprising). In particular, the collation selftest fails. But it fails already even with the carbon use (Bug #644686 ), now just "fails different". sigh
*** Bug 679558 has been marked as a duplicate of this bug. ***
Resolving as duplicate of bug 673047 because the patch attached there was committed. *** This bug has been marked as a duplicate of bug 673047 ***