Created attachment 237215 [details] [review]
GIRepository: add API for extending library paths

Review of attachment 237215 [details] [review]:

I know I filed the gjs application bug, and this came from that, but after thinking about this more:

The thing I don't like about this is that it only works for the one shared library used by the typelib.  But what if you have an introspectable library that depends on a non-introspectable library, and you want to put them both in an app-private libdir?

The app will try to load the first, but the dynamic linker will fail to find the second.

I think the best way to solve this is to set an rpath to your app's private directory.
This is actually *really* easy to do with automake/libtool.

Failing that you can wrapper script LD_LIBRARY_PATH, but the rpath approach works really well.

::: girepository/gitypelib.c
@@ +2066,3 @@
+
+void
+g_irepository_prepend_library_path (const char *directory)

Needs documentation, and Since:

No, prepend_library_path is not an alternative to RPATH, is an addition to one. Of course, it's expected that you use libtool, so the introspectable library will have the private directory in the RPATH and find the non-introspectable one just fine.
(Ok, I did not test this, but it should work according to the manual)

The problem is when you can't modify RPATH. Ie, what I'm trying to achieve is avoiding a compiled binary whose only purpose is the RPATH. It should work with stock gjs-console or python.

(OK, I just found that you can invoke ld.so with --library-path

(In reply to comment #3)
>
> The problem is when you can't modify RPATH. Ie, what I'm trying to achieve is
> avoiding a compiled binary whose only purpose is the RPATH. It should work with
> stock gjs-console or python.

Oh right, duh.  Hrm...ideally there'd be this API, except in glibc.  <looks>  There's this glibc-specific /usr/include/link.h which has a variety of interesting lowlevel API for the dynamic linker.  

Although if we wanted to be a bit more portable, we *could* call setenv("LD_LIBRARY_PATH").  The downside of that is that we must do it before any threads are created.  Except, ew...it would get inherited by child processes =/

Well, if we modified glibc today, we'd still have to wait a while before we could hard-depend on it.  So I'm not opposed to this new API now, but we should at least *consider* modifying glibc.

It's worse than that, LD_LIBRARY_PATH is cached when the dynamic linker is loaded (before main()), so setting it after has no effect.

And even if we modified glibc, we could never hard depend on it to the extent of having gjs or pygobject using that API directly, because they're expect to work on all glib supported platforms, so we would still go through some form of prepend_library_path() in g-i.

(In reply to comment #5)

> And even if we modified glibc, we could never hard depend on it to the extent
> of having gjs or pygobject using that API directly, because they're expect to
> work on all glib supported platforms, so we would still go through some form of
> prepend_library_path() in g-i.

Yeah...but I still feel too often we lose out on the opportunity to add useful features to e.g. glibc because of that.

If it was added to glibc, maybe other libcs eventually would pick it up too..


Anyways, let's get your patch in.  Can you just add a doc comment?

Created attachment 237299 [details] [review]
GIRepository: add API for extending library paths

Previously we would require applications that shipped with private
typelibs to add the private path to LD_LIBRARY_PATH, or to have a
launcher binary with the right RPATH.
Now they can just call GIRepository.prepend_library_path() before
they access the module.

Review of attachment 237299 [details] [review]:

Minor feeling that the change to delete the SHLIB_SUFFIX fallback should be a separate patch, but eh, not a big deal.

ACN after the minor doc comment updates.

::: girepository/gitypelib.c
@@ +2080,3 @@
+ * in this way, loading will fall back to the system library
+ * path (ie. LD_LIBRARY_PATH and DT_RPATH in ELF systems).
+ * See the documentation of your dynamic linkers for full details.

"dynamic linker" parses better

@@ +2081,3 @@
+ * path (ie. LD_LIBRARY_PATH and DT_RPATH in ELF systems).
+ * See the documentation of your dynamic linkers for full details.
+ */

Since: 1.35.8

Attachment 237299 [details] pushed as 9faf4b4 - GIRepository: add API for extending library paths

[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]