Re: Uninstalled interlibrary dependencies
On Tue, Mar 14, 2006 at 03:30:55PM +0100, Magnus Lie Hetland wrote: > > It seems a bit "icky" to use Autotools, and then to slap on an if > statement to choose between DYLD_LIBRARY_PATH and LD_LIBRARY_PATH... > (I guess this might be in the docs, though. I'll have another look > there.) Set them all: DYLD_LIBRARY_PATH=... LD_LIBRARY_PATH=... SHLIB_PATH=... LIBPATH=... \ python ... -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Uninstalled interlibrary dependencies
* Magnus Lie Hetland wrote on Tue, Mar 14, 2006 at 03:30:55PM CET: > On Mar 14, 2006, at 14:24, Peter O'Gorman wrote: > > > >Magnus, > >You'll need to run the python interpreter with the "right" env vars > >set. > >For Mac OS X, env DYLD_LIBRARY_PATH=/path/to/uninstalled/library > >python > >foo, for linux LD_LIBRARY_PATH=/path/to/uninstalled/library python > >etc.. > > Ah. Thanks -- that worked. I didn't think that would work when -rpath > was used -- I guess I should have checked :) Well, as shlibpath_overrides_runpath=yes on darwin, it will cease to work if you have a run path pointing to _installed_ modules, and there are actually some old ones hanging around there. > >Libtool usually generates a wrapper script for uninstalled programs, > >unfortunately, it can not do so for python or other interpreters. > > I see. But is there any support functionality for this sort of thing? > Any way of finding a platform-independent (sort of) environment > variable, for example? You can eval `./libtool --config | grep "^shlibpath_var="` then $shlibpath_var will be the right name. > It seems a bit "icky" to use Autotools, and then to slap on an if > statement to choose between DYLD_LIBRARY_PATH and LD_LIBRARY_PATH... > (I guess this might be in the docs, though. I'll have another look > there.) Well, making this better is a TODO item. I'm collecting use cases at the moment.. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Uninstalled interlibrary dependencies
On Mar 14, 2006, at 14:24, Peter O'Gorman wrote: Magnus, You'll need to run the python interpreter with the "right" env vars set. For Mac OS X, env DYLD_LIBRARY_PATH=/path/to/uninstalled/library python foo, for linux LD_LIBRARY_PATH=/path/to/uninstalled/library python etc.. Ah. Thanks -- that worked. I didn't think that would work when -rpath was used -- I guess I should have checked :) Libtool usually generates a wrapper script for uninstalled programs, unfortunately, it can not do so for python or other interpreters. I see. But is there any support functionality for this sort of thing? Any way of finding a platform-independent (sort of) environment variable, for example? It seems a bit "icky" to use Autotools, and then to slap on an if statement to choose between DYLD_LIBRARY_PATH and LD_LIBRARY_PATH... (I guess this might be in the docs, though. I'll have another look there.) Thanks! Peter -- Magnus Lie Hetland http://hetland.org ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Uninstalled interlibrary dependencies
On Mar 14, 2006, at 14:02, Magnus Lie Hetland wrote: This article and thread has a bit more info on the current state: http://article.gmane.org/gmane.comp.sysutils.automake.general/6921 http://thread.gmane.org/gmane.comp.sysutils.automake.general/6912 OK -- thanks. I'll have a look. I've had a look now. The proposed method (using libtool with -- mode=execute and -dlopen pointing to _foo.la when running the test script/Python) doesn't work, because (as mentioned in [1]) shlibpath_overrides_runpath=yes for the platform I'm working on. I see another "solution" mentioned there (building dummy files) -- doesn't sound like the nicest way out of the situation, really :-} [1] http://article.gmane.org/gmane.comp.gnu.libtool.general/7248 -- Magnus Lie Hetland http://hetland.org ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Uninstalled interlibrary dependencies
On Tue, 2006-03-14 at 14:02 +0100, Magnus Lie Hetland wrote: > > It all works well when I install everything -- because _foo.so refers > to the installed location of libfoo.so. > > > which system are you on? > > Mac O Magnus, You'll need to run the python interpreter with the "right" env vars set. For Mac OS X, env DYLD_LIBRARY_PATH=/path/to/uninstalled/library python foo, for linux LD_LIBRARY_PATH=/path/to/uninstalled/library python etc.. Libtool usually generates a wrapper script for uninstalled programs, unfortunately, it can not do so for python or other interpreters. Peter signature.asc Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Uninstalled interlibrary dependencies
On Mar 14, 2006, at 13:10, Ralf Wildenhues wrote: Hi Magnus, [snip] Do you specify the dependency on libfoo.la at link time? Yes -- I use: _foo_la_LIBADD = $(top_srcdir)/src/libfoo.la It all works well when I install everything -- because _foo.so refers to the installed location of libfoo.so. Which libtool version do you use, 1.5.20 what says `./libtool --config', Uhm. That dumps quite a lot of info... Any particular variables you need? (BTW: I see here that fast_install=needless -- so there's something special about that going on, it seems...) which system are you on? Mac OS X. This article and thread has a bit more info on the current state: http://article.gmane.org/gmane.comp.sysutils.automake.general/6921 http://thread.gmane.org/gmane.comp.sysutils.automake.general/6912 OK -- thanks. I'll have a look. -- Magnus Lie Hetland http://hetland.org ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Uninstalled interlibrary dependencies
Hi Magnus, * Magnus Lie Hetland wrote on Tue, Mar 14, 2006 at 01:04:45PM CET: > > I'm writing a C++ library along with a wrapper for Python (generated > by SWIG), and I'm using Autotools for building it all. The way I > build it, I have one core library, of the form libfoo.la, and one > wrapper library, _foo.la. The _foo.la library (or, rather, _foo.so or > the like) will be dynamically loaded into the Python interpreter. Do you specify the dependency on libfoo.la at link time? > This seems to work nicely ... mostly. But the problem is that I write > my test suite in Python, so I need to dynamically load _foo.so before > installing, and that doesn't seem to be altogether straightforward. > The problem is (as I'm sure you already understand) that _foo.so > refers to the libfoo.la file -- but at the -rpath location. Which libtool version do you use, what says `./libtool --config', which system are you on? > I see that Libtool goes to great lengths to have things work before > installing -- but I haven't been able to make it do what I need. This article and thread has a bit more info on the current state: http://article.gmane.org/gmane.comp.sysutils.automake.general/6921 http://thread.gmane.org/gmane.comp.sysutils.automake.general/6912 Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Uninstalled interlibrary dependencies
Hi! I'm writing a C++ library along with a wrapper for Python (generated by SWIG), and I'm using Autotools for building it all. The way I build it, I have one core library, of the form libfoo.la, and one wrapper library, _foo.la. The _foo.la library (or, rather, _foo.so or the like) will be dynamically loaded into the Python interpreter. This seems to work nicely ... mostly. But the problem is that I write my test suite in Python, so I need to dynamically load _foo.so before installing, and that doesn't seem to be altogether straightforward. The problem is (as I'm sure you already understand) that _foo.so refers to the libfoo.la file -- but at the -rpath location. I see that Libtool goes to great lengths to have things work before installing -- but I haven't been able to make it do what I need. The automatic relinking of executables, for example, doesn't apply. I had some hopes when I discovered the --enable-fast-install=no option, but that didn't do anything either, as far as I can see. When I came across the following quote in the manual, I was rather discouraged: "In the current implementation, libtool libraries may not depend on other uninstalled libtool libraries." Does this mean that I can't do what I'm trying to do -- that is, that there is no switch or mechanism in Autotools (or, more specifically, Libtool) that will make it work? If so, what would be the "best" approach to get a similar effect? I can see a couple of possibilities, at least: - Statically link _foo.la with libfoo.la, so there is no dependency (but a *slight* bloat :) - Do some Automake magic (or just add some instructions to the README file, though that would break distcheck) to run configure and install in a sandbox before testing (rather cumbersome) Any other suggestions or input? -- Magnus Lie Hetland http://hetland.org ___ http://lists.gnu.org/mailman/listinfo/libtool
