Symbol not found: _g_content_type_get_mime_dirs with gi-gtk on MacOS

[sgronblo]

I am trying out https://owickstrom.github.io/gi-gtk-declarative/ and was trying to follow the instructions for using it on MacOS.

I add the following to dependencies in package.yaml: gi-gtk, gi-gtk-declarative, gi-gtk-declarative-app-simple

I followed the instructions for installing system dependencies for MacOS here: https://github.com/haskell-gi/haskell-gi#installation

Specifically installing the three required packages using brew and setting the PKG_CONFIG_PATH=/usr/local/opt/libffi/lib/pkgconfig

Next when I try to run stack build, the process encounters the following error:

<command line>: can't load .so/.DLL for: /Users/sam/.stack/snapshots/x86_64-osx/lts-13.19/8.6.4/lib/x86_64-osx-ghc-8.6.4/libHSgi-gio-2.0.19-7OCgNZnEEEh4XbhFBPrEBZ-ghc8.6.4.dylib (dlopen(/Users/sam/.stack/snapshots/x86_64-osx/lts-13.19/8.6.4/lib/x86_64-osx-ghc-8.6.4/libHSgi-gio-2.0.19-7OCgNZnEEEh4XbhFBPrEBZ-ghc8.6.4.dylib, 5): Symbol not found: _g_content_type_get_mime_dirs

I ran nm -gu /Users/sam/.stack/snapshots/x86_64-osx/lts-13.19/8.6.4/lib/x86_64-osx-ghc-8.6.4/libHSgi-gio-2.0.19-7OCgNZnEEEh4XbhFBPrEBZ-ghc8.6.4.dylib | grep _g_content_type_get_mime_dirs which lists the symbol as existing in this dylib file.

I'm not sure if the problem is caused by stack, brew or haskell-gi but I raise the issue here to start the investigation.

[garetxe]

Thanks for the report.

Perhaps you have an old version of libgio (without the symbol) laying around? Try searching for all copies of libgio-2.0 in your system, and make sure that the one that stack is picking up (no idea how to check this in MacOS, sorry) does have the symbol. For instance, in my system (Fedora):

$ nm -D /usr/lib64/libgio-2.0.so | grep g_content_type_get_mime_dirs
00000000000c85d0 T g_content_type_get_mime_dirs

[sgronblo]

Hey, thanks for the response. I think you might be on to something. I found out where libgio is on my system and confirmed that it doesn't contain _g_content_type_get_mime_dirs. There are a couple of mysteries to solve now:

• Your symbol doesn't start with an underscore, mine does. Is this relevant?
• Your libgio version is also claiming to be version libgio-2.0 same as mine. How come mine has different contents? Different compile time macros?
• Why does it seem like my stack error message is blaming my libHSgi-gio-2.0.19-7OCgNZnEEEh4XbhFBPrEBZ-ghc8.6.4.dylib file instead of my libgio-2.0.dylib file? Is it just a poorly written error message coming from dlopen?

Finally I ran otool -L on /Users/sam/.stack/snapshots/x86_64-osx/lts-13.19/8.6.4/lib/x86_64-osx-ghc-8.6.4/libHSgi-gio-2.0.19-7OCgNZnEEEh4XbhFBPrEBZ-ghc8.6.4.dylib which lists /usr/local/opt/glib/lib/libgio-2.0.0.dylib as a dependency. I confirmed this file does not have _g_content_type_get_mime_dirs

Who is responsible for maintaining libgio?

[sgronblo]

Ok, did some more digging around. A few more questions came up:

