Re: noinst_bindir
Hi Bob, Russ, * Russ Allbery wrote on Sun, Apr 30, 2006 at 05:34:53AM CEST: Bob Rossi [EMAIL PROTECTED] writes: noinst_bin_PROGRAMS = gdbmi_driver noinst_bindir = $(top_builddir)/progs Try using $(abs_top_builddir) instead. I've always had bad luck with relative paths and anything that involves libtool. Libtool explicitly forbis relative paths because, portably, you can't put libraries in paths other than the ones specified, and can't move them around. Luckily those systems are less used today. (I know you know this, Russ; in fact, I'm citing (you?) here) Hmm. Maybe libtool should be less anal about relative paths when it comes to installing programs. Actually, I don't know what noinst_bin_PROGRAMS is supposed to mean. noinst means it should not be installed; bin means it should be installed in $(bindir). The fact that Automake outputs an install rule for this and doesn't die complaining looks awfully like an Automake bug to me. Or maybe it's just that the prefix rules have the priority the other way round (match longest prefix first), gotta go and check. Do you actually want 'make install' to copy into the build tree, a binary linked against the installed libraries? Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
dependency_libs?
Hi, I build my library with GNU autotools and link to it with the pkg-config --uninstalled option without installing it. In this case a la-file (libmhgui.la) is created. I've some problems to understand how libtool generated the dependency_libs field. In my package is a --with-x/--without-x option from AC_PATH_X. But the la-file has the X libraries in its dependency_libs field. So how does libtool generate this field? see this file build on Gentoo Linux: # libmhgui.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.5.22 (1.1220.2.365 2005/12/18 22:14:06) ... # Libraries that this one depends upon. dependency_libs=' -L/tmp/animorph/lib /tmp/animorph/lib/libanimorph.la /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.la -L/usr/i686-pc-linux-gnu/bin -L/usr/i686-pc-linux-gnu/lib -L/usr/lib/gcc-lib/i686-pc-linux-gnu/../../../i686-pc-linux-gnu/l ib /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/../../..//libglut.la /usr/lib/libGL.la -L/usr/lib /usr/lib/libGLU.la -lXxf86vm / usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/../../..//libGLU.la -lGL -lSM -lICE -lXmu -lXt -lXi -lpthread /usr/lib/gcc-lib/i686- pc-linux-gnu/3.3.6/../../..//libGL.la -lX11 -lXext -ldl -lpng /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6//libstdc++.la' I don't like the link to -lX* if I use --without-x! And it's interesting that if I build the same application on Debian, I get another (working!!) libmhgui.la: # libmhgui.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.5.6 (1.1220.2.95 2004/04/11 05:50:42) Debian: 224 $ ... # Libraries that this one depends upon. dependency_libs=' /home/andreas/src/MakeHuman/cvs/animorph/src/libanimorph.la -l glut -lGLU -lGL -lpng This is what I expect for dependency_libs! So why is the result on Gentoo wrong? Please pay attention to the different libtool versions. May this be a problem? And in the Debian case is also a relink_command field in libmhgui.la. Please try to explain me this libtool magic. regards Andreas ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: noinst_bindir
On Sat, Apr 29, 2006 at 08:34:53PM -0700, Russ Allbery wrote: Bob Rossi [EMAIL PROTECTED] writes: I have noinst_bin_PROGRAMS = gdbmi_driver noinst_bindir = $(top_builddir)/progs Try using $(abs_top_builddir) instead. I've always had bad luck with relative paths and anything that involves libtool. noinst_bin_PROGRAMS = gdbmi_driver noinst_bindir = $(abs_top_builddir)/progs Unfortunatly, that doesn't work either. test -z /progs || mkdir -p -- /progs mkdir: cannot create directory `/progs': Permission denied make[2]: *** [install-noinst_binPROGRAMS] Error 1 make[2]: Leaving directory `/home/bob/cvs/gdbmi/builddir/src' make[1]: *** [install-am] Error 2 make[1]: Leaving directory `/home/bob/cvs/gdbmi/builddir/src' make: *** [install-recursive] Error 1 Is this a misuse of the autotools on my part? or a bug in libtool? Thanks, Bob Rossi ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: noinst_bindir
On 2006-04-30, Bob Rossi [EMAIL PROTECTED] wrote: Unfortunatly, that doesn't work either. test -z /progs || mkdir -p -- /progs mkdir: cannot create directory `/progs': Permission denied abs_top_builddir isn't set in the Makefile (with automake 1.8.5, and I can't see a ChangeLog entry in 1.9.6 saying this has changed), so make replaces $(abs_top_builddir) with the empty string. However @abs_top_builddir@ is substituted, so you should be able to do: abs_top_builddir = @abs_top_builddir@ noinst_bin_PROGRAMS = gdbmi_driver noinst_bindir = $(abs_top_builddir)/progs Cheers, Olly ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: noinst_bindir
On Sun, Apr 30, 2006 at 12:05:57PM +, Olly Betts wrote: On 2006-04-30, Bob Rossi [EMAIL PROTECTED] wrote: Unfortunatly, that doesn't work either. test -z /progs || mkdir -p -- /progs mkdir: cannot create directory `/progs': Permission denied abs_top_builddir isn't set in the Makefile (with automake 1.8.5, and I can't see a ChangeLog entry in 1.9.6 saying this has changed), so make replaces $(abs_top_builddir) with the empty string. However @abs_top_builddir@ is substituted, so you should be able to do: abs_top_builddir = @abs_top_builddir@ noinst_bin_PROGRAMS = gdbmi_driver noinst_bindir = $(abs_top_builddir)/progs Hi Olly, That does work. I'm using automake 1.9.5. This does fix the problem I'm seeing. Is there any difference between using abs_top_builddir vs top_builddir? Will things stop working for my users that used to work? Finally, is this a bug that libtool doesn't handle relative paths? Thanks, Bob Rossi ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: noinst_bindir
On Sun, Apr 30, 2006 at 08:18:34AM -0400, Bob Rossi wrote: Is there any difference between using abs_top_builddir vs top_builddir? The former has an absolute path, while the latter may not (in fact for builddir I think it never will; for srcdir, the non-abs_ versions may also in fact be absolute). Will things stop working for my users that used to work? I don't think it would, but it's always wise to test changes... Finally, is this a bug that libtool doesn't handle relative paths? I'm not sure my opinion counts for much, but I'd tend to think it's a feature rather than a bug (for installation paths that is). Cheers, Olly ___ http://lists.gnu.org/mailman/listinfo/libtool
fail.at failing on HP-UX
I'm getting the following test failure from HEAD on HP-UX 11.23/PA:
$ gmake check-local TESTSUITE_FLAGS=15 -v
...
fail.at:54: if $LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o a a.$OBJEXT; then
(exit 1); else :; fi
stderr:
/usr/ccs/bin/ld: Unsatisfied symbols:
main (Not referenced yet! Probably due to -u option)
stdout:
libtool: link: cc -z +O2 +Olit=all +Onofltacc +Oentrysched +Odataprefetch
+Onolimit -o a a.o
fail.at:55: test -f a || test -f a$EXEEXT
fail.at:55: exit code was 0, expected 1
15. fail.at:22: FAILED (fail.at:55)
The code in tests/fail.at:
echo 'int not_main(void) { return 0; }' a.c
$CC $CPPFLAGS $CFLAGS -c a.c
FAIL_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o a a.$OBJEXT])
AT_CHECK([test -f a || test -f a$EXEEXT], [1])
$ echo 'int not_main(void) { return 0; }' a.c
$ cc -c a.c
$ sh /opt/build/libtool/libtool --mode=link cc -o a a.o
libtool: link: cc -o a a.o
/usr/ccs/bin/ld: Unsatisfied symbols:
main (Not referenced yet! Probably due to -u option)
However, even though there is no main, `a' is still created. How do we
work around this?
--
albert chin ([EMAIL PROTECTED])
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: noinst_bindir
Bob Rossi [EMAIL PROTECTED] writes: noinst_bin_PROGRAMS = gdbmi_driver noinst_bindir = $(abs_top_builddir)/progs Unfortunatly, that doesn't work either. test -z /progs || mkdir -p -- /progs mkdir: cannot create directory `/progs': Permission denied Well, that makes it look like abs_top_builddir isn't actually getting set. I'm not sure exactly what would cause that. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: dependency_libs?
On Sun, 30 Apr 2006, Russ Allbery wrote: # Libraries that this one depends upon. dependency_libs=' /home/andreas/src/MakeHuman/cvs/animorph/src/libanimorph.la -l glut -lGLU -lGL -lpng I expect that one of glut, GLU, and GL depend on the X libraries, and hence when libtool resolves transitive dependencies through the .la files, it pulls in the other libraries. This is one of the problems with .la files currently. It doesn't have the correct semantics to distinguish between static builds (and builds on platforms with deficient shared library handling) where all transitive dependencies have to be pulled into the link line and shared builds on modern platforms where transitive dependencies do not have to be pulled in and in fact generally *shouldn't* since they make library migrations harder. In this particular case, it would not matter much if libtool simply applied the X11 libraries out of spite due to it knowing that GLUT depends on X11, or if the OS applied the libraries due to transitive dependencies. The result still does not work unless the X11 libraries are involved. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: fail.at failing on HP-UX
On Sun, Apr 30, 2006 at 05:09:23PM +0200, Ralf Wildenhues wrote: * Albert Chin wrote on Sun, Apr 30, 2006 at 05:00:46PM CEST: I'm getting the following test failure from HEAD on HP-UX 11.23/PA: However, even though there is no main, `a' is still created. How do we work around this? Yes. I didn't finish this when I saw it, several weeks ago. Bob suggested removing the binary in mode=link when an error occurred, I am hesitant as the binary may still be useful for the clueful developer. If cc doesn't remove it, libtool definitely should not. OTOH another `make' may erroneously report nothing to do, depending on whether the binary appears in the current directory or in .libs/. That's ok, as, if they were using cc, they would encounter the same problem. Can we XFAIL it for now on *-hpux*? How do I do this? -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
