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
___
-- Forwarded message --
Date: Tue, 24 May 2011 15:16:36
From: Jan Engelhardt
To: bug-libt...@gnu.org
Cc: Jozsef Kadlecsik, Peter Volkov
Subject: rpath encoded in binary linking a .la-.so file
On Tuesday 2011-05-24 15:01, Peter Volkov wrote via private mail:
>
>>>
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
ind
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 t
---
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
>> +
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 -Wu
On Sunday 2014-02-16 13:26, Jan Engelhardt wrote:
>
>When -export-symbols-regex is passed to libtool (for example
>in the systems source), it generates a version map that gold
>does not like:
>[...]
>$ cat .libs/libgudev-1.0.ver
>
>{ global:
>local: *; };
How to tr
Despite choosing all kinds of -static* options for libtool,
it won't pick $old_library iff $installed=yes. Why is this?
I have produced the following minimal testcase. Using below's
libzz.la, I observe:
$ libtool --mode=link --tag=CXX g++ -o foo -static -all-static libzz.la
libtool: link: g++ -o
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
AC
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 app
. On Win32, -fPIC is always in effect.
Comments please.
Jan Engelhardt
--
___
http://lists.gnu.org/mailman/listinfo/libtool
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:
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:
>>
>>
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 inv
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=".$curren
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 --enable-sha
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
Hi Ralf,
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
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
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 h
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 sc
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
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 no
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 re
Hi,
A paragraph in libtool's info manual section 7.2 ("Libtool's versioning
system") got me thinking:
The dynamic linker is guaranteed that if a library supports
_every_ interface number between FIRST-INTERFACE and
LAST-INTERFACE, then the program can be relinked against
610
Author: Jan Engelhardt
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 with a v23 t
On Sunday 2009-11-01 09:46, Ralf Wildenhues wrote:
>>
>> -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 with a v23 that implements APIs 22–23.
>>
>Wow. This would be a heavy change
On Wednesday 2009-11-04 20:22, Kurt Roeckx wrote:
>On Sun, Oct 25, 2009 at 03:00:27PM +0100, Jan Engelhardt wrote:
>>
>> program: unknown symbol api23_function in libfoo.so.22
>> (or similar wording)
>
>In Debian-based systems there we have 2 solutions for that:
&g
On Wednesday 2009-11-04 20:49, Ralf Wildenhues wrote:
>* Jan Engelhardt wrote on Wed, Nov 04, 2009 at 08:42:00PM CET:
>> What if a symbol has kept its name, yet changed in semantics?
>> The Linux Kernel has a number of features that address these
>> issues for itself,
>
On Wednesday 2009-11-04 21:05, Kurt Roeckx wrote:
>
>> What if a symbol has kept its name, yet changed in semantics?
>
>Then you either shouln't say the API is compatible (and change
>soname), or provide 2 versions of that symbol, like for instance
>libc6 does.
Well let's exclude glibc right from
32 matches
Mail list logo
