This can best be seen by launching a filtered file chooser that is filtering on application/x-executable. Point to a directory with some UNIX executables (e.g. /usr/bin). Then go to /tmp and back to /usr/bin. Most, if not all, of the binaries will now be missing. This is due to symbol conflicts between the xdgmime cache functions in gtk+ and gnome-vfs (i.e. this problem will not be seen if libgnomeui and the gnome-vfs file choose module are not installed). The attached patch protects all of the xdgmimecache functions behind XDG_PREFIX, and seems to fix the problem.
Created attachment 5760 [details] [review] Fix cache symbol conflicts in xdgmimecache
Created attachment 10157 [details] [review] Python test script Thanks for your bug report! I cannot reproduce your issue. The attached python script is a testcase that calls gnome_program_init and constructs a simple file-filtered gtkfilechooser. For me, it always correctly displays the entire directory, which can be proven by running it in a command line, and selecting all files in /usr/bin. If the number stays constant, there is no cache conflict.
This would most likely only be seen on FreeBSD with the way the linker works.
Maybe you could explain the problem a bit more in detail - if we apply such a patch we may want to apply it to ALL private functions (and _caches) instead of just the cache functions. Using XDG_ENTRY for this also problematic as it strips the initial underscore. I'm currently reading http://www.cs.utah.edu/dept/old/texinfo/glibc-manual-0.02/library_1.html and it suggests: "In addition to the names documented in this manual, reserved names include all external identifiers (global functions and variables) that begin with an underscore (`_') and all identifiers regardless of use that begin with either two underscores or an underscore followed by a capital letter are reserved names. This is so that the library and header files can define functions, variables, and macros for internal purposes without risk of conflict with names in user programs." Am I taken right that the problem is that when linking against shared libraries, the FreeBSD linker will also use symbols beginning with a '_' character if they are external?
Created attachment 10165 [details] [review] Proposed patch Do you think this patch is OK? It's vital to maintain the underscore for _xdg_mime_mime_type_equal, _xdg_mime_media_type_equal and _xdg_mime_mime_type_subclass as CVS HEAD has two defined function, one with and the other one without underscore.
This patch does look okay. I agree that patching all of the functions is probably a safer way to go. The problem is that the symbols exported by gnome-vfs collide with those exported by gtk+. This means that static memory is different between the two, and this causes strange behavior in the file selector when the gnome-vfs module is loaded. By strange, I mean MIME types mysteriously change every time you enter a directory, leave it, then come back in again. Files may also be missing as I already said in this bug.
Fixed, closing. Thanks for your help.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.