iscussion in other lists, but I seem
to recall that AIX's native tools can then select static or shared 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 shar
as libtool expected
.libs 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.
>
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
==
15 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.eyr
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/~ea
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/~ea
sw/development/libtool/build/@sys/tests/_inst/lib:/usr/lib:/lib
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
btool 1.3e (1.910 2001/04/23 00:34:53)
checking host system type... hppa2.0n-hp-hpux11.00
checking build system type... hppa2.0n-hp-hpux11.00
Using vendor ld and gcc 2.95.3.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.e
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
.
===
All 83 tests passed
===
on all three of them.
--
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
.test
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.or
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 t
... (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/~ea
d link or compile
flags, and the packager needs 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
ally leave out 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
ally needs to be told about those directories.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
stand it, turn it into a symbol export 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
Ralf Wildenhues 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 it into
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://ww
ional
(my fault originally), and I suspect that something about the structure of
its configure.ac is causing $delay_single_quote_subst to not be set to
anything, leading sed to be invoked with the empty string as a command.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
___
https://lists.gnu.org/mailman/listinfo/libtool
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. I
believe you may still need this on such platforms as AIX or HP-UX that use
a much different object format, but I'
Russ Allbery 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
Peter Rosin 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 definit
of the library to declare
the necessary behavior for both cases: working transitive dependency
resolution, and situations where this cannot be relied upon. The build
system then chooses based on the situation.
--
Russ Allbery (r...@stanford.edu)
Bob Friesenhahn writes:
> On Sat, 7 Jan 2012, Russ Allbery wrote:
>> pkg-config is an excellent example of an alternative way of handling
>> this that does not have this problem, and it includes Autoconf support.
> What do you mean by "it includes Autoconf support
Bob Friesenhahn writes:
> On Sat, 7 Jan 2012, Russ Allbery wrote:
>> Do you mean for detecting other libraries? Only for libraries without
>> pkg-config support.
> For detecting library features such as the availabilty of functions.
Yes, it deals with that fine. Not tha
this dates from 2005, and
breaking C++ libraries that need threading seems like a bad outcome. Does
this problem still exist? Can this workaround just be dropped?
Note that the GCC maintainters closed the bug requesting -pthread still
add -lpthread even under -nostdlib as invalid.
--
Russ
hat is causing distributions to drop 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...
ould 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://l
(as with Debian/Ubuntu
multiarch) or it will be the 64-bit multiarch system library path.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
___
https://lists.gnu.org/mailman/listinfo/libtool
t does this when 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
ng plugins.
In other 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
hlibdeps
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&arch=amd64&ver=4.7.0-3%2Bb1&stamp=1446816432
--
Russ Allbery
or. 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/>
___
https://lists.gnu.org/mailman/listinfo/libtool
ther things, such as PATH).
--
Russ Allbery (ea...@eyrie.org) <http://www.eyrie.org/~eagle/>
___
https://lists.gnu.org/mailman/listinfo/libtool
ritten to
solve, and is why it does so many things that on Linux are weird and
unnecessary.
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
applicability in the grand picture of all
systems and 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
ing it to do so 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/>
ki/CompileFarm
I am certain they would be happy to give you access as Libtool maintainer.
--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
x27;s the difference between a working 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])
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 Allbe
;: 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
he right link lines to avoid this. That being said,
the addition of extra dependencies is generally only a problem if you're
building OS packages and have to be careful about adding too many
dependencies. If you're just building software for local use, it doesn't
really matter.
That would be very nice. It does require input from the person building
the library, though, or very recent GNU ld with options that don't work
properly on some more obscure platforms.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
___
http://lists.gnu.org/mailman/listinfo/libtool
dd -lz.
Note that the linker that needs to figure this out 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.
--
cific to one executable or library, and hence 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 PRO
ssible at link time. This will (hopefully) 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.
nsitive dependency closures when loading shared 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
>>
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 l
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 usin
ve proper transitive dependency support unless a
static link was requested. (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
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 whi
th -pthread where appropriate is the only additional bit
required in another 4% or more of the cases.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
___
http://lists.gnu.org/mailman/listinfo/libtool
ich are
required only for static linking.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
___
http://lists.gnu.org/mailman/listinfo/libtool
now about the dependency
> on "C"?
Is (B) also linked with libtool? If so, is the *.la 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/&
size of
Debian. Otherwise, your shared 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 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
>>
s used. Normally
it's easier 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/
are something of a special case; it's one 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
Ralf Wildenhues writes:
> * Russ Allbery wrote on Wed, Aug 26, 2009 at 07:35:53AM CEST:
>> dlopened modules are something of a special case; it's one of the
>> places where Debian may not remove *.la files depending on the specific
>> situation.
> I have a question
config in the *.la files of all your
installed libraries.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
___
http://lists.gnu.org/mailman/listinfo/libtool
ne, given that it
installs the library symlinks itself properly in the first place.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
___
http://lists.gnu.org/mailman/listinfo/libtool
e is
therefore intended to minimize the size of statically 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
7;s a lot more pleasant and a lot clearer to
write configure scripts using the new language definition than the old one
because it's much clearer what to do at any given point to accomplish what
you want to accomplish (although the annoying cache directory and the
speed issues are a bi
to go on
is how Autoconf 2.13 works and how Autoconf 2.54 works.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
ool can readily be used 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 PROT
much of that, if any, AIX 5.x 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 PROTECT
make, or hand-coded traditional make.
This I'm not too 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 ([E
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
ou can't easily link 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])
75 matches
Mail list logo
