Russ Allbery wrote:
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
On Sat, Nov 8, 2008 at 7:00 AM, Roumen Petrov
[EMAIL PROTECTED] wrote:
Russ Allbery wrote:
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.
[SNIP]
But problem is not in the libtool.
Yes it is. If you're linking to libfoo, libtool reads libfoo.la and
adds direct links to everything in dependency_libs. Let's say libfoo
depends on libbar and libbaz. You're application ends up directly
linking to libfoo, libbar and libbaz instead of
On Sat, Nov 8, 2008 at 9:22 AM, Roumen Petrov
[EMAIL PROTECTED] wrote:
[SNIP]
But problem is not in the libtool.
Yes it is. If you're linking to libfoo, libtool reads libfoo.la and
adds direct links to everything in dependency_libs. Let's say libfoo
depends on libbar and libbaz. You're
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
Russ Allbery wrote:
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,
Dan Nicholson wrote:
On Sat, Nov 8, 2008 at 9:22 AM, Roumen Petrov
[EMAIL PROTECTED] wrote:
[SNIP]
But problem is not in the libtool.
Yes it is. If you're linking to libfoo, libtool reads libfoo.la and
adds direct links to everything in dependency_libs. Let's say libfoo
depends on libbar and
Roumen Petrov [EMAIL PROTECTED] writes:
It was old build bug when building readline library on some linux-es. In
my memory is suse 7.1 but I'm sure that only this particular version was
affected.
Many other linux verdors build readline without dependent libraries and
this allow application
Russ Allbery wrote:
Roumen Petrov [EMAIL PROTECTED] writes:
It was old build bug when building readline library on some linux-es. In
my memory is suse 7.1 but I'm sure that only this particular version was
affected.
Many other linux verdors build readline without dependent libraries and
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
Russ Allbery wrote:
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.
No,no debian version/release.
This is an 7(5?) years old linux bug.
I'm very dubious of that
On Sat, 8 Nov 2008, Russ Allbery wrote:
pkg-config supports having separate dependency lists for static linking
and shared linking, which seems to adequately address this problem (if
that feature is actually used; the documentation last I looked was a bit
lacking and a lot of pkg-config *.pc
Bob Friesenhahn [EMAIL PROTECTED] writes:
Quite a lot can known from .la files but it is apparent that .la files
are now spontaneously deleted.
Hm, I must admit that I generally find them useless compared to reading
readelf -a output, but I'm not the normal user. :)
It is really quite a
Bob Friesenhahn [EMAIL PROTECTED] writes:
It seems that there is an issue for Linux distribution maintainers. What
needs to be done about it so that this topic does not come up so often?
Well, my preference would be to implement the change to libtool described
in my previous message, but since
Roumen Petrov wrote:
Linking readline against ncurses prevent application to link against
readline against ncursesw and to offer wide characters support.
Note that this is only even possible on a system with lazy binding. For
windows, shared libraries cannot have any undefined symbols at link
I know you mentioned (in 7/6) that you can turn on enough porting hacks to
allow running with Autoconf 2.60; does that include this patch?
No, the porting hacks allow *building* with Autoconf 2.60. This patch
is just to stop using now-deprecated interfaces. Where it touches
libtool.m4, it
This might be a bit easier to write (and thus review) if we used AS_ESCAPE
rather than supplying all the \ ourselves (perhaps as an independent patch
prior to this one).
s/might be/would have been/; s/we used/Libtool had been using/
in other words, that's a separate cleanup IMNSHO.
Paolo
M4SH_VERBATIM([[
Hmm. This is a nicer name for m4_echo, for how it is being used; maybe it is
time to migrated it into the Autoconf manual (perhaps under the name
AS_VERBATIM)?
Maybe, yes.
: ${CP=cp -f}
-: ${ECHO=echo}
+: ${ECHO=$as_echo}
This is delving a bit into m4sh
Roumen Petrov wrote:
With attached patch now I get for libtool 2.2.4:
DESTDIR tests
38: Simple DESTDIR install ok
39: DESTDIR with in-package deplibs ok
Ping?
http://lists.gnu.org/archive/html/bug-libtool/2008-05/msg00023.html
Seems like an
Bruno Haible wrote:
This is a severe regression in libtool 2.x w.r.t. 1.5.26. On mingw, several
of the gettext tests fail because the executable wrapper created by the
libtool script does two bad things:
1) It converts argv[0] from a filename with backslashes to a filename with
slashes.
* libltdl/config/ltmain.m4sh (func_enable_tag): allow
--verbose to set opt_verbose
(func_win32_dllname_for_implib): New function.
(func_mode_link) [cygwin|mingw]: Use linklib (that is,
import lib) as dlpreopen file, rather than DLL.
(func_generate_dlsyms) [cygwin|mingw]: Use
21 matches
Mail list logo
