On Sat, Apr 26, 2014 at 09:39:11PM +0200, Rolf Wuerdemann wrote:
> The patch works nice,
Great, I commited a patch to use the libtool-detected shared library
extensions instead of module extension (revs 16158, 16159).
> except the fact that I have to use
> "DYLD_FALLBACK_LIBRARY_PATH". Do you think, you can set up the
> loader to work on ${prefix}/lib instead of /usr/local/lib?
I am somewhat confused abouth the library paths. If you can run
Gwyddion it means the libraries it requires are found by the dynamic
linker. And they are exactly the same libraries and the loading uses
the same search paths as we need for gwy.so – with one exception, a
library search path can be also encoded into the executable. However,
gwy.so is already built with
-Wl,-rpath -Wl,$(libdir)
at least for me, so the path is encoded to gwy.so. If you install the
libraries where you told configure you would do so, no search paths
should need to be set. But maybe I am missing something.
> PS: Might the debian maintainer take also a look? dlopen
> fails for debian wheezy also
This cannot be caused by the extension because shared libraries and
modules are both called ".so" on Linux. It should not be caused by the
library search path either because libraries from a package are
installed into the system lib directory so they must be in the search
path.
Regards,
Yeti
------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
_______________________________________________
Gwyddion-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gwyddion-users
