Running an uninstalled executable
Hello, in an autoconf+automake+libtool C++ project containing only one program, I want to run the executable before installing it. Reading the manual I thought that it could be done with libtool --mode=execute program_binary but it fails, since there are undefined references to shared libraries not installed in standard directories. Can libtool solve this problem for me? -- Alberto ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Running an uninstalled executable
David writes: > El Tue, 12 May 2015 11:38:42 +0200 > Alberto Luaces escribió: >> Hello, >> >> in an autoconf+automake+libtool C++ project containing only one >> program, I want to run the executable before installing it. >> >> Reading the manual I thought that it could be done with >> >> libtool --mode=execute program_binary >> >> but it fails, since there are undefined references to shared libraries >> not installed in standard directories. >> >> Can libtool solve this problem for me? >> > > In order to use libraries not installed, but present in another > directory (non standard), you have to use LD_LIBRARY_PATH > > http://stackoverflow.com/questions/695530/why-do-i-have-to-define-ld-library-path-with-an-export-every-time-i-run-my-appli > > Something like: LD_LIBRARY_PATH=/path/to/your/custom/library libtool > --mode=execute program_binary > > I think this is not related to libtool, but how bash and shared > libraries works though > Thanks, David. I was hoping that libtool set LD_LIBRARY_PATH for me. -- Alberto ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Running an uninstalled executable
Bob Friesenhahn writes: > On Tue, 12 May 2015, Alberto Luaces wrote: > >> Hello, >> >> in an autoconf+automake+libtool C++ project containing only one program, >> I want to run the executable before installing it. >> >> Reading the manual I thought that it could be done with >> >> libtool --mode=execute program_binary >> >> but it fails, since there are undefined references to shared libraries >> not installed in standard directories. >> >> Can libtool solve this problem for me? > > Libtool is supposed to solve this problem automatically for libraries > in the build-tree built using libtool, or involved libraries which > have a correct associated ".la" file. It is not uncommon for the .la > files that libtool installs to be deleted, or for libraries to be put > into a location other than the paths the .la file says they reside. > > If the installed libraries violate the libtool expectations, then > there are only the choices of building the software with a hard-coded > run-path (-RLIBDIR or -Wl,-rpath,/libdir'), or using environment > variables like LD_LIBRARY_PATH. > > As a developer, I find using the run-path to be most > reliable/convenient, but this may not be suitable when creating > packaged binaries for installation. Thanks, Nick and Bob. So the key point is the existence of the .la files. To sum it up, I would say: * From a developer point of view, when having a test suite depending on libraries installed in non-standard places, LD_LIBRARY_PATH, -rpath and -R are suitable candidates. * From an user point of view, when making tests with an uninstalled executables, it could be interesting to write those .la files by hand (seems easy!) in order for libtool to find them at link time. The second point is an internal hack, I do not want to mean that it is a suitable procedure for distribution purposes. -- Alberto ___ https://lists.gnu.org/mailman/listinfo/libtool
Trouble upgrading to 2.2.6a
Hello,
I have recently updated my system, so now I have new versions of the
Autotools:
autoconf 2.64-2
automake 1:1.11-1
libtool 2.2.6a-4
I have a simple testcase where libtool fails to do the linking of a tiny
executable, here is the process:
$ ls
configure.ac Makefile.am test1.c
$ autoreconf -vfi
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
autoreconf: running: /usr/bin/autoconf --force
autoreconf: configure.ac: not using Autoheader
autoreconf: running: automake --add-missing --copy --force-missing
autoreconf: Leaving directory `.'
$ mkdir build && cd build
$ ../configure
[...] skipped configure output
$ ls
config.log config.status libtool Makefile
$ make
gcc -DPACKAGE_NAME=\"test1\" -DPACKAGE_TARNAME=\"test1\" -
DPACKAGE_VERSION=\"0.9.0\" -DPACKAGE_STRING=\"test1\ 0.9.0\" -
DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"test1\" -
DVERSION=\"0.9.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -
DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -
DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -
DLT_OBJDIR=\".libs/\" -I. -I.. -g -O2 -MT test1.o -MD -MP -MF
.deps/test1.Tpo -c -o test1.o ../test1.c
mv -f .deps/test1.Tpo .deps/test1.Po
/bin/bash ./libtool --tag=CC --mode=link gcc -g -O2 -o test1 test1.o
./libtool: line 827: X--tag=CC: command not found
./libtool: line 860: libtool: ignoring unknown tag : command not found
./libtool: line 827: X--mode=link: command not found
./libtool: line 994: *** Warning: inferring the mode of operation is
deprecated.: command not found
./libtool: line 995: *** Future versions of Libtool will require --mode=MODE
be specified.: command not found
./libtool: line 2239: X-g: command not found
./libtool: line 2239: X-O2: command not found
./libtool: line 2408: Xtest1: command not found
X: user not authorized to run the X server, aborting.
./libtool: line 2420: Xtest1: command not found
./libtool: line 2428: mkdir /.libs: No such file or directory
mkdir: cannot create directory `/.libs': Permission denied
make: *** [test1] Error 1
I have searched on the web and it seems that the problem is a mismatch with
the libtool templates. However, I haven't been able to find any outdated
template on my system:
$ cd ..
$ aclocal --verbose 2>&1 | grep AC_PROG_LIBTOOL
aclocal: found macro _AC_PROG_LIBTOOL in /usr/share/aclocal/lt~obsolete.m4: 71
aclocal: found macro AC_PROG_LIBTOOL in /usr/share/aclocal/libtool.m4: 102
$ dpkg -S /usr/share/aclocal/lt~obsolete.m4
libtool: /usr/share/aclocal/lt~obsolete.m4
$ dpkg -S /usr/share/aclocal/libtool.m4
libtool: /usr/share/aclocal/libtool.m4
How can I keep trying to know what is happening?
I'm attaching the small testcase.
Thank you,
Alberto
AC_INIT([test1], [0.9.0])
AM_INIT_AUTOMAKE([-Wall -Werror foreign])
AC_PROG_LIBTOOL
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
bin_PROGRAMS = test1
test1_SOURCES = test1.c
#include
int main()
{
printf("works!\n");
return 0;
}
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Trouble upgrading to 2.2.6a
Hi Bob,
On Martes, 8 de Septiembre de 2009 04:20:15 Bob Friesenhahn escribió:
> >>> I have searched on the web and it seems that the problem is a mismatch
> >>> with the libtool templates. However, I haven't been able to find any
> >>> outdated template on my system:
> >>
> >> The outdated templates or files may be in your source tree.
> >
> > The only files present in my source tree are those three that I sent. Can
> > any of the Autotools look in parent directories?
>
> Autotools only look in their own installation trees, or in the source
> tree at Makefile.am and below. Never above. Pay attention to any
> extra path information passed to aclocal.
In fact, after a lot of tests I found quite the contrary, but it can also be a
bug. I ended uninstalling the autotools from Debian, in case they had left any
older file from previous versions and compiling autoconf, automake and libtool
from the git repositories. The behavior was the same, after the "autoreconf -
vfi", no ltmain.sh was copied into the directory.
I followed the strace of libtoolize on two different located source trees and
found that this program looks for install.sh or install-sh in the parent and
the grandparent directory. Here are two straces, one from a source tree with a
install-sh in its grandparent directory and another which does not:
=[with]==
stat("./install-sh", 0x7fffa4d70780)= -1 ENOENT (No such file or
directory)
stat("./install.sh", 0x7fffa4d70750)= -1 ENOENT (No such file or
directory)
stat("../install-sh", 0x7fffa4d70780) = -1 ENOENT (No such file or
directory)
stat("../install.sh", 0x7fffa4d70750) = -1 ENOENT (No such file or
directory)
stat("../../install-sh", {st_mode=S_IFREG|0755, st_size=13663, ...}) = 0
=[with]==
=[without]
stat("./install-sh", 0x7fff04083cf0)= -1 ENOENT (No such file or
directory)
stat("./install.sh", 0x7fff04083cc0)= -1 ENOENT (No such file or
directory)
stat("../install-sh", 0x7fff04083cf0) = -1 ENOENT (No such file or
directory)
stat("../install.sh", 0x7fff04083cc0) = -1 ENOENT (No such file or
directory)
stat("../../install-sh", 0x7fff04083cf0) = -1 ENOENT (No such file or
directory)
stat("../../install.sh", 0x7fff04083cc0) = -1 ENOENT (No such file or
directory)
=[without]
If those files are not found, everything works well. If one of them is, then
no ltmain.sh is copied and the building system is messed up.
I don't know Autotools internals, so I don't know if I should file a bug or if
it is my mistake...
Alberto
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Trouble upgrading to 2.2.6a
El Miércoles, 9 de Septiembre de 2009ES 19:56:22 Kurt Roeckx escribió: > This is a typical behaviour of mixing libtool 1.5 and 2.2 parts. > You probably have some aclocal.m4 file or simular somewhere still > containing 1.5 macro's. This is true in many cases, as I have seen from many other people. However this time, the failure depends on the existence of a "install-sh" file in the parent or the grandparent of the source directory. If it is present, the following files are *not* generated during the autoreconf call: config.guess config.sub depcomp install-sh ltmain.sh missing I came to this conclusion by inspecting the strace of libtool, which I have posted on the other reply. This behavior sounds more strange to me as time passes, so I'm going to write a bug report. Alberto ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Trouble upgrading to 2.2.6a
Hello Ralf, El Sábado, 12 de Septiembre de 2009ES 07:20:48 Ralf Wildenhues escribió: > Well, not really. libtoolize has > > if test -n "$ac_auxdir"; then > # If $configure_ac contains AC_CONFIG_AUX_DIR, check that it was > # not given in terms of a shell variable! > [...] > else > # Try to discover auxdir the same way it is discovered by configure. > # Note that we default to the current directory. > for dir in . .. ../..; do > if test -f "$dir/install-sh"; then > [...] > > and the configure behavior mentioned in that comment is documented in > 'info Autoconf Input'. > > Question is, whether the libtoolize behavior is desirable, and if so, > then we should document it, and if not, we should change the code. I understand now. Since this is not a bug, I'm not filling one. In my case there is no problem removing parent install-sh's, because they were in my testing stuff directory, not in any real project. Regards, Alberto ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Getting executable to link to libtool-built library
David Bruce writes: > OK, I can get it to work post-installation with either LD_LIBRARY_PATH > or the ldconfig+/etc/ld.so.conf mechanism. What I want to learn is > the "right" way to do this as a programmer/packager from an autotools > perspective so that a user can do "./configure; make; sudo make > install" on my lib package (libt4kcommon)and on my executable package > (tuxmath) and have it work. This is user responsibility; if the user installs a library in some directory, the user has also to tell its system to look for libraries there. For example, in my Debian system, /usr/local/lib is included by default in the directories' list to be looked at when searching libs. > Ideally, I would like to be able build a tarball that has both the lib > and executable for standalone installation, but have them be > packagable separately for e.g. Debian. Perhaps this is where nested > packages fit in? Maybe I should move this to the Autoconf list? Debian packagers can split the tarball compilation results in as many packages as they wish, so I think only one tarball is fine unless the program or the library are going to have a wildly different rate of development. -- Alberto ___ http://lists.gnu.org/mailman/listinfo/libtool