• The source code for gio in glib has a comment saying /*< private *>/ for the two functions in gcontenttype.c that are not visible in my /usr/local/opt/glib/lib/libgio-2.0.0.dylib. Could it be that some dylib build step chooses to not expose the private functions? If so, why is it showing for you?
• I also checked the source for haskell-gi and tried to find any mention of g_content_type_get_mime_dirs but couldn't find anything. Maybe this is auto-generated anyway?

Wild guess: the libHSgi-gio package is generated based on the contents of libgio.so which might have been built without somehow respecting that some functions are private. The dylib version is somehow built without the private functions?

[garetxe]

Thanks for doing the digging! I think I can make a guess based on that: if you look to the source of gio, in https://gitlab.gnome.org/GNOME/glib/blob/master/gio/meson.build#L331, you will find that a different version of g_content_type is compiled in MacOS:
https://gitlab.gnome.org/GNOME/glib/blob/master/gio/gosxcontenttype.m
which does not have the problematic g_content_type_get_mime_dirs.

On the other hand, the gi-gio bindings are based on the introspection data, which is taken from some .gir file, in linux this is /usr/share/gir-1.0/Gio-2.0.gir. Could you check if the corresponding file in your system contains a reference to g_content_type_get_mime_dirs? For example mine says:

    <function name="content_type_get_mime_dirs"
              c:identifier="g_content_type_get_mime_dirs"
              version="2.60">
...
    </function>

If you have something similar in yours then it is a bug in gio (the introspection data refers to symbols that don't exist), and should be reported upstream.

In the meanwhile, while the upstream bug is there, we can easily add a workaround in gi-gio itself.

[sgronblo]

Ok, I was able to find two locations on my system containing a Gio-2.0.gir file: /usr/local/Cellar/gobject-introspection/1.60.1/share and /usr/local/share/gir-1.0

Both of them have the same reference to g_content_type_get_mime_dirs

So you are saying that the gir file on my system contains this symbol, but my dylib doesn't right? And this should be reported to... the glib maintainers?

[garetxe]

Thanks for checking!

So you are saying that the gir file on my system contains this symbol, but my dylib doesn't right?

Yes. The bindings are generated from the .gir file (mostly), but they refer to symbols in the dylib. If they differ, you see the kinds of errors here.

And this should be reported to... the glib maintainers?

Yes, indeed. You can report it here. Thanks for doing this!

In the meanwhile I'll add a workaround in gi-gio itself. (It might take me a few days, though. Please poke me in a bit if you don't see movement here.)

[sgronblo]

Thanks, would love to try gi-gtk so hope you can get around to adding the workaround.

By the way. I submitted an issue for this here: https://gitlab.gnome.org/GNOME/glib/issues/1791

[garetxe]

I just uploaded gi-gio-2.0.21 which I believe should fix this issue. Could you please git it a try, and let me know if it works for you?

[sgronblo]

Do I need to overwrite any other version dependencies? I tried adding gi-gio-2.0.21 to my extra-deps section of stack.yaml. Then I ran stack build again, but now I get the following error:

Could not find module ‘Data.GI.Base.GClosure’
        Perhaps you meant
          Data.GI.Base.Closure (from haskell-gi-base-0.21.5)
          Data.GI.Base.GValue (from haskell-gi-base-0.21.5)

Is this an indication that the version of gi-gtk in my Stack snapshot is incompatible with gi-gio 2.0.21?

[garetxe]

If you can, I would recommend upgrading to the latest nightly (https://www.stackage.org/nightly-2019-06-08), as this has the latest versions of everything you need.

Alternatively, you can add the latest versions of haskell-gi, haskell-gi-base and gi-* to your stack.yaml:

- haskell-gi-0.22.2
- haskell-gi-base-0.22.1
- gi-atk-2.0.18
- gi-cairo-1.0.20
- gi-gdk-3.0.19
- gi-gdkpixbuf-2.0.20
- gi-gio-2.0.22
- gi-glib-2.0.20
- gi-gobject-2.0.19
- gi-gtk-3.0.29
- gi-gtk-hs-0.3.7.0

[sgronblo]

Thanks. Finally found some time to try this again. I was able to build and run a simple gi-gtk app on MacOS using the snapshot you suggested. 🙇

[garetxe]

Great, thanks for checking! Closing then, thanks for the report.

[coponhub]

@garetxe I got same error message in windows msys2/mingw64.

C:\sr\snapshots\c5f79bd0\lib\x86_64-windows-ghc-8.4.3\gi-gio-2.0.18-4RVnkaocmoN5NmSA5Zls5R\HSgi-gio-2.0.18-4RVnkaocmoN5NmSA5Zls5R.o: unknown symbol 'g_content_type_set_mime_dirs'

Is it the same as this problem ?

[garetxe]

@coponhub Thanks for the report. Yes, indeed it seems like the same problem. I have just pushed 6585431, which should fix the issue, and should appear in the next version of gi-gio in hackage.

In the meanwhile, a workaround is to edit Gio-2.0.gir (not entirely sure where this is located in Windows, in linux it is typically in /usr/share/gir-1.0) to remove reference to these symbols.