linking
by choosing which objects in the .a they pull in.
Some vague memory also tells me that this is how shared library versioning
is done (with differently named shared objects).
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle
was hardcoded in `hc-minusL', which fooled libtool
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Whoops, sorry, I should add that this was with:
Configuring libtool 1.3e (1.910 2001/04/23 00:34:53)
Russ Allbery [EMAIL PROTECTED] writes:
gcc 2.95.3, SGI native ld.
[...]
FAIL
2.6, Solaris 7, and Solaris 8.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
of 69 tests failed
=
I don't have the time to do specific debugging, but if you want any of
these tests rerun specifically, I can do that and send the output.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle
FAIL: demo-unst.test
FAIL: depdemo-unst.test
FAIL: mdemo-unst.test
FAIL: dryrun.test
FAIL: demo-unst.test
FAIL: depdemo-unst.test
FAIL: demo-unst.test
FAIL: depdemo-unst.test
FAIL: mdemo-unst.test
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle
checking if the linker (/usr/ccs/bin/ld) is GNU ld... no
gcc 2.95.3 in use on both. On both systems:
=
12 of 83 tests failed
=
with the same list of failing tests as Solaris 8.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle
creating helldl
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
PASS: build-relink2.test
===
All 83 tests passed
===
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
libtool [EMAIL PROTECTED] writes:
On Mon, Apr 23, 2001 at 09:10:20AM -0700, Russ Allbery wrote:
I was unable to even get the test suite to complete on this platform;
every time the mdemo tests ran, the program it was running went runaway
and had to be kill -9'd. I got tired of doing
FAIL: demo-exec.test
FAIL: demo-make.test
FAIL: demo-exec.test
FAIL: demo-make.test
FAIL: demo-exec.test
FAIL: demo-inst.test
FAIL: mdemo-make.test
=
19 of 66 tests failed
=
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle
libtool [EMAIL PROTECTED] writes:
On Tue, Apr 24, 2001 at 12:46:33AM -0700, Russ Allbery wrote:
That patch fixed the hang. The test results still aren't pretty.
Apply the fix I posted to libtool-patches. That should bring it down to
6 failures.
I assume that this is the one now
... (cached) no
FAIL: cdemo-make.test
FAIL: demo-make.test
FAIL: depdemo-make.test
FAIL: mdemo-make.test
FAIL: mdemo-exec.test
FAIL: mdemo-inst.test
6 of 66 tests failed
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle
to fix them if they are.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
of the package configuration scripts.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
directories.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
linked binaries by
giving the linker maximum freedom to drop unused code.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
works.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
anymore without Autoconf and
Automake being involved.
I can't comment on using it without Autoconf, but INN uses libtool and
doesn't use Automake. That's not particularly difficult to do, at least
for the simple cases.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle
changed.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Bob Friesenhahn [EMAIL PROTECTED] writes:
I have a copy of libtool-1.5.tar.gz which was retrieved on April 15.
The MD5 checksum is also 0e1844f25e2ad74c3715b5776d017545.
I have a copy dated April 14 with the same MD5 checksum.
--
Russ Allbery ([EMAIL PROTECTED]) http
worried about. I generally have Automake around. Just
as long as I don't have to use Automake for the package itself when I use
libtool, I think this is fine.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
___
Libtool
Nick Twaddell [EMAIL PROTECTED] writes:
How long till the libtool source is posted back on the site?
Looks like it's there now.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
___
Libtool mailing list
[EMAIL PROTECTED
with (often newer) locally
installed static libraries if the operating system happens to come with
some dynamic library by the same name.
What was the reason for this change, or was it accidental?
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle
build
system and a broken build system.
There are ten-year-old binaries that expect a particular SONAME for the X
libraries and can't simply be rebuilt. It's very, very important that
they not break.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle
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.
--
Russ Allbery ([EMAIL PROTECTED]) http
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
is actually the dynamic
linker as such dependencies should be resolved at run-time, *not* at link
time. A linker that does such resolution at link time actually re-adds
most of the problems that libtool currently causes.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle
is much more
targetted and doesn't have the same far-reaching effect.
LD_LIBRARY_PATH can be used safely and many large installations do use it
safely, but it's dangerous and tricky.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle
) cause
the module to be built without an external reference to that symbol, so
then there's nothing to go wrong at runtime.
Note that this will change other linker behavior. Read the GNU ld
documentation for more details on exactly what the option does.
--
Russ Allbery ([EMAIL PROTECTED
libraries.)
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
___
http://lists.gnu.org/mailman/listinfo/libtool
Ralf Wildenhues [EMAIL PROTECTED] writes:
Hello Russ,
* Russ Allbery wrote on Fri, Nov 07, 2008 at 01:20:28AM CET:
The most frequent problem caused by *.la files is that they add a pile
of unnecessary dependencies to shared libraries, which further
entangles package dependencies and makes
Roumen Petrov [EMAIL PROTECTED] writes:
Russ Allbery wrote:
Debian's experience to date is that --as-needed is buggy and breaks a
lot of software, and overall is not a particularly stable solution.
Removing *.la files so that the unneeded shared libraries aren't linked
in the first place
Roumen Petrov [EMAIL PROTECTED] writes:
Russ Allbery wrote:
When you create a libtool library, libtool records every library
against which that library was linked into the *.la file. If you then
link another shared library against that shared library using libtool,
libtool reads that list
. (There would need to be a flag to override
this for the unusual cases where this is required; there are some edge
cases where it's needed, usually involving things like weak symbols or
other corner cases.)
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle
Roumen Petrov [EMAIL PROTECTED] writes:
Russ Allbery wrote:
libreadline is linked against libncurses on Debian.
Which version ?
readline 5.2-3, ncurses 5.7-2.
This is an 7(5?) years old linux bug.
I'm very dubious of that assertion. Applications which use readline but
do not directly use
in another 4% or more of the cases.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
___
http://lists.gnu.org/mailman/listinfo/libtool
linking.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
___
http://lists.gnu.org/mailman/listinfo/libtool
file installed?
That's where libtool gets the metadata required to know when to link to
additional libraries.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
___
http://lists.gnu.org/mailman/listinfo/libtool
library dependencies get so entangled that
it's extremely difficult to correctly handle transitions.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
http://lists.gnu.org/mailman/listinfo/libtool
Bob Friesenhahn bfrie...@simple.dallas.tx.us writes:
On Tue, 25 Aug 2009, Russ Allbery wrote:
Relying on the OS's implicit dependency features seems to be an
approach which is fraught with peril.
Relying on the dynamic linker to resolve implicit dependencies is the
only way that it's really
and more robust to just build two different versions of
somelib, one for each of the alternative dependency libraries. (See, for
instance, how cURL is handled in Debian.)
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle
of the places
where Debian may not remove *.la files depending on the specific
situation.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
http://lists.gnu.org/mailman/listinfo/libtool
work out
why libtool is trying to link against a library that is not being used or
mentioned in the package being built.
It's linking against some other package which has a *.la file that
mentions fontconfig. Grep for fontconfig in the *.la files of all your
installed libraries.
--
Russ
itself properly in the first place.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
http://lists.gnu.org/mailman/listinfo/libtool
list on platforms
that only support that, and suppress it entirely if the linker doesn't
have any relevant capabilities. That would save me a ton of maintenance
burden on some of my packages, and it would then be easy to add a feature
like the above as well.
--
Russ Allbery (r...@stanford.edu
Ralf Wildenhues ralf.wildenh...@gmx.de writes:
* Russ Allbery wrote on Tue, Jun 22, 2010 at 11:00:04PM CEST:
I would dearly, dearly love for libtool to pick up a --version-script
option that would pass in the full version script on platforms with
linkers that understand it, turn
conflicts when multiple versions of a shared library are loaded at the
same time, not to do more sophisticated things like provide multiple
versions of a function bound to different symbol versions.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle
that doesn't require this. Solaris is definitely not one of them. I
believe you may still need this on such platforms as AIX or HP-UX that use
a much different object format, but I'm not at all certain of that; it's
been years since I've used them.
--
Russ Allbery (r...@stanford.edu) http
Russ Allbery r...@stanford.edu writes:
I don't believe this is correct. GNU/Linux does not add implicit
dependencies at link time; it only links with the libraries that you
explicitly list. ELF doesn't require that all symbols be resolved during
the link, only the symbols in the thing
Peter Rosin p...@lysator.liu.se writes:
Russ Allbery skrev 2012-01-07 03:13:
Of which there are very few still in existence in terms of widespread
use, since most systems now use ELF or (like Mac OS X) some other
object format that doesn't require this. Solaris is definitely not one
of them
the *.la files and they're
becoming more and more widespread beyond their initial community and are
well-supported in Autoconf. Although that doesn't address your immediate
issue.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle
should not be
a problem!?
-Wl says to pass the flag verbatim to the linker. It's common to use the
system linker even with non-system compilers.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
https://lists.gnu.org
-bit multiarch system library path.
--
Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
___
https://lists.gnu.org/mailman/listinfo/libtool
it thinks the directory isn't listed in the system
library search path, though.
--
Russ Allbery (ea...@eyrie.org) http://www.eyrie.org/~eagle/
___
https://lists.gnu.org/mailman/listinfo/libtool
r words, this is probably an upstream Makefile issue rather than a
problem with either libtool or dpkg-shlibdeps.
--
Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
___
https://lists.gnu.org/mailman/listinfo/libtool
ever, dpkg-shlibdeps
doesn't care. So maybe this is a problem in that tool where it should be
suppressing that error for your package as well?
You can see the build logs at:
https://buildd.debian.org/status/fetch.php?pkg=webauth=amd64=4.7.0-3%2Bb1=1446816432
--
Russ Allbery (ea...@eyrie.org)
that behavior. Changing it
would break things, rather horribly.
(This is somewhat afield of the original issue, though, which was a change
from RPATH to RUNPATH, and does sound rather surprising.)
--
Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
_
various other things, such as PATH).
--
Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
___
https://lists.gnu.org/mailman/listinfo/libtool
all ways of linking libraries, but it applies to pretty much
every Linux distribution (and probably any other distribution of any kind
of UNIX that uses shared libraries and package dependencies). So by
quantity of Libtool installs and invocations, it's significant.
--
Russ Allbery (ea...@eyrie.org)
ny things that on Linux are weird and
unnecessary.
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
with that setting. This of course doesn't work, and
as a result files are not moved to their correct locations during the
build.
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
Farm
I am certain they would be happy to give you access as Libtool maintainer.
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
63 matches
Mail list logo
