libtool (2.4.7, and earlier versions) pass -nostdlib to the linker
command. This would seem to cause ASAN/UBSAN libraries not to be
linked, and a situation of unresolved symbols arises.
Commit a5c6466528c060cc4660ad0319c00740db0e42ba certainly feels right
(hence the "earlier versions"), but
Given certain circumstances, libtool 2.4.2 fails to install a library.
(a) The target directory spec contains a trailing slash
(b) The library to install is linking to another just-built one in a
different path.
$ cat Makefile
AC_INIT([foo], [0])
AM_INIT_AUTOMAKE([foreign])
AC_PROG_CC
LT_INIT
When -export-symbols-regex is passed to libtool (for example
in the systems source), it generates a version map that gold
does not like:
$ make
make --no-print-directory all-recursive
Making all in .
/bin/sh ./libtool --tag=CC --mode=link gcc-4.9 -std=gnu99 -pipe -Wall
-Wextra -Wno-inline
---
doc/libtool.texi |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/libtool.texi b/doc/libtool.texi
index f7787f6..c06ddaa 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -1696,7 +1696,7 @@ not
libdir='/tmp/usr/local/lib'
@end example
-@code{inst-prefix} is
On Monday 2013-01-28 17:18, Peter Rosin wrote:
On 2013-01-28 14:07, Jan Engelhardt wrote:
@@ -1696,7 +1696,7 @@ not
libdir='/tmp/usr/local/lib'
@end example
-@code{inst-prefix} is also used to insure that if the installed
+@code{inst-prefix} is also used to ensure that if the installed
Much to my disappointment, I found that the newly-released libkmod v5
has made the following non-trivial change to its source tree, the latter
of which I want to bring to attention:
commit e479598b7d19ae7be45bf5329d6e4df32d646c16
diff --git a/Makefile.am b/Makefile.am
On Wednesday 2012-02-08 03:45, Peter O'Gorman wrote:
On 02/07/2012 07:06 PM, Lucas De Marchi wrote:
Yes. We can always learn. It seems that this is not the case here.
There are other projects releasing like this and no one pointed out to
a reasonable argument against it. That means these
Hi,
I have seen one project where Makefile.am used
ACLOCAL_AMFLAGS = -Im4
and libtool 2.2.6b still threw the warning
Consider adding -I m4 to Makefile.am
which is because libtool does not seem to handle bundled arguments.
Jan
___
Author: Jan Engelhardt jeng...@medozas.de
Date: Sun Oct 25 13:26:58 2009 +0100
Create symlinks to all API versions and set soname to highest
-version-info 23:0:1 will create a libfoo.so.22.1.0 and there is a
symlink libfoo.so.22 to it, so that programs originally linked for
v22 continue to work
On Wednesday 2009-07-29 07:15, Ralf Wildenhues wrote:
Although, we probably should communicate more clearly that tar is a
prerequisite of libtoolize. I didn't know there existed a distro that
doesn't have tar in its base setup though.
Well, it was not a base setup, because qemu, for some
Errors are worst when there is no message explaining why
it could not copy it.
(libtool 2.2.6)
# libtoolize --copy --force --verbose
libtoolize: putting auxiliary files in `.'.
libtoolize: can not copy `/usr/share/libtool/config/ltmain.sh' to `./'
libtoolize: Not copying `m4/argz.m4', libltdl
Hi,
when one has a program that does something like
if(strcmp(argv[0], gunzip) == 0)
uncompress();
else
compress();
and this program also uses a libtool library, then the - lets use this
example - just-built gzip file will be around 4 kilobytes only, it is
a libtool wrapper
On Friday 2009-07-24 13:56, Eric Blake wrote:
when one has a program that does something like
if(strcmp(argv[0], gunzip) == 0)
uncompress();
else
compress();
GNU Coding Standards frown on this practice:
http://www.gnu.org/software/automake/manual/standards.html#User-Interfaces
On Sunday 2009-05-03 18:58, John Calcote wrote:
It appears that Libtool is smart enough to detect ridiculous cases, but it
should probably throw an error of some sort, rather than simply generate
code with a different version number.
Since libtool is just a linker as far as is considered here,
On Monday 2009-02-23 10:45, Ralf Wildenhues wrote:
[...]
So it's back to the drawing and testing board for the patch. One of
the problems is that
- for the prefer one type of library but not the other we might have
to drop the switches for libraries which don't match,
- for the require one
On Monday 2009-02-16 19:56, Ralf Wildenhues wrote:
is it somehow possible to specify that only a given set of libraries is
supposed to be linked in statically into a program? Something along the
lines of...
bin_PROGRAMS = foo bar
foo_LDADD = libabc.la -( -static libdef.la -) libghi.la
Hi,
is it somehow possible to specify that only a given set of libraries is
supposed to be linked in statically into a program? Something along the
lines of...
bin_PROGRAMS = foo bar
foo_LDADD = libabc.la -( -static libdef.la -) libghi.la
bar_LDADD = libdef.la libghi.la
(assuming
Hi,
I noticed that different platforms get different filenames, e.g.
for -version-info 16:0:2:
Linux, libfoo.so.14.2.0
NetBSD, libfoo.so.16.0
FreeBSD, libfoo.so.16
I looked at the libtool source and found
freebsd-elf)
major=.$current
versuffix=.$current;
On Monday 2008-11-03 22:59, Ralf Wildenhues wrote:
* Ralf Wildenhues wrote on Mon, Nov 03, 2008 at 09:14:31AM CET:
* Jan Engelhardt wrote on Mon, Nov 03, 2008 at 07:39:56AM CET:
Is not that what libtool is supposed to cover up? Maybe not for every
make invocation à la `make LD=zzzld
Hi,
I have two libraries in paths that are not searched by default (e.g.
/opt/foo/lib). So I have this in my pkgconfig files:
foo.pc: Libs: -L${libdir} -lfoo
bar.pc: Libs: -L${libdir} -lbar
The linker will find -lfoo,-lbar and successfully create the output file
-- which is an .la library
On Sunday 2008-11-02 20:22, Bob Friesenhahn wrote:
On Sun, 2 Nov 2008, Jan Engelhardt wrote:
I have two libraries in paths that are not searched by default (e.g.
/opt/foo/lib). So I have this in my pkgconfig files:
foo.pc: Libs:-L${libdir} -lfoo
bar.pc: Libs:-L${libdir
Hi Ralf,
On Sunday 2008-11-02 21:56, Ralf Wildenhues wrote:
* Jan Engelhardt wrote on Sun, Nov 02, 2008 at 05:24:27PM CET:
I have two libraries in paths that are not searched by default (e.g.
/opt/foo/lib). So I have this in my pkgconfig files:
foo.pc: Libs:-L${libdir} -lfoo
22 matches
Mail list logo
