After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 555293 - --library-path option in g-ir-scanner doesn't actually do anything
--library-path option in g-ir-scanner doesn't actually do anything
Status: RESOLVED FIXED
Product: gobject-introspection
Classification: Platform
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gobject-introspection Maintainer(s)
gobject-introspection Maintainer(s)
Depends on:
Blocks: 555303
 
 
Reported: 2008-10-06 21:11 UTC by Lucas Rocha
Modified: 2015-02-07 16:50 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Dirty patch (604 bytes, patch)
2008-10-06 21:50 UTC, Lucas Rocha 		none Details | Review
Updated patch (818 bytes, patch)
2008-10-07 21:27 UTC, Lucas Rocha 		committed Details | Review

Description Lucas Rocha 2008-10-06 21:11:21 UTC 
Maybe append its values to LPATH env var?
Comment 1 Lucas Rocha 2008-10-06 21:50:38 UTC 
Created attachment 120059 [details] [review]
Dirty patch

Append passed library path to LPATH env var (which will be used by python's find_library call).
Comment 2 Colin Walters 2008-10-07 00:13:24 UTC 
This would be used for applications to scan custom libraries?  Do you know where can I find information about LPATH?
Comment 3 Lucas Rocha 2008-10-07 02:49:38 UTC 
(In reply to comment #2)
> This would be used for applications to scan custom libraries?  Do you know
> where can I find information about LPATH?

Yes. For example, on bug #555296 patch, I wasn't able to put the custom library in a different directory simply because g-ir-scanner (and g-ir-compiler) are not able to find the library in a different path.
Comment 4 Lucas Rocha 2008-10-07 21:27:29 UTC 
Created attachment 120166 [details] [review]
Updated patch

I added a FIXME comment about the not-so-portable use of LPATH.
Comment 5 Johan (not receiving bugmail) Dahlin 2008-10-08 14:13:06 UTC 
What's the difference between LPATH and LD_LIBRARY_PATH?
This needs to be portable across linux/osx/win32?
Comment 6 Lucas Rocha 2008-10-09 14:06:46 UTC 
(In reply to comment #5)
> What's the difference between LPATH and LD_LIBRARY_PATH?
> This needs to be portable across linux/osx/win32?

LPATH is something that gcc uses to find libraries. Looking at the code, it seems that the use of ldconfig is just broken (using -r when it should be using -p?) and this is probably why the use of ldconfig is not working. If ldconfig doesn't find the lib, gcc is used. This is why LPATH makes find_library work here and LD_LIBRARY_PATH is being "ignored". So, in practice, LPATH is a work around for a bug in Python[2].

[1] http://svn.python.org/projects/python/trunk/Lib/ctypes/util.py
[2] The only related bug report in bugs.python.org I could find is this one: http://bugs.python.org/issue3383
Comment 7 Lucas Rocha 2008-10-10 21:26:16 UTC 
Commited in trunk after jdahlin review.
Comment 8 André Klapper 2015-02-07 16:50:00 UTC 
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]