! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Fails to build with glib 2.27.3
Status:
RESOLVED: FIXED

Comments

Description Lionel Le Folgoc 2010-11-09 23:37:04 CET
Hi,

I just tried to build exo 0.5.4 with glib 2.27, and it fails with the following error:

==8<==

Making all in exo-gio-module
make[3]: Entering directory `/build/mrpouit-exo_0.5.4-0fakesync1-i386-isHffC/exo-0.5.4/exo-gio-module'
  CC     libexo_module_1_la-exo-module.lo
/bin/bash ../libtool --silent --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I.. -DG_LOG_DOMAIN=\"exo-gio-module\" -DLIBDIR=\"/usr/lib/xfce4/exo-1\" -DPACKAGE_LOCALE_DIR=\"/usr/share/locale\" -DLIBEXO_VERSION_API=\"1\"  -DNDEBUG -DHAVE_GNUC_VISIBILITY -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   -pthread -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12   -I/usr/include/xfce4 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   -g -O2  -fPIE  -fstack-protector  -D_FORTIFY_SOURCE=2  -Wformat -Wformat-security  -c -o libexo_module_1_la-exo-module.lo `test -f 'exo-module.c' || echo './'`exo-module.c
exo-module.c:41:88: error: expected ')' before '*' token
exo-module.c:42:88: error: expected ')' before '*' token
exo-module.c: In function 'exo_gio_module_register_type':
exo-module.c:87:1: error: 'exo_gio_module_app_info_lookup_iface_init' undeclared (first use in this function)
exo-module.c:87:1: note: each undeclared identifier is reported only once for each function it appears in
exo-module.c:87:1: error: 'G_TYPE_DESKTOP_APP_INFO_LOOKUP' undeclared (first use in this function)
exo-module.c: At top level:
exo-module.c:115:71: error: expected ')' before '*' token
exo-module.c:123:66: error: expected ')' before '*' token
exo-module.c: In function 'g_io_module_load':
exo-module.c:173:35: error: 'G_DESKTOP_APP_INFO_LOOKUP_EXTENSION_POINT_NAME' undeclared (first use in this function)
exo-module.c: In function 'g_io_module_query':
exo-module.c:190:5: error: 'G_DESKTOP_APP_INFO_LOOKUP_EXTENSION_POINT_NAME' undeclared (first use in this function)
make[3]: *** [libexo_module_1_la-exo-module.lo] Error 1
make[3]: Leaving directory `/build/mrpouit-exo_0.5.4-0fakesync1-i386-isHffC/exo-0.5.4/exo-gio-module'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/build/mrpouit-exo_0.5.4-0fakesync1-i386-isHffC/exo-0.5.4'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/build/mrpouit-exo_0.5.4-0fakesync1-i386-isHffC/exo-0.5.4'

==8<==

23:32 +NSchermer: mr_pouit: yeah i now see they dropped the extension point
23:33 +NSchermer: mr_pouit: could you file a bug in our bugtracker?

Here it is. ;)
Thanks!
Comment 1 Lionel Le Folgoc 2010-11-11 15:58:32 CET
They put it back: http://git.gnome.org/browse/glib/commit/?id=fb94859e84c0b7859a0a5425d461b18e67ea9ac7

This should fix the build failure. Feel free to close this bug (or change it into a "exo shouldn't use deprecated gio-desktop-app-info-lookup extension point).
Comment 2 Nick Schermer editbugs 2010-11-12 09:35:30 CET
They fixed the build failure, but as the commit message says "..but deprecates and does not use it. So no functionality is changed". In other words: it builds, but it is not implemented anymore.

So we somewhere need to implement the new mimetype handling; which, from my first look seems to be easier, because .desktop files are scanned, so we only need to provide .desktop files for the x-scheme-handler/{file,http(s),email} mime types (we already have those, but not with the new mime types and URI handling, but that is easy to fix).

Maybe we also need to convert the preferred apps framework to save it's setting to mimeapps.list. The direct desktop file (ie. write mimetype=Thunar.desktop) would be nice, but for that we need to change the way desktop files are handled within the preferred apps frameworks, which is sometime for 4.10 (bug #6113). So I think we should go with writing "x-scheme-handler/file=exo-file-manager.desktop" and handle the requests through exo-open, so we are sure the supported mime types are handled through exo-open -> preferred apps.

The exo-gio-module can be dropped completely if the user compiles with glib 2.27, so that's nice.

For Jannis: Does Thunar use g_desktop_app_info_lookup_get_default_for_uri_scheme() or only g_app_info_get_default_for_uri_scheme(), because if so; you need to replace the calls.
Comment 3 Jannis Pohlmann editbugs 2010-11-12 12:36:48 CET
It doesn't use any of these calls. It used g_file_query_default_handler() until October 19th, and now uses g_app_info_get_default_for_content_type() first. The reasons are explained in this commit:

commit 8fae46156ce617d3639486e10a3d91b878c75f17
Author: Jannis Pohlmann <jannis@xfce.org>
Date:   Tue Oct 19 15:53:11 2010 +0200

    Change how Thunar picks the default handler for a file (bug #6167).
    
    It appears that g_file_query_default_handler() prefers URI scheme
    handlers over content type handlers. This is inappropriate if we want to
    open a file for which we already know the content type (as is the case
    with most local files).
    
    Using g_file_query_default_handler() as the only way to pick the default
    handler for a file somewhat collides with exo-gio-module, which sets the
    default handler for a few URI schemes, such as http:// and file://.
    
    This was problematic only when launching a file from outside (e.g. by
    running "Thunar <file>" or by calling the D-Bus Launch() method. In
    internal situations, Thunar used thunar_file_list_get_applications()
    which prioritizes the content type.
    
    We now use g_app_info_get_default_for_content_type() first and only fall
    back to g_file_query_default_handler() if the content type is unknown or
    we don't have a default handler for it.
Comment 4 Nick Schermer editbugs 2010-11-13 16:26:16 CET
Fixed in master in commit a581e8e, ecb8a6e and 59214af.

Bug #6800

Reported by:
Lionel Le Folgoc
Reported on: 2010-11-09
Last modified on: 2010-11-13

People

Assignee:
Nick Schermer
CC List:
3 users

Version

Attachments

Additional information