GNOME Bugzilla – Bug 630993
g-ir-scanner ignores -L commandline option (PATCH)
Last modified: 2017-05-04 21:32:06 UTC
It should add them to the commandline.
Created attachment 171417 [details] [review] Propagate -L options to the link commandline.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
Created attachment 172015 [details] [review] More complete -L option handling. Previous patch is correct, but unfortunately incomplete, because it allowed linking introspection binary against libraries in custom directories, but these libs were not found when actually running compiled introspection binary. This bug is also a generalization of solution of bug #625195. Unfortunately, this is still not complete solution for platforms with linker without -rpath support, i.e. windows/cygwin.
I'd like to reopen this bug, but somehow don't know how to get it to reopened state, so I'm moving it back to 'unconfirmed'.
Review of attachment 172015 [details] [review]: Hmm...so one issue with this is that we'll be adding rpaths for all of the pkg-config libraries too, which seems wrong to me. Can you describe in what case you were having a problem?
Also note that this code changed again with the patch from bug 631348 I just committed.
(In reply to comment #5) > Hmm...so one issue with this is that we'll be adding rpaths for all of the > pkg-config libraries too, which seems wrong to me. I thought that the patch adds only libraries from self._options.library_paths, which are only libpaths explicitely specified on the g-ir-scanner's commandline by -L option. I can't see how pkg-config's libs get into this list. > Can you describe in what case you were having a problem? Sure. I'm trying to build GI's Regress library locally inside my project. Source files regress.[c|h] are copied into ./tests subdir, and ./tests/libregress.so is successfully built. Then following commandline: g-ir-scanner --no-libtool --namespace=Regress --nsversion=1.0 --include=cairo-1.0 --include=Gio-2.0 -lregress -L tests ./tests/regress.c ./tests/regress.h --output=Regress-1.0.gir successfully creates introsp. executable (linking it against ./tests/libregress.so), bu fails to run it, because ./tests/libregress.so cannot be found. So the patch is based on the logic "if you need the path setting for ld to link against executable, you'll also always need the path setting for ld.so to run that executable afterwards".
(In reply to comment #7) > (In reply to comment #5) > > Hmm...so one issue with this is that we'll be adding rpaths for all of the > > pkg-config libraries too, which seems wrong to me. > > I thought that the patch adds only libraries from self._options.library_paths, > which are only libpaths explicitely specified on the g-ir-scanner's commandline > by -L option. I can't see how pkg-config's libs get into this list. Now I realized that scannermain.py:process_packages() pushes output of pkg-config to options. So you are right and your concern is a valid one, thanks for reminding me. Will have to think about it.
*** Bug 562885 has been marked as a duplicate of this bug. ***
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]
The way gobject-introspection links the dumper binary has been changed — at least twice — since this bug was opened. I think it's safe to call it obsolete.