GNOME Bugzilla – Bug 780309
gio/tests/appinfo build fails: gdesktopappinfo.c skipped on OS X
Last modified: 2017-11-20 10:33:19 UTC
Building glib-2.52.0 on OS X 10.11 was uneventful. Then during 'make check'... /bin/sh ../../libtool --tag=CC --mode=link gcc -Wall -Wstrict-prototypes -Werror=declaration-after-statement -Werror=missing-prototypes -Werror=implicit-function-declaration -Werror=pointer-arith -Werror=init-self -Werror=format-security -Werror=format=2 -Werror=missing-include-dirs -Os -L/sw/lib -Wl,-framework,Carbon -Wl,-framework,Foundation -o appinfo appinfo.o ../../gio/libgio-2.0.la ../../gobject/libgobject-2.0.la ../../gmodule/libgmodule-2.0.la ../../glib/libglib-2.0.la -lintl libtool: link: gcc -Wall -Wstrict-prototypes -Werror=declaration-after-statement -Werror=missing-prototypes -Werror=implicit-function-declaration -Werror=pointer-arith -Werror=init-self -Werror=format-security -Werror=format=2 -Werror=missing-include-dirs -Os -Wl,-framework -Wl,Carbon -Wl,-framework -Wl,Foundation -o .libs/appinfo appinfo.o -L/sw/lib ../../gio/.libs/libgio-2.0.dylib -L/sw/lib/libpcre1 /sw/build.build/glib2-shlibs-2.52.0-1/glib-2.52.0/gobject/.libs/libgobject-2.0.dylib /sw/build.build/glib2-shlibs-2.52.0-1/glib-2.52.0/gmodule/.libs/libgmodule-2.0.dylib -lz -lresolv ../../gobject/.libs/libgobject-2.0.dylib /sw/lib/libffi.dylib ../../gmodule/.libs/libgmodule-2.0.dylib /sw/build.build/glib2-shlibs-2.52.0-1/glib-2.52.0/glib/.libs/libglib-2.0.dylib ../../glib/.libs/libglib-2.0.dylib /sw/lib/libiconv.dylib /sw/lib/libpcre1/libpcre.dylib /sw/lib/libintl.dylib -pthread clang: warning: argument unused during compilation: '-pthread' Undefined symbols for architecture x86_64: "_g_desktop_app_info_get_categories", referenced from: _test_from_keyfile in appinfo.o "_g_desktop_app_info_get_filename", referenced from: _test_from_keyfile in appinfo.o "_g_desktop_app_info_get_generic_name", referenced from: _test_from_keyfile in appinfo.o "_g_desktop_app_info_get_keywords", referenced from: _test_from_keyfile in appinfo.o "_g_desktop_app_info_get_nodisplay", referenced from: _test_from_keyfile in appinfo.o "_g_desktop_app_info_get_startup_wm_class", referenced from: _test_startup_wm_class in appinfo.o "_g_desktop_app_info_new_from_filename", referenced from: _test_basic in appinfo.o _test_launch in appinfo.o _test_show_in in appinfo.o _test_tryexec in appinfo.o _test_startup_wm_class in appinfo.o _test_supported_types in appinfo.o _test_locale in appinfo.o ... "_g_desktop_app_info_new_from_keyfile", referenced from: _test_from_keyfile in appinfo.o ld: symbol(s) not found for architecture x86_64 Those symbols are in glib/gdesktopappinfo.[ch], but glib/Makefile.am has those files controlled by "if !OS_COCOA". I see we do have gosxappinfo.[ch] on this platform, but it appears to supply different function-names.
Same symptom in desktop-app-info.o
Formerly, I thought the solution was simply to use the same "if !OS_COCOA" to omit these tests (skip tests that test code that is skipped). But now I see that the same problem (absence of g_desktop_app_info_* from libgio) causes gio/tests/async-splice-output-stream to fail: /async-splice/copy-chunks-threaded-input: _1_: a dyld: lazy symbol binding failed: Symbol not found: _g_desktop_app_info_lookup_get_type Referenced from: /sw/lib/gio/modules/libgiogconf.so Expected in: /sw/build.build/glib2-shlibs-2.52.0-1/glib-2.52.0/gio/.libs/libgio-2.0.0.dylib dyld: Symbol not found: _g_desktop_app_info_lookup_get_type Referenced from: /sw/lib/gio/modules/libgiogconf.so Expected in: /sw/build.build/glib2-shlibs-2.52.0-1/glib-2.52.0/gio/.libs/libgio-2.0.0.dylib Trace/BPT trap I have /sw/lib/gio/modules/libgiogconf.so installed from gvfs, and that module is linked against the older version of libgio I have installed on my system. In the test, g_file_new_tmp() somehow triggers loading of that module from the live system, but the nature of the libtoolized test environment is that the local libs are inserted into the DYLD search path. So the module on the live system is loading the currently-being-tested local libgio instead of the one on the live system. That live one (older glib suite) *does* have these symbols. Bumping the "importance" because this is now apparently a backwards-incompatible/ABI break.
It should be mentioned that this problem also breaks the build of glibmm 2.50.0
there is probably a bunch of "unix has desktop app info" assumptions all over the place, I'm afraid
The origin seems to be Bug #734946, where a *partial* osx code was added but the *whole* previously-existing code was removed on this platform. Why wasn't this done piece-by-piece, or else with some build-time flag to control whether I want to break interface in a stable release until someone eventually writes the rest of the code? Is it that the pre-existing code is both hopeless and always-been-non-functional?
It wasn't don't piece-by-piece because there is no infrastructure to do 'a little bit of desktop file support with some native on top'. Either you use GDesktopAppInfo, or you don't.
Could we have a ./configure flag to control it?
We could, but I don't think we want to. Whats the motivation here ?
Not breaking ABI. Above you can see reports that this is a visible problem for glibmm and gfvs, and even breaks glib self-testing itself (not just "we forgot to disable a test for an interface we disabled"--easy fix--but "breaking external things that use that interface breaks the test"--cannot be fixed within the test suite).
This was fixed by commit 03c88daa733ee5efe5e78da382f3b6fc8735d44e
As for an option, it might make sense the problem is just that OSX is sort of a grey area. If you look at Windows you have two options being a Windows library or being a Cygwin library. In the latter it makes sense to respect the desktop spec because you are Unix. The problem is OSX is at the same time the same as Unix but also used in a native context like bundles. So we can't go full Win32 and have a G_OS_OSX because half the Unix backends are the same. I really don't know the best solution to any of this; I think getting applications from the system is the best solution for users but obviously breaking ABI in such an unclear way sucks.
Created attachment 349016 [details] [review] build: Don't build dbus-appinfo on OSX Skip another test that fails to build.
I get a total of ~20 separate io/tests/ test-program failures analogous to Comment #2. Although the "cause" is broken ABI, the way that becomes visible is that giomodule is loading modules from the live system even though we're only in a testing environment, which is additionally circular against any older installed version of glib. Would a more proper test harness actually just have giomodule ignore the live system's modules altogether? One route would be to set the GIO_MODULE_DIR env var to a defined value that does not contain any modules, short-circuiting get_gio_module_dir()'s attempts to load whatever it finds.
(In reply to Daniel Macks from comment #13) > I get a total of ~20 separate io/tests/ test-program failures analogous to > Comment #2. Although the "cause" is broken ABI, the way that becomes visible > is that giomodule is loading modules from the live system even though we're > only in a testing environment, which is additionally circular against any > older installed version of glib. Would a more proper test harness actually > just have giomodule ignore the live system's modules altogether? One route > would be to set the GIO_MODULE_DIR env var to a defined value that does not > contain any modules, short-circuiting get_gio_module_dir()'s attempts to > load whatever it finds. Indeed, 'make check TESTS_ENVIRONMENT=GIO_MODULE_DIR=' clears a ton of problems. I have no idea how a blank (but defined!) value there is actually evaluated (whethe there could be interference for out-of-tree building with other random things in the local dir, for example).
Bug 781548 will allow me to avoid breaking ABI.(In reply to Matthias Clasen from comment #8) > We could, but I don't think we want to. Whats the motivation here ? Seems like Bug 781548 is it.
*** Bug 781694 has been marked as a duplicate of this bug. ***
My build failure was fixed by attachment 349016 [details] [review] and it's practically the same patch that I wrote on bug 781694, so this is a vote for committing it; I'm not a GLib reviewer though. Can we backport it to the 2.52 branch too please?
Review of attachment 349016 [details] [review]: sure
Comment on attachment 349016 [details] [review] build: Don't build dbus-appinfo on OSX Attachment 349016 [details] pushed as d4bfee1 - build: Don't build dbus-appinfo on OSX
Thanks, I appreciate it!
(In reply to Matthias Neeracher from comment #3) > It should be mentioned that this problem also breaks the build of glibmm > 2.50.0 Looks like that got filed at Bug #781947
Created attachment 351022 [details] [review] Avoid entanglement with modules not part of build world Per Comment #14
(In reply to Patrick Griffis (tingping) from comment #11) > The problem is OSX is at the same time the same as Unix but also used in a > native context like bundles. So we can't go full Win32 and have a G_OS_OSX > because half the Unix backends are the same. Why not? The tests would not be quite as clean as with G_OS_WIN32, more like the tests with defined(HAVE_COCOA) in giomodule.c. It would still be helpful to glibmm and other modules if HAVE_COCOA in config.h could be replaced by a preprocessor macro in glibconfig.h, named G_OS_OSX or G_OS_COCOA or something else. Then other modules could test for the existence of this macro instead of repeating the configure test done by glib.
(In reply to Kjell Ahlstedt from comment #24) > (In reply to Patrick Griffis (tingping) from comment #11) > > The problem is OSX is at the same time the same as Unix but also used in a > > native context like bundles. So we can't go full Win32 and have a G_OS_OSX > > because half the Unix backends are the same. > > Why not? The tests would not be quite as clean as with G_OS_WIN32, more like > the tests with defined(HAVE_COCOA) in giomodule.c. > It would still be helpful to glibmm and other modules if HAVE_COCOA in > config.h > could be replaced by a preprocessor macro in glibconfig.h, named G_OS_OSX or > G_OS_COCOA or something else. Then other modules could test for the existence > of this macro instead of repeating the configure test done by glib. Well, it wouldn't be an awful thing to do. As you say it is just a less clean case. For example all usage of it would be like: #ifdef G_OS_UNIX #ifndef G_OS_OSX #include <gio-unix.h> #endif #endif It just doesn't have the clean separation that WIN32 does. I do believe it would still have value and no real harm.
Review of attachment 351022 [details] [review]: This is a good catch. Setting GIO_MODULE_DIR to the empty string is the correct way to disable module loading from the system path. Once this patch is updated and pushed, is there anything more to do in this bug? ::: gio/tests/Makefile.am @@ +18,3 @@ +# avoid trying to load modules installed on build machine +TESTS_ENVIRONMENT=GIO_MODULE_DIR= I think this should be: ``` AM_TESTS_ENVIRONMENT += GIO_MODULE_DIR= ``` The AM_ prefix is needed because TESTS_ENVIRONMENT is reserved for the user to set, and we need to use += rather than = because glib-tap.mk already initialises AM_TESTS_ENVIRONMENT for us. The corresponding change also needs to be made to the gio/tests/meson.build file.
Created attachment 364029 [details] [review] Set GIO_MODULE_DIR= in test environment This is purely voodoo on the meson.build as I don't have a platform where I can test it.
Review of attachment 364029 [details] [review]: Looks like the right voodoo to me, thanks.