Re: [gtk-osx-users] g-ir-scanner without libtool on macOS

[John Ralls <jralls ceridwen us>]

> On Feb 5, 2018, at 1:54 AM, Wataru Shimizu <waruzilla gmail com> wrote:
>
> Hi,
>
> I have a question about gobject introspection on macOS.
> (Is this mailing list correct place?)
>
> I'm now trying to build gir from a sample library (libsample.dylib) with
> g-ir-scanner. On macOS, each dylib has "install name", and it's usually
> same as its install path. In my case, install_name is
> /usr/local/lib/libsample.dylib because I plan to install it to there.
> (I'm not sure what it really should be, but other libraries (e.g.
> libgtk-3.0, libglib) installed by homebrew have such install_name).
>
> When I create .gir from libtool library (.la), gir could be generated
> as I expected. However I could not find the way to do it from dylib
> directly.
>
> [with libtool]
> $ glibtool --mode=compile --tag=CC cc -Wall -c \
>  `pkg-config --cflags gobject-2.0` greeter.c
> $ glibtool --mode=link --tag=CC cc -o libsample.la greeter.lo \
>  -rpath /usr/local/lib `pkg-config --libs gobject-2.0`
> $ g-ir-scanner --warn-all --namespace=Sample --nsversion=1.0 \
>  --libtool=glibtool --library=libsample.la --include=GObject-2.0 \
>  --pkg-export=sample --output Sample-1.0.gir greeter.c greeter.h \
>  libsample.la
>
>  => OK, Sample-1.0.gir is generated and it has correct path.
> $ cat Sample-1.0.gir | grep "shared-library"
>             shared-library="/usr/local/lib/libsample.0.dylib"
>
> [without libtool]
> $ gcc -Wall -fPIC -c `pkg-config --cflags gobject-2.0` greeter.c
> $ gcc -dynamiclib -install_name /usr/local/lib/libsample.dylib \
>  -o libsample.dylib greeter.o `pkg-config --libs gobject-2.0`
> $ g-ir-scanner --warn-all --namespace=Sample --nsversion=1.0 \
>  --no-libtool --library=sample --include=GObject-2.0 \
>  --pkg-export=sample --output Sample-1.0.gir greeter.c greeter.h
>
>  => Failed with the following error message.
> ------------------------------------------------------------------------
> dyld: Library not loaded: /usr/local/lib/libsample.dylib
>  Referenced from: /private/tmp/gir-mac-sample/tmp-introspectoN9qXF/Sample-1.0
>  Reason: image not found
> Command '[u'/private/tmp/gir-mac-sample/tmp-introspectoN9qXF/Sample-1.0',
> u'--introspect-dump=/private/tmp/gir-mac-sample/tmp-introspectoN9qXF/functions.txt,/private/tmp/gir-mac-sample/tmp-introspectoN9qXF/dump.xml']'
> returned non-zero exit status -6
> ------------------------------------------------------------------------
>
> I guess a command invoked from g-ir-scanner tried to load /usr/local/lib/
> libsample.dylib, but it hasn't been installed yet.
>
> I found some workarounds,
>  - Create libsample.dylib without "-install_name" option, then modify
>    Sample-1.0.gir manullay
>  - Install libsample.dylib into /usr/local/lib before invoking
>    g-ir-scanner
> but they make the build process (Makefile/CMakeLists.txt) complex.
>
> What is the correct way to generate .gir from non-libtool environment on
> macOS?
>
> To reproduce my problem easier, I uploaded the full source codes and
> command scripts to: https://github.com/wagavulin/gir-mac-sample

No, this isn’t the right place to ask. This mailing list is to support the gtk-osx jhbuild modules,
gtk-mac-bundler, and the gtk-mac-integration library.

But I’ll try to explain what’s going on anyway.

MacOS’s dynamic linker (dyld) primarily uses installed paths to find files to load, and the installed name is 
what gets put in the client’s installed path. That means that if you set the installed name to 
/usr/local/lib/libsample.dylib and use -lsample to compile some other library (a typelib in this case) then 
at runtime the 
dynamic loader is going to look for it in /usr/local/lib. It will then look in other places (see dyld(1) for 
the gory details) and if it doesn’t find it you get the “image not found” error.

You can use `otool -L foo` to list the installed paths to foo’s dependencies and the install_name_tool to 
change both a library’s installed name and the installed paths in libraries and executables.

MacOS provides some special installed path features, @executable_path, @loader_path, and @rpath to allow for 
relocation. Those are also explained in dyld(1).

Regards,
John Ralls