Re: Blackfin and version scripts
On Mon, Jul 05, 2010 at 04:08:47PM -0400, Mike Frysinger wrote:
On Mon, Jul 5, 2010 at 12:50, Kurt Roeckx wrote:
On Mon, Jul 05, 2010 at 03:43:21AM -0400, Mike Frysinger wrote:
On Saturday, July 03, 2010 05:48:13 Kurt Roeckx wrote:
On Tue, Jun 22, 2010 at 11:42:43AM +0200, Werner Koch wrote:
Hi!
GCRYPT_1.2 {
global:
gcry_check_version; gcry_control;
[...]
Blackfin seems to be the only platform which has version script support
and prefixes symbols with underscores. That does not work of course.
blackfins is one of the arches that defined underscores in the
ABI. But I don't think an application writer should care about
that, and that this is a bug in binutils.
no, it isnt. please read the whole thread and the linker documentation.
I'm not sure which part of the thread you think I missed that said
anything about it. Most of it is actually about complelty
unrelated issues that have nothing to do with bfin.
The only mail that seems to be about it is Ralf's mail about the
mangling. But I'm not convinced that libtool should do any
mangle/demangle thing. Atleast the gnu linker will already do the
proper thing for you, but some others might not.
If you think I missed something, please point me to the actual
mail or documentation.
you stated it is a bug in binutils. that is simply wrong. the
linker script deals in *linker visible* symbols while C code deals in
*C visible*. it has always been this way and as you indirectly
stated, this is not Blackfin specific.
We're talking about a version script, not a linker script.
But my point is that a version script is nothing arch specific,
unlike a linker script. Version scripts even support saying in
which language the symbol is, so that it can properly mangle it
for you. Adding the symbol inside an 'extern C' also doesn't
have any effect.
If you use a debugger, you also want to use break main, and that
actually works, even if the symbol is really called _main in the
file. You don't want to do break _main just because the
platform's ABI says that's the way symbols are named.
Kurt
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Blackfin and version scripts
On Mon, Jul 05, 2010 at 03:43:21AM -0400, Mike Frysinger wrote:
On Saturday, July 03, 2010 05:48:13 Kurt Roeckx wrote:
On Tue, Jun 22, 2010 at 11:42:43AM +0200, Werner Koch wrote:
Hi!
GCRYPT_1.2 {
global:
gcry_check_version; gcry_control;
[...]
Blackfin seems to be the only platform which has version script support
and prefixes symbols with underscores. That does not work of course.
blackfins is one of the arches that defined underscores in the
ABI. But I don't think an application writer should care about
that, and that this is a bug in binutils.
no, it isnt. please read the whole thread and the linker documentation.
I'm not sure which part of the thread you think I missed that said
anything about it. Most of it is actually about complelty
unrelated issues that have nothing to do with bfin.
The only mail that seems to be about it is Ralf's mail about the
mangling. But I'm not convinced that libtool should do any
mangle/demangle thing. Atleast the gnu linker will already do the
proper thing for you, but some others might not.
If you think I missed something, please point me to the actual
mail or documentation.
Kurt
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Blackfin and version scripts
On Tue, Jun 22, 2010 at 11:42:43AM +0200, Werner Koch wrote:
Hi!
GCRYPT_1.2 {
global:
gcry_check_version; gcry_control;
[...]
Blackfin seems to be the only platform which has version script support
and prefixes symbols with underscores. That does not work of course.
blackfins is one of the arches that defined underscores in the
ABI. But I don't think an application writer should care about
that, and that this is a bug in binutils.
Kurt
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: versioning and soname
On Mon, Oct 05, 2009 at 06:30:18PM +0200, Lorenzo Bettini wrote: Hi from what I understand, at least in a Unix environment, if the library version is current:revision:age the soname will be (current-age).age.revision No, The soname will be libname.so.(current-age) The filename on the other hand will have the age and revision added to it on atleast some of the OSs. Kurt won't it? Now if I have a library version (the revision should not be important in this context) 5:_:4 the soname will be 1.4._ right? If I now remove an interface I should set as a library version the following one, right? 6:0:0 and this will generate a soname 6.0.0 i.e., from soname 1.4 we go directly to 6.0 is this the intended behavior? thanks in advance Lorenzo -- Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino ICQ# lbetto, 16080134 (GNU/Linux User # 158233) HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com http://www.myspace.com/supertrouperabba BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com http://www.gnu.org/software/src-highlite http://www.gnu.org/software/gengetopt http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net ___ http://lists.gnu.org/mailman/listinfo/libtool ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
On Mon, Aug 31, 2009 at 04:38:04PM -0400, Mike Frysinger wrote: On Monday 31 August 2009 15:56:06 Kurt Roeckx wrote: On Mon, Aug 31, 2009 at 08:55:21PM +0200, Ralf Wildenhues wrote: * Kurt Roeckx wrote on Sun, Aug 30, 2009 at 10:31:39PM CEST: I've mailed about this issue before. What I think needs to happen, and have proposed before, is: - The .la file should only contain the libraries the current library links to That will make it impossible to support static linking against libraries which do not themselves provide .la files. We cannot do this upstream. I don't see how it's different than what we have now. If I understand what you're trying to say is: - The lib we're making now, liba, links to libb - libb itself does not have a .la file - to link to libb staticly, you also need to link to other libraries. Either you provided libb's depedencies when linking liba or not, what is going to be in liba.la is going to be the same. And if you really want static linking to work properly, you need some way to find out what libraries libb requires, be that with a libb.la or libb.pc file. and Ralf is pointing out that by trimming dependency_libs, you're breaking libb.la when linking libb statically via libtool. if there is no libb.la, then the issue is irrelevant because we arent talking about libtool scripts. - mike You mean that if liba.la was created when there was a libb.la that did contain the needed info? In that case trying to use liba.la now already fails, because it's looking for libb.la. In case liba.la never knew about a libb.la, or libb.a never existed, I can't see any difference. Kurt ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
On Mon, Aug 31, 2009 at 08:55:21PM +0200, Ralf Wildenhues wrote: Hello Kurt, * Kurt Roeckx wrote on Sun, Aug 30, 2009 at 10:31:39PM CEST: I've mailed about this issue before. What I think needs to happen, and have proposed before, is: - The .la file should only contain the libraries the current library links to That will make it impossible to support static linking against libraries which do not themselves provide .la files. We cannot do this upstream. I don't see how it's different than what we have now. If I understand what you're trying to say is: - The lib we're making now, liba, links to libb - libb itself does not have a .la file - to link to libb staticly, you also need to link to other libraries. Either you provided libb's depedencies when linking liba or not, what is going to be in liba.la is going to be the same. And if you really want static linking to work properly, you need some way to find out what libraries libb requires, be that with a libb.la or libb.pc file. - Libtool should recursively read all the .la files in the .la file. Again, this implies that all libraries of interest provide .la files. But Debian itself contributes to making that assumption be false. And the main reason Debian currently doesn't want to ship .la files is because they currently cause more problems than they solve. We want to link as much as possible shared. But it would be nice if we could make it easier for our users to link something staticly if they want to do that. Besides, another issue that we currently have, and whose effect would be worsened by this change, is that deplib searches in staging directories need to take the staging prefix into account. I'm not sure I really understand your point here. But I think it has to do with finding the right library at link time, and that it makes things harder. It's not because it's harder that we shouldn't be doing it. With that change only one .la file would need to be updated. Well, for that you do not need that the .la file only contains the libraries the current library links to. What you need is the following. Assuming there is a deplibs and a private_deplibs (for static linking). Then, when your dependency walker is smart enough (and correct) to recurse .la files, then you can omit references to .la files which you only link against indirectly. However, references to indirect non-libtool deplibs still need to be added to private_deplibs. So you're saying that for the example above, you want to specify libb's depedencies, and make them end up in liba.la's private_deplibs, and that private_deplibs should only be used for cases where the libraries we're linking to do not provide the dependency info? Kurt ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: removal of .la files from Debian and a possible solution to the libtool shared libs problem
On Tue, Aug 25, 2009 at 05:46:12PM +0300, Anssi Hannula wrote: dependency_libs contains the dependencies of a library. These are needed when linking statically. These are also needed when linking dynamically, but only on certain systems (they are not needed on normal linux systems). I think the proper way to solve this is to not link to dependency_libs when linking dynamically on systems where it is not needed to link to those. I haven't seen any correctly working patches that implement this. Debian already ships a version that has link_all_deplibs set to no, which already solves _some_ of the problems we have. (It also has it's issues.) The reason we still have a problem is that the .la file contains all the shared files that this lib, and recursively all the libs they depends on, link to. And when somewhere in the chain something no longer links to a library we have to go and fix all the libraries in between to get rid of the broken .la files. So it currently seems to be easier to ship .la files with dependency_libs set to an empty string. I've mailed about this issue before. What I think needs to happen, and have proposed before, is: - The .la file should only contain the libraries the current library links to - Libtool should recursively read all the .la files in the .la file. With that change only one .la file would need to be updated. I have an implementation (in C) that does this. And it atleast finds some issues in the test suite that I've mailed about and didn't get resolved yet. I should probably also keep working on my version. Kurt ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: lt_dlopenext() sets error on succesful loading the library
On Sun, Feb 01, 2009 at 07:21:11PM +0100, Ralf Wildenhues wrote:
* Kurt Roeckx wrote on Fri, Jan 02, 2009 at 12:10:38PM CET:
There was an error report on the Debian bug tracking system
that lt_dlopenext() sets an error on succesful loading the library
if no extention was given. See:
http://bugs.debian.org/510006
Here are the patches I've made for both the 1.5 and 2.2 branch.
Before I get to the patches, I would like to have a reproducible test
case. Here's the code I gather from the references (patch against git
master). I've redone the build commands the way I think they are
correct (those mentioned in the Autobook are pretty bogus).
I can only reproduce the error in case there is no .la file.
I guess the easiest way it to install the library and then remove
the .la file. I've attached an updated lt_dlopenext.at and
a diff against your version that does that, and reproduces
the error.
Kurt
# lt_dlopenext.at -- test libltdl functionality -*- Autotest -*-
#
# Copyright (C) 2009 Free Software Foundation, Inc.
# This file is part of GNU Libtool.
#
# GNU Libtool is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License as
# published by the Free Software Foundation; either version 2 of
# the License, or (at your option) any later version.
#
# GNU Libtool is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with GNU Libtool; see the file COPYING. If not, a copy
# can be downloaded from http://www.gnu.org/licenses/gpl.html,
# or obtained by writing to the Free Software Foundation, Inc.,
# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
AT_SETUP([lt_dlopenext error messages])
AT_KEYWORDS([libltdl])
prefix=`pwd`/inst
mkdir $prefix
# This code is copied from the Autobook:
# http://sources.redhat.com/autobook/autobook/autobook_169.html
# so if it needs changes, be sure to notify the Autobook authors
# about them.
AT_DATA([simple-module.c],
[[
#include stdio.h
int
run (const char *argument)
{
printf (Hello, %s!\n, argument);
return 0;
}
]])
AT_DATA([ltdl-loader.c],
[[
#include stdio.h
#include stdlib.h
#ifndef EXIT_FAILURE
# define EXIT_FAILURE1
# define EXIT_SUCCESS0
#endif
#include limits.h
#ifndef PATH_MAX
# define PATH_MAX 255
#endif
#include string.h
#include ltdl.h
#ifndef MODULE_PATH_ENV
# define MODULE_PATH_ENVMODULE_PATH
#endif
typedef int entrypoint (const char *argument);
/* Save and return a copy of the dlerror() error message,
since the next API call may overwrite the original. */
static char *dlerrordup (char *errormsg);
int
main (int argc, const char *argv[])
{
char *errormsg = NULL;
lt_dlhandle module = NULL;
entrypoint *run = NULL;
int errors = 0;
if (argc != 3)
{
fprintf (stderr, USAGE: main MODULENAME ARGUMENT\n);
exit (EXIT_FAILURE);
}
/* Initialise libltdl. */
errors = lt_dlinit ();
/* Set the module search path. */
if (!errors)
{
const char *path = getenv (MODULE_PATH_ENV);
if (path != NULL)
errors = lt_dlsetsearchpath (path);
}
/* Load the module. */
if (!errors)
module = lt_dlopenext (argv[1]);
/* Find the entry point. */
if (module)
{
run = (entrypoint *) lt_dlsym (module, run);
/* In principle, run might legitimately be NULL, so
I don't use run == NULL as an error indicator
in general. */
errormsg = dlerrordup (errormsg);
if (errormsg != NULL)
{
errors = lt_dlclose (module);
module = NULL;
}
}
else
errors = 1;
/* Call the entry point function. */
if (!errors)
{
int result = (*run) (argv[2]);
if (result 0)
errormsg = strdup (module entry point execution failed);
else
printf (\t= %d\n, result);
}
/* Unload the module, now that we are done with it. */
if (!errors)
errors = lt_dlclose (module);
if (errors)
{
/* Diagnose the encountered error. */
errormsg = dlerrordup (errormsg);
if (!errormsg)
{
fprintf (stderr, %s: dlerror() failed.\n, argv[0]);
return EXIT_FAILURE;
}
}
/* Finished with ltdl now. */
if (!errors)
if (lt_dlexit () != 0)
errormsg = dlerrordup (errormsg);
if (errormsg)
{
fprintf (stderr, %s: %s.\n, argv[0], errormsg);
free (errormsg);
exit (EXIT_FAILURE);
}
return EXIT_SUCCESS;
}
/* Be careful to save a copy of the error message,
since the next API call may overwrite the original. */
static char *
dlerrordup (char *errormsg)
{
char *error = (char *) lt_dlerror ();
if (error !errormsg)
errormsg = strdup (error
Re: lt_dlopenext() sets error on succesful loading the library
On Fri, Jan 02, 2009 at 12:10:38PM +0100, Kurt Roeckx wrote: Hi, There was an error report on the Debian bug tracking system that lt_dlopenext() sets an error on succesful loading the library if no extention was given. See: http://bugs.debian.org/510006 Here are the patches I've made for both the 1.5 and 2.2 branch. PS: Can somebody fix the example in autobook? Can someone take a look at this? Kurt
Re: [PATCH] Don't install .la files when --no-la-files is used
On Sun, Nov 09, 2008 at 12:01:33AM +0200, Roumen Petrov wrote:
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.
That's the version currently in unstable and won't even be part of
our next release.
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 any curses functions should not need to link with any
curses library.
Linking readline against ncurses prevent application to link against
readline against ncursesw and to offer wide characters support.
I was under the impression that ncursesw was going to go away,
but I'm not sure where I got that from.
And you can still have ncursesw load before ncurses if you put
the libraries in the right order.
Details:
- library foo1 for pkg1 export function foo1
- library foo2 for pkg2 export function foo2 and use function foo1
- application use functions foo1 and foo2 and and to link with libraries
that export them.
This example seems to be wrong. The example should be about the
the application only using the function foo2 and not using foo1.
It should only need to link to library foo2, it should not link to
library foo1, since it's not using symbols from that.
Where is libtool bug ?
Your example as described above has nothing to do with the case that we're
talking about since it contains no implicit dependencies. I'm afraid I
can only conclude that I've not been sufficiently clear and you're not
following my point at all. I've explained this as clearly as I can,
though. Maybe someone else can do a better job.
But is a package author uncomment line:
#libfoo2_la_LIBADD = -L${testPREFIX}/lib -lfoo1
from pkg2/bootstrap.sh you will see dependency added in la-file.
library foo2 is using symbols from foo1 so it really should link
against that library. And the .la should contain foo1 in it's
dependency_libs.
The problem is that when linking the application making use of
foo2 libtool should _not_ look at foo2's dependency_libs if it's
linking to foo2 shared and it's an arch that does not need that
for shared libraries like in the case of ELF. A way of forcing
libtool not to look at it is to remove the .la file.
Kurt
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: [PATCH] Don't install .la files when --no-la-files is used
On Sun, Nov 09, 2008 at 07:31:47AM -0800, Dan Nicholson wrote: On Sat, Nov 8, 2008 at 3:38 PM, Bob Friesenhahn [EMAIL PROTECTED] wrote: I feel like today I just watched the movie Groundhog Day another 20 times. This topic re-emerges just as often as the one about whether list replies should default to the original sender, or to the list. 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? I haven't followed the topic for that long, but it think this is that patch Debian uses which many other distros have picked up: http://patches.ubuntu.com/libt/libtool/extracted/link_all_deplibs.patch http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/libtool/current/SOURCES/libtool-1.5.24-link_all_deplibs.patch?view=markup So, what would it take to get something like that upstream? There are a few problems with this patch. See: http://bugs.debian.org/291641 http://bugs.debian.org/320698 http://bugs.debian.org/297726 It's also not complete: http://bugs.debian.org/419228 Obviously, it would first have to be ported to 2.2. Then, it seems to me that it should probably use a feature test rather than a platform glob. I think Ralf called this transitive dependency closures. The patch has been ported to 2.2 and the first link you showed is the one for 2.2. Kurt ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Problems with libtool 2.2.2 and /bin/sh pointing to dash
On Tue, Apr 22, 2008 at 08:00:08PM +0200, Ralf Wildenhues wrote: * Ross Burton wrote on Tue, Apr 22, 2008 at 11:11:25AM CEST: I can replicate this on my Debian Sid (up to date as of this morning) laptop, with the following configuration. /bin/sh - /bin/dash SHELL=/bin/bash PATH=/home/ross/BUILD/bin:/home/ross/bin:/usr/local/bin:/usr/bin:/bin:/usr/games Using libtool 2.2.2-1 from Debian Experimental I'm having a deja vu feeling, there was a similar Debian bug a while ago which IIRC I could not reproduce either. You could reproduce it, and you supplied a patch for configure.ac. See http://bugs.debia.org/447022 Kurt ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: why does libtool reorder -Wl, arguments to the end making -Wl, --as-needed unusable
There is some sort of patch available at: http://bugs.debian.org/347650#60 Kurt On Thu, Feb 28, 2008 at 03:17:54PM +0200, Petteri Räty wrote: [EMAIL PROTECTED] /mnt/checkouts/classpath/native/jni/qt-peer $ make make all-am make[1]: Entering directory `/mnt/checkouts/classpath/native/jni/qt-peer' /bin/sh ../../../libtool --tag=CXX --mode=link g++ -DQT_SHARED -I/usr/include/qt4 -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -g -O2 -module -version-info 0:0:0 -no-undefined -avoid-version -Wl,--as-needed -o libqtpeer.la -rpath /usr/local/classpath/lib/classpath libqtpeer_la-componentevent.lo libqtpeer_la-keybindings.lo libqtpeer_la-mainqtthread.lo libqtpeer_la-mainthreadinterface.lo libqtpeer_la-nativewrapper.lo libqtpeer_la-qmatrix.lo libqtpeer_la-qpainterpath.lo libqtpeer_la-qpen.lo libqtpeer_la-qtaudioclip.lo libqtpeer_la-qtbuttonpeer.lo libqtpeer_la-qtcanvaspeer.lo libqtpeer_la-qtcheckboxpeer.lo libqtpeer_la-qtchoicepeer.lo libqtpeer_la-qtcomponent.lo libqtpeer_la-qtcomponentpeer.lo libqtpeer_la-qtdialogpeer.lo libqtpeer_la-qtembeddedwindowpeer.lo libqtpeer_la-qtfiledialogpeer.lo libqtpeer_la-qtfontmetrics.lo libqtpeer_la-qtfontpeer.lo libqtpeer_la-qtframepeer.lo libqtpeer_la-qtgraphics.lo libqtpeer_la-qtimage.lo libqtpeer_la-qtlabelpeer.lo libqtpeer_la-qtlistpeer.lo libqtpeer_la-qtmenubarpeer.lo libqtpeer_la-qtmenucomponentpeer.lo libqtpeer_la-qtmenuitempeer.lo libqtpeer_la-qtmenupeer.lo libqtpeer_la-qtpanelpeer.lo libqtpeer_la-qtpopupmenupeer.lo libqtpeer_la-qtscreendevice.lo libqtpeer_la-qtscrollbarpeer.lo libqtpeer_la-qtscrollpanepeer.lo libqtpeer_la-qtstrings.lo libqtpeer_la-qttextareapeer.lo libqtpeer_la-qttextfieldpeer.lo libqtpeer_la-qttoolkit.lo libqtpeer_la-qtvolatileimage.lo libqtpeer_la-qtwindowpeer.lo libqtpeer_la-slotcallbacks.lo -L/usr/lib/qt4 -lQtGui -lpng -lSM -lICE -lQtCore -lz -lrt -lpthread -lXrender -lXrandr -lXfixes -lXcursor -lXinerama -lfreetype -lfontconfig -lXext -lX11 -lm -ldl -lpulse libtool: link: rm -fr .libs/libqtpeer.la .libs/libqtpeer.lai .libs/libqtpeer.so libtool: link: g++ -shared -nostdlib /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/../../../crti.o /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/crtbeginS.o .libs/libqtpeer_la-componentevent.o .libs/libqtpeer_la-keybindings.o .libs/libqtpeer_la-mainqtthread.o .libs/libqtpeer_la-mainthreadinterface.o .libs/libqtpeer_la-nativewrapper.o .libs/libqtpeer_la-qmatrix.o .libs/libqtpeer_la-qpainterpath.o .libs/libqtpeer_la-qpen.o .libs/libqtpeer_la-qtaudioclip.o .libs/libqtpeer_la-qtbuttonpeer.o .libs/libqtpeer_la-qtcanvaspeer.o .libs/libqtpeer_la-qtcheckboxpeer.o .libs/libqtpeer_la-qtchoicepeer.o .libs/libqtpeer_la-qtcomponent.o .libs/libqtpeer_la-qtcomponentpeer.o .libs/libqtpeer_la-qtdialogpeer.o .libs/libqtpeer_la-qtembeddedwindowpeer.o .libs/libqtpeer_la-qtfiledialogpeer.o .libs/libqtpeer_la-qtfontmetrics.o .libs/libqtpeer_la-qtfontpeer.o .libs/libqtpeer_la-qtframepeer.o .libs/libqtpeer_la-qtgraphics.o .libs/libqtpeer_la-qtimage.o .libs/libqtpeer_la-qtlabelpeer.o .libs/libqtpeer_la-qtlistpeer.o .libs/libqtpeer_la-qtmenubarpeer.o .libs/libqtpeer_la-qtmenucomponentpeer.o .libs/libqtpeer_la-qtmenuitempeer.o .libs/libqtpeer_la-qtmenupeer.o .libs/libqtpeer_la-qtpanelpeer.o .libs/libqtpeer_la-qtpopupmenupeer.o .libs/libqtpeer_la-qtscreendevice.o .libs/libqtpeer_la-qtscrollbarpeer.o .libs/libqtpeer_la-qtscrollpanepeer.o .libs/libqtpeer_la-qtstrings.o .libs/libqtpeer_la-qttextareapeer.o .libs/libqtpeer_la-qttextfieldpeer.o .libs/libqtpeer_la-qttoolkit.o .libs/libqtpeer_la-qtvolatileimage.o .libs/libqtpeer_la-qtwindowpeer.o .libs/libqtpeer_la-slotcallbacks.o -L/usr/lib/qt4 /usr/lib/qt4/libQtGui.so -L/usr/lib /usr/lib/libpng12.so /usr/lib/qt4/libQtCore.so -lpthread /usr/lib/libXrandr.so /usr/lib/libXcursor.so /usr/lib/libXrender.so /usr/lib/libXfixes.so /usr/lib/libxcb-xlib.so /usr/lib/libxcb.so /usr/lib/libXinerama.so /usr/lib/libfontconfig.so /usr/lib/libfreetype.so /usr/lib/libxml2.so -lz /usr/lib/libXext.so /usr/lib/libpulse.so /usr/lib/libSM.so /usr/lib/libICE.so /usr/lib/libX11.so /usr/lib/libXau.so /usr/lib/libXdmcp.so -lcap -lrt -ldl -latomic_ops -L/usr/lib/gcc/i686-pc-linux-gnu/4.2.3 -L/usr/lib/gcc/i686-pc-linux-gnu/4.2.3/../../../../i686-pc-linux-gnu/lib -L/usr/lib/gcc/i686-pc-linux-gnu/4.2.3/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/crtendS.o /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/../../../crtn.o -Wl,--as-needed -Wl,-soname -Wl,libqtpeer.so -o .libs/libqtpeer.so libtool: link: ( cd .libs rm -f libqtpeer.la ln -s ../libqtpeer.la libqtpeer.la ) make[1]: Leaving directory `/mnt/checkouts/classpath/native/jni/qt-peer' --as-needed needs to come before the object files and libs to be effective but libtool moves it to the end. This happens with both 1.5.26 and cvs head. Regards, Petteri
2.1b license.
Hi, It seems most of the files have this in them: # GNU Libtool is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. But the COPYING file has version 3 in it. I could only find 1 example with version 3 in it: texinfo.tex Are you going to change everything to version 3? Kurt ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.1b license.
On Sat, Feb 09, 2008 at 07:21:35PM +0100, Ralf Wildenhues wrote: Hello Kurt, * Kurt Roeckx wrote on Sat, Feb 09, 2008 at 07:13:00PM CET: It seems most of the files have this in them: # GNU Libtool is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. But the COPYING file has version 3 in it. Erm, I can't see that in http://alpha.gnu.org/gnu/libtool/libtool-2.1b.tar.gz. Where did you get the tarball from? It seems that someone thought it was a good idea to remove the COPYING file in the clean target of the Debian package. automake then readds it but changed it to version 3. This wasn't a good idea obviously. Kurt ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Linker archives and dependency_libs
On Sat, Nov 24, 2007 at 03:47:24PM +0100, Micha Lenk wrote: Hi, I'm currently investigating how http://bugs.debian.org/451582 could be solved in a clean fashion. As far as I understand upstream, the library libchipcard shouldn't need to be linked against libgnutls. But apparently it got linked against libgnutls because of the content of the .la files. libgwenhywfar.la contains: # Libraries that this one depends upon. dependency_libs=' /usr/lib/libgnutls.la -L/usr/lib /usr/lib/libtasn1.la -lz /usr/lib/libgcrypt.la /usr/lib/libgpg-error.la -lnsl -ldl' The package that ships libgwenhywfar.la (libgwenhywfar38-dev) should have a Depends on the packages shipping /usr/lib/libgnutls.la (libgnutls-dev), which it doesn't. This is a bug in libgwenhywfar38-dev, and I'll reassign it shortly. libgnutls.la contains: # Libraries that this one depends upon. dependency_libs=' -L/usr/lib /usr/lib/libtasn1.la /usr/lib/libgcrypt.la -lz /usr/lib/libgcrypt.la /usr/lib/libgpg-error.la -lnsl' And the package shipping libgnutls.la (libgnutls-dev) should have a Depends on the packages shipping /usr/lib/libtasn1.la (libtasn1-3-dev), /usr/lib/libgcrypt.la (libgcrypt11-dev), which it does. And there is also /usr/lib/libgcrypt.la that has: dependency_libs=' /usr/lib/libgpg-error.la -lnsl' So libgnutls-dev should Depends on the package shipping /usr/lib/libgpg-error.la (libgpg-error-dev), which it does. (You should read this in the reverse order). If libchipcard shouldn't need to be linked against libgnutls -- as upstream said -- I think libgwenhywfar.la shouldn't contain a reference to libgnutls.la. But what needs to be done (in libgwenhywfar) to achieve that? There are 2 problems here: - libtool uses the .la files when it finds them. And tries to read all of them. If one of the files mentioned isn't available, it will and should fail. There are 2 ways to deal with this (in Debian): - Add the right Depends to your -dev package. This is also needed for static linking. - Don't ship the .la files if you don't need them for other reasons - You have extra libraries you link too which you don't need. This is a problem in libtool that has no easy solution. There is a patch in the Debian version of libtool that mostly solves it, but it also has a few problems. Kurt ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Bug#419228: unnecessary linkage when libtool convenience libraries (noinst_LTLIBRARIES) are used
On Mon, Apr 23, 2007 at 07:31:38PM +0200, Ralf Wildenhues wrote: Hello Kurt, all, Thanks for the patch. * Kurt Roeckx wrote on Sun, Apr 22, 2007 at 01:22:30AM CEST: So would the attached patch be acceptable for now? I'm thinking about adding that to the Debian patch. Hmm. It breaks when -static is used. Here's how I tested your patch, as a new test against the testsuite of CVS HEAD (apologies, but I rather prefer writing new tests for HEAD; the patch contains two tests; the first one belongs to this bug). If you're inclined, here's how you can use HEAD's new testsuite with an 1.5.x libtool: get CVS HEAD, bootstrap and compile it. Then run make check-local TESTSUITEFLAGS=-v -d -x -k indirect \ LIBTOOL=/path/to/the/1.5.x/libtool This is a great trick, thanks! Both of those two tests work with Debian's current libtool, but break with your patch. Note that they also break if -static is used for all libraries (add LDFLAGS=-static to TESTSUITEFLAGS to try out), rather than only to the final ones. Right, so the problem is with static libraries. And the solution I had in mind was that it needs to look at the .la files recursivly. It doesn't seem to be doing this. Kurt
Re: Bug#419228: unnecessary linkage when libtool convenience libraries (noinst_LTLIBRARIES) are used
On Thu, Apr 19, 2007 at 08:16:07PM +0200, Ralf Wildenhues wrote: * Andreas Metzler wrote on Thu, Apr 19, 2007 at 08:02:36PM CEST: On 2007-04-19 Ralf Wildenhues [EMAIL PROTECTED] wrote: And libtool remembers by putting the library dependency into the libconvenience.la file. And that is exactly what goes wrong. It does not put the library dependency in the la file, it puts the library dependency and *its* dependencies in the la file. D'oh. I sense that we are talking past each other all the time. I also get that feeling. Thanks for bearing with me, I feel a bit better now. OK, now that I (think I) understand the issue, I guess it's the right thing for Debian libtool (with its link_all_deplibs=no) to also not link against these indirect deplibs stemming from a convenience archive's deplibs. This feature should be specific to systems with link_all_deplibs=no, though. It can be pulled into upstream once the indirect deplibs issues are fixed (one of them being that uninstalled indirect deplibs aren't found). So would the attached patch be acceptable for now? I'm thinking about adding that to the Debian patch. Kurt --- ltmain.in.orig 2007-04-22 01:16:56.0 +0200 +++ ltmain.in 2007-04-22 01:18:57.0 +0200 @@ -2859,7 +2859,9 @@ # ... and its dependency_libs tmp_libs= for deplib in $dependency_libs; do - newdependency_libs=$deplib $newdependency_libs + if test $link_all_deplibs != no; then + newdependency_libs=$deplib $newdependency_libs + fi if test X$duplicate_deps = Xyes ; then case $tmp_libs in * $deplib *) specialdeplibs=$specialdeplibs $deplib ;;
Re: Splitting dependency_libs in *.la?
On Mon, Oct 02, 2006 at 05:26:43PM -0500, Albert Chin wrote: Debian has a patch that sets link_all_deplibs to no. This basicly doesn't use dependency_libs for shared linking. Note that this causes various problems for which there are open bugs in the Debian bug tracking system. Because of this, Debian is more and more moving from .la files to using pkg-config's .pc files, which contains the info we need, and also has cflags (-Is) in it. If you add LDFLAGS=-Wl,--as-needed, then linking against dependency_libs shouldn't matter. But, that only helps if you use a recent version of GNU ld. You don't want to use --as-needed in all cases. You sometimes need to be linked to a library, even if you don't appear to be using it. One example is the use of constructors/destructors in the library. Also, libtool has a problem with it, since it can reorder things. See http://bugs.debian.org/347650 And, even for .pc files, it doesn't mean you get _only_ the libraries you need. What if someone has Requires: -lpng -lz in a .pc file? Then you have a dependency on libpng and libz, which is unnecessary as libpng already depends on libz. What you mean is: Libs: -lpng -lz But you really should use: Libs.private: -lpng -lz Or: Requires.private: libpng The Libs are used for all linking, the Libs.private only for static linking. The same goes for Requires and Requires.private. Anyway, when you make a library, and you use both libpng and libz, you should yourself link to both of them. If you only make use of libpng, and don't use libz yourself, you should only link to libpng if you're linking shared. But that doesn't say anything about applications that try to link to your library, since they really should only link to yours if linking shared, and to all 3 if linking static. I don't see how libtool can intelligently decide the minimum set of libraries needed to satisfy the link. It should just use whatever to user said to use. Kurt ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Splitting dependency_libs in *.la?
On Mon, Oct 02, 2006 at 01:51:58PM +0200, Axel Thimm wrote: Hi, dependency_libs contains the linker switches/arguments that this library was built with including the dependent libs, both directly references as well as indirectly references through intermediate libs. For static linking one needs the whole dependency_libs information, but for building against shared libs you only need a subset. This leads to having more build dependencies than neccessary in a shared-libs only build. As a consequence some distributions decided to remove all *.la files to keep build dependencies down. This is of course not really a solution. There is nothing you can do to reduce the number of build dependencies. If you can reduce it, there is a bug somewhere. However, you can reduce the number of depends of the package itself when linking shared. But recursivly, you'll still have the same dependencies. Because of those reduced dependies it makes it alot easier to do transitions from 1 soname to another. Can this be somehow dealt with within libtool? It would need to fork the semantics of dependency_libs into static vs shared libs or something similar. I guess the difficult part is identifying what parts of dependency_libs are needed for a shared build against this library. Debian has a patch that sets link_all_deplibs to no. This basicly doesn't use dependency_libs for shared linking. Note that this causes various problems for which there are open bugs in the Debian bug tracking system. Because of this, Debian is more and more moving from .la files to using pkg-config's .pc files, which contains the info we need, and also has cflags (-Is) in it. If you need more info about this, please let me know. There is also an other problem when using conviences libraries, which basicly has the same problem adding dependencies. This has also been discussed before, please see: http://lists.gnu.org/archive/html/libtool/2005-12/msg00021.html Kurt ___ http://lists.gnu.org/mailman/listinfo/libtool
Fwd: ~ in builddirs caused libtool to fail
Hi, In Debian we recently allowed ~ in version numbers, where ~ could be used to sort after everything else. This is for instance useful so that 1.0~rc1 is a smaller version than 1.0. Using this seems to be breaking libtool, because it uses ~ for something else. Can someone take a look at this? Kurt ---BeginMessage--- Hi all, the new ~ in packagenames and builddirs doesn' fit well. The problem is caused by the fact that there is a ~ in the directory name. Libtool uses ~ as a separator. [1] Is there a way to avoid this or should we use the old packagenames - alsa-tools-1.0.12+1.0.13rc2 instead of alsa-tools-1.0.13~rc2 ? [1]http://autoconf-archive.cryp.to/patch_libtool_changing_cmds_ifs.html Thanks for cooperation Elimar -- Numeric stability is probably not all that important when you're guessing;-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] ---End Message--- ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: ~ in builddirs caused libtool to fail
On Sun, Sep 24, 2006 at 08:26:24PM +0900, Peter O'Gorman wrote: I'm pretty sure that I applied a patch sometime to allow ~ in the build dir name. Here we are: 2004-01-25 Peter O'Gorman [EMAIL PROTECTED] * ltmain.in: Move eval to after command separation to allow ~ in paths. Maybe it's been broken again? Can you please provide ./libtool -- version for the packages in question. The current version in Debian unstable has: ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06) The patch mentioned in the mail says it's last modified 2003-03-24, I've tried building with a ~ in the path and it worked, so I have no idea what's wrong. Elimar, could you check what version of libtool you're using, and what happens exactly? Are you sure this is a libtool problem? Kurt ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: ~ in builddirs caused libtool to fail
On Sun, Sep 24, 2006 at 03:32:26PM +0200, Elimar Riesebieter wrote: On Sun, 24 Sep 2006 the mental interface of Kurt Roeckx told: The current version in Debian unstable has: ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06) The patch mentioned in the mail says it's last modified 2003-03-24, I've tried building with a ~ in the path and it worked, so I have no idea what's wrong. Elimar, could you check what version of libtool you're using, and what happens exactly? Are you sure this is a libtool problem? # libtool --version ltmain.sh (GNU libtool) 1.5.22 Debian 1.5.22-4 (1.1220.2.365 2005/12/18 22:14:06) That's what you have installed in /usr/bin, try: ./ld10k1/libtool --version Trying to build alsa-tools-1.0.12~rc1: ranlib /source/alsa/svn-pkg-alsa/tarballs/alsa-tools-1.0.12 ranlib: '/source/alsa/svn-pkg-alsa/tarballs/alsa-tools-1.0.12': No such file rc1/debian/tmp/usr/lib/liblo10k1.a ../libtool: line 5985: rc1/debian/tmp/usr/lib/liblo10k1.a: No such file or directory The builddir is indeed /source/alsa/svn-pkg-alsa/tarballs/alsa-tools-1.0.12~rc1 I get: ranlib /usr/src/alsa-tools-1.0.12~rc1/debian/tmp/usr/lib/liblo10k1.a Which seems to be working perfectly. I don't get any errors at all. What shell are you using, and what is /bin/sh pointing to? (Note that I've just renamed the alsa-tools-1.0.12 to alsa-tools-1.0.12~rc1, this isn't really an rc1.) Kurt ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: ~ in builddirs caused libtool to fail
On Sun, Sep 24, 2006 at 02:30:45PM +0200, Kurt Roeckx wrote: The current version in Debian unstable has: ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06) So, it seems they were using an older version of libtool now suddenly: ltmain.sh (GNU libtool) 1.5 (1.1220.2.1 2003/04/14 22:48:00) And upgrading seems to have fixed it. Kurt ___ http://lists.gnu.org/mailman/listinfo/libtool
kfreebsd*-gnu/k*bsd*-gnu support.
Hi,
I've attached 2 patches that should get kfreebsd*-gnu and
knetbsd*-gnu support, or more in general k*bsd*-gnu support
working properly.
k*bsd behaves like Linux, but with a bsd kernel. They have a gnu
libc, gnu binutils, ... Some of the things currently in libtool.m4
are actually for the case they wouldn't be using gnu ld, and
therefor break. They mostly seem to have problem with the
kfreebsd-amd64 port.
The patch changed (almost) everything to do the same as on Linux.
It's based on a patch provided by Aurelien Jarno. I've made a
patch for both the 1.5 branch and 2.0.
One thing I have to wonder about is they need to set LD in
_LT_AC_LOCK for arches that support 64 bit.
Kurt
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v
retrieving revision 1.314.2.149
diff -u -r1.314.2.149 libtool.m4
--- libtool.m4 3 Feb 2006 20:05:00 - 1.314.2.149
+++ libtool.m4 12 Mar 2006 15:07:34 -
@@ -1398,18 +1398,6 @@
dynamic_linker=no
;;
-kfreebsd*-gnu)
- version_type=linux
- need_lib_prefix=no
- need_version=no
- library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}$major ${libname}${shared_ext}'
- soname_spec='${libname}${release}${shared_ext}$major'
- shlibpath_var=LD_LIBRARY_PATH
- shlibpath_overrides_runpath=no
- hardcode_into_libs=yes
- dynamic_linker='GNU ld.so'
- ;;
-
freebsd* | dragonfly*)
# DragonFly does not have aout. When/if they implement a new
# versioning mechanism, adjust this.
@@ -1565,7 +1553,7 @@
;;
# This must be Linux ELF.
-linux*)
+linux* | k*bsd*-gnu)
version_type=linux
need_lib_prefix=no
need_version=no
@@ -1594,18 +1582,6 @@
dynamic_linker='GNU/Linux ld.so'
;;
-knetbsd*-gnu)
- version_type=linux
- need_lib_prefix=no
- need_version=no
- library_names_spec='${libname}${release}${shared_ext}$versuffix
${libname}${release}${shared_ext}$major ${libname}${shared_ext}'
- soname_spec='${libname}${release}${shared_ext}$major'
- shlibpath_var=LD_LIBRARY_PATH
- shlibpath_overrides_runpath=no
- hardcode_into_libs=yes
- dynamic_linker='GNU ld.so'
- ;;
-
netbsd*)
version_type=sunos
need_lib_prefix=no
@@ -2315,7 +2291,7 @@
lt_cv_deplibs_check_method=pass_all
;;
-freebsd* | kfreebsd*-gnu | dragonfly*)
+freebsd* | dragonfly*)
if echo __ELF__ | $CC -E - | grep __ELF__ /dev/null; then
case $host_cpu in
i*86 )
@@ -2369,7 +2345,7 @@
;;
# This must be Linux ELF.
-linux*)
+linux* | k*bsd*-gnu)
lt_cv_deplibs_check_method=pass_all
;;
@@ -3129,7 +3105,7 @@
freebsd-elf*)
_LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
;;
- freebsd* | kfreebsd*-gnu | dragonfly*)
+ freebsd* | dragonfly*)
# FreeBSD 3 and later use GNU C++ and GNU ld with standard ELF
# conventions
_LT_AC_TAGVAR(ld_shlibs, $1)=yes
@@ -3288,7 +3264,7 @@
_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath ${wl}$libdir'
_LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
;;
- linux*)
+ linux* | k*bsd*-gnu)
case $cc_basename in
KCC*)
# Kuck and Associates, Inc. (KAI) C++ Compiler
@@ -4664,7 +4640,7 @@
lt_cv_sys_global_symbol_to_cdecl=sed -n -e 's/^T .* \(.*\)$/extern int
\1();/p' -e 's/^$symcode* .* \(.*\)$/extern char \1;/p'
lt_cv_sys_global_symbol_to_c_name_address=sed -n -e 's/^: \([[^ ]]*\) $/
{1\\\, (lt_ptr) 0},/p' -e 's/^$symcode* \([[^ ]]*\) \([[^ ]]*\)$/
{\\2\, (lt_ptr) \\2},/p'
;;
-linux*)
+linux* | k*bsd*-gnu)
if test $host_cpu = ia64; then
symcode='[[ABCDGIRSTW]]'
lt_cv_sys_global_symbol_to_cdecl=sed -n -e 's/^T .* \(.*\)$/extern int
\1();/p' -e 's/^$symcode* .* \(.*\)$/extern char \1;/p'
@@ -4937,7 +4913,7 @@
;;
esac
;;
- freebsd* | kfreebsd*-gnu | dragonfly*)
+ freebsd* | dragonfly*)
# FreeBSD uses GNU C++
;;
hpux9* | hpux10* | hpux11*)
@@ -4980,7 +4956,7 @@
;;
esac
;;
- linux*)
+ linux* | k*bsd*-gnu)
case $cc_basename in
KCC*)
# KAI C++ Compiler
@@ -5234,7 +5210,7 @@
_LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
;;
-linux*)
+linux* | k*bsd*-gnu)
case $cc_basename in
icc* | ecc*)
_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
@@ -5549,7 +5525,7 @@
_LT_AC_TAGVAR(archive_expsym_cmds, $1)='sed s,^,_, $export_symbols
$output_objdir/$soname.expsym~$CC -shared $pic_flag $libobjs $deplibs
$compiler_flags ${wl}-h,$soname
${wl}--retain-symbols-file,$output_objdir/$soname.expsym
${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
;;
-linux*)
+linux* | k*bsd*-gnu)
if $LD --help 21 | grep ': supported targets:.* elf' /dev/null; then
tmp_addflag=
case $cc_basename,$host_cpu in
@@ -5910,7 +5886,7 @@
;;
# FreeBSD 3 and greater uses gcc -shared
Re: Spaces in path names
On Thu, Jan 12, 2006 at 11:06:51AM +0100, Roger While wrote: Per Subject. Libtool 1.5.22 I found some earlier mails about this from 2005. Is anything being/going to be done about this ? This is a real pain on most Cygwin machines where users are likely to have spaces in path names (eg. in HOME - Roger While). Debian has a open bug about this with has a patch at: http://bugs.debian.org/193163 And it seems this has been mailed to bug-libtool@gnu.org too. I do not believe the patch is complete, but might be something you can start with if you really want to get this working. Kurt ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Deplibs for conviences archives and binaries.
On Mon, Jan 02, 2006 at 06:32:56PM +0100, Ralf Wildenhues wrote: Hi Kurt, Gary, * Kurt Roeckx wrote on Thu, Dec 29, 2005 at 07:52:53PM CET: It seems 1.5 and head are a little bit different when it comes to linking a binary. It seems that for linking a binary it does the same as in case of a conviences library, and adds all depedency_libs to deplibs. It should do that for conviences libraries, but not for binaries. I've attached a patch to make head do the same as 1.5, which is the behaviour I want. It just moves the code to be inside the if. I have no idea why they're different, couldn't find when it was changed (in which branch), but didn't look too hard either. This is exactly the reversal of libtool--gary--1.0--patch-49 which is http://lists.gnu.org/archive/html/libtool-patches/2004-09/msg00248.html This is exactly what I was looking for, thanks for the pointer. It would help greatly to have both - a small self-contained example that works with libtool-1.5.x but breaks with CVS HEAD, As you might have guessed, this has to do with the number of dependencies generated for binaries. It doesn't really break anything, it just that in Debian we'd like to reduce the dependencies to a minimum. - any more details on how CVS m4 breaks without libtool--gary--1.0--patch-49 and how to reproduce that easily. In above mail, Gary said: | Finally... it has taken me a week to track down the two bugs [...] and I have little desire to invest another week. I can't bootstrap CVS m4 at the moment because it needs (among others) CVS gettext which fails to build for me.. and I don't have lots of incentive to chase all these bugs before getting to the libtool one. (IOW, a pointer to a CVS m4 tarball would be great, too). I'll try looking into that too if I find some time. Kurt
Daily snapshot broken [Was: Re: Fix variables_saved_for_relink / LD_LIBRARY_PATH with libtool wrapped files]
On Mon, Dec 19, 2005 at 10:22:04AM +0100, Ralf Wildenhues wrote: Hmm. Teaches me to get people to test whether their bugs are indeed fixed. Luckily with HEAD we can point them to the nightly tarball. I think the generation of the snapshot is broken since they changed the anonymous access for cvs. It's still from 2005-12-08. Cvs access got changed on 2005-12-11 and the first commit after 2005-12-08 was 2005-12-16. Kurt ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Reducing dependency_libs to what was on the command line.
On Wed, Dec 07, 2005 at 10:41:47AM +0100, Ralf Wildenhues wrote:
Not if you have to deal with installations lacking .la files.
Really: The only sane way we can get this done without breaking
backward compatibility and retain user-expected behavior is if we
Yes, one problem is that users who have a version that
doesn't walk the dependencies properly, it might not work as
expected, and this would be a problem if I'm using an older
version and try to link to a library that is created with a newer
version.
So how do you feel about adding a new field that only lists the
direct dependencies, and keep the old one around for a while
(until you drop support for older versions?) containing both the
direct and indirect? The newer versions could then only use the
new field if it's present and fall back to the old if it's not.
It's currently the only option I see to make it backward
compatible.
- implement the walking and all that stuff
- make library authors be aware
(ie. they need to state, maybe with a command line switch: I
have listed all my direct dependencies)
I'm not sure how I feel about requiring authors to do that. They
should always link to all their direct dependencies.
I think I need an example of where you think there can be a
problem, because afaik, there shouldn't be any problem. And if
you find an example, I'm guessing it doesn't work portabily now
either.
And also get all of this in a way that Debian can still upgrade
gradually from their current set to the new. I believe it is possible.
For example, if we allow arguments from some environment variable,
or some other debian-build global setting. Would you agree with this?
The only way I can see this working would be to have an
environment variable. Note that there is no such thing as a
global setting, each package will have to manually set that
variable (in the debian/rules file). But that shouldn't be a
problem since people already have to re-libtoolize the package to
get the desired behaviour anyway.
Anyway, I'm not really interested in things that only benefit
Debian. Everybody should be able to benefit from what we're
doing. And I believe this is also in the spirit of our Social
Contract.
What this reduction of the dependencies is mostly about is not
reducing the dependency tree, it should not have any effect on
it, but our ability to change the dependency tree. But I feel
this is getting a little bit off topic. If someone is interested
in what is involved, feel free to ask though.
Well. If people link convenience archives directly in programs
(which they shouldn't, but they do), then this patch will break it.
You also need to take into account that quite a few users
- either don't install the .la files (which we may rightfully,
declare as it's their problem then, but in reality that will
be another maintenance nightmare)
If the .la file isn't installed, it doesn't matter what is in it.
But, on some systems, the library we just compile *will need* to link
against all other libraries. That means, for package authors, they
may need to take into account that they can't rely on installed .la
files taking this burden off of them. Even with the non-transitive
dependency_libs, all libs may need to be listed.
You mean that some people had a .la file at some point, but don't
keep it around? Afaik, this doesn't work.
If you have a libA linked to libB, libA's .la file mentions
either libB's .la file, or -lB. To not make this example too
hard, let's just assume it has libB.la in it.
Now if I want to link something to libA, and libB.la doesn't
exist, libtool will complain that it can't find libB.la and fail.
I've seen this way too many times that it failed.
In case there never was a libB.la, libA.la will just mention -lB,
and there isn't a problem either.
Once a .la file exists, it's hard to remove it without breaking
something.
Besides, you're missing the point here: just because the installed
system does not use .la files, doesn't mean a user that happens to
install below $HOME does not want to use it.
I'm really not following.
And back when the deplibs stuff was discussed (about a year ago) before,
there was another item that came up: Do we want to support the notion of
exposure? I.e., a header accompanying my library libfoo, foo.h, has
static inline foo () { return bar(); }
where bar is from libbar. Even if a user of libfoo believes not to use
libbar directly (after all, only public interfaces of foo are used), it
will be necessary to link against it.
I consider this broken, but unfortuantly it happens way too much.
Anyway, I disagree that it should link to it. The reason you
think you should link to it is because you're using a symbol from
bar. But bar is clearly part of foo's API, and in case bar
changes the API in such a way that it breaks something linked to
foo, both of their API's changed and both of them should do an
soname change (or
Re: Reducing dependency_libs to what was on the command line.
On Tue, Dec 06, 2005 at 08:25:15AM +0100, Ralf Wildenhues wrote: Well. Given above thoughts, I would think that your change makes sense in the link_all_deplibs=no setting, given that the package author knows about this. Erm. Except: what about static linking in that case? I think there is an implicit assumption in ltmain that if P - libA - libB - libC then picking up libA's dependency_libs will give you all you need, ie., you do not need to walk recursively. For static linking, you will need to do this now. ltmain does not implement this walk at the moment. Then that is something that needs to happen. I did some basic tests to see if this worked, and I thought it did, but I didn't really take a close look to it. Now I try to link to libC, and if I only look at libC's .la file, it says it should link to libA and libB, but not to libD. This mean that in case of static linking it will break, unless it also goes and looks at libA's .la file. P -- libC -- libA -- libB `- liBD Correct. It's an instance of the 'ltmain needs to do the walk' issue. Do you know in what cases it does the walk, and in what cases it doesn't do it? What I would like to see is that libC's dependency_libs only have libA in it, and should never contain libB or libD, which is just an implementation detail of libA. True, in the link_all_deplibs=no case. I believe it's also true in the link_all_deplibs=yes case, but only if it does the walk of the dependencies. So the 2 problems I've mentioned (convience libs and adding/removing dependencies) both seem to have a simular solution, reducing the dependency_libs to what was on the command line when making that library. Well, yes, but solving this without breakage simply requires that ltmain walk the dependency chain. So I guess we should concentrate on getting that right. What systems have you tested on? I only have access to GNU/Linux, so I can't test this myself. If you can help out providing tests, I can easily test them on a number of platforms But you want test for HEAD right? Maybe I should try and get this working in HEAD instead. I should probably also get a more recent version in experimental, and maybe I can play with some of those changes there without breaking too much. Well. If people link convenience archives directly in programs (which they shouldn't, but they do), then this patch will break it. You also need to take into account that quite a few users - either don't install the .la files (which we may rightfully, declare as it's their problem then, but in reality that will be another maintenance nightmare) If the .la file isn't installed, it doesn't matter what is in it. - or, and that is more important, where a lot of the installed libraries simply were never created with libtool, e.g., because they stem from a proprietary OS. There, having indirect dependency information is very valuable. So in this case you don't have an .la file either. I'm guess I'm missing the point here. If you're talking about an other library linked to any of those 2, then I agree that it should contain those in it. And my suggestion wouldn't change that. As summary, I think the following needs to happen: - Check that depedencies get walked recursivly, and do it in all cases. - Write tests for all the cases mentioned so far. Some might break with the current versions too. - If that's done, look at reducing the number of dependencies in .la files that get mentioned. Kurt ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Reducing dependency_libs to what was on the command line.
On Mon, Dec 05, 2005 at 09:33:54AM +0100, Ralf Wildenhues wrote: Hi Kurt, * Kurt Roeckx wrote on Mon, Dec 05, 2005 at 12:52:55AM CET: As some of you might know, Debian has a patch to reduce the number of libraries that libtool will link too. Yes. And it's a support nightmare, not only for Debian Libtool, but for us as well, because people do not recognize it's the Debian changes that break their builds. When I have time, I'd like to fix your current issues with it, namely cross-compilation[1], and wrong-libs-for-uninstalled-programs[2]. I'm very aware that it has some problems. And hope to be able to work them out in the future. I still believe this is the right way to go forward. I do not want to have a libtool in Debian that breaks even more, which is why I'm seeking input on this. And also, I very very much would like to change the way this is enabled, in order to both - make this usable for non-Debianers - not unconditionally turn this on for unsuspecting Debian users I'm willing to do this, but I'd rather have that libtool does the right thing by default. I know you have simular plans for a future release, and I hope this can be implemented soon. And now I'd like to reduce it even more. What an other problem is that in case of convience libraries, it also adds all the libraries in the dependency_libs to the depends, and so links with all of those. It should however only link with those they tried to link the convience library with, and not all it's dependency. I don't understand. Please post an example that exposes this change. This is mostly a request of the Debian kde people, but in general for packages making use of conviences libraries. Kde makes alot of use conviences libraries. I was looking at the apollon package, but there are various others. Apollon creates 1 conviences library libkirc.la. It does the following to create it: /bin/sh ../../libtool --mode=link --tag=CXX g++ [...] -o libkirc.la [...] dcchandler.lo kirc.lo kircmessage.lo -L/usr/X11R6/lib -L/usr/share/qt3/lib -L/usr/lib -lkio /usr/lib/libkio.la has this in it: dependency_libs=' -L/usr/lib -L/usr/share/qt3/lib -L/usr/X11R6/lib /usr/lib/libkdeui.la /usr/lib/libkdesu.la /usr/lib/libkwalletclient.la /usr/lib/libkdecore.la /usr/lib/libDCOP.la -lresolv -lutil /usr/lib/libart_lgpl_2.la /usr/lib/libidn.la /usr/lib/libkdefx.la /usr/lib/libqt-mt.la -laudio -lXt -ljpeg -lXi -lXrender -lXrandr -lXcursor -lXinerama -lXft -lfreetype -lfontconfig -ldl -lpng -lXext -lSM -lICE -lpthread /usr/lib/libXrender.la -lX11 -lz /usr/lib/libfam.la -lrpcsvc' And so libkirc.la ends up with: dependency_libs=' -L/usr/X11R6/lib -L/usr/share/qt3/lib -L/usr/lib /usr/lib/libkio.la /usr/lib/libkdeui.la /usr/lib/libkdesu.la /usr/lib/libkwalletclient.la /usr/lib/libkdecore.la /usr/lib/libDCOP.la -lresolv -lutil /usr/lib/libart_lgpl_2.la /usr/lib/libidn.la /usr/lib/libkdefx.la /usr/lib/libqt-mt.la -laudio -lXt -ljpeg -lXi -lXrender -lXrandr -lXcursor -lXinerama -lXft -lfreetype -lfontconfig -ldl -lpng -lXext -lSM -lICE -lpthread /usr/lib/libXrender.la -lX11 -lz /usr/lib/libfam.la -lrpcsvc' What I want is that it says: dependency_libs=' -L/usr/X11R6/lib -L/usr/share/qt3/lib -L/usr/lib /usr/lib/libkio.la' In case of convience libraries, it will add everything from the dependency_libs in the .la file to the depends, and not dependency_libs, so even with the Debian patch, it will link to all those libraries, which is what we want to avoid. What my change does is basicly make it only add the -lkio to the depends. I hope, but did not test, that everything in the libkio.la file ends up in the dependency_libs so that it doesn't break on other platforms. With my change, and the other Debian patch to not link to dependency_libs, this greatly reduces the number of libraries that gets linked too that it doesn't need itself. An other problem we've expierenced in the past is that in case we remove some lib in the chain, all libraries that got (inderectly) linked to it needed to be rebuild to remove the library from their dependency_libs in their .la files. Having all the libraries you need to link to in the .la file is really not a good idea in my opinion. I think this should work recursivly, and find the other libraries it should link to from the .la files it references. Huh? If you use symbols from it, you should link against it -- [...] Maybe I am misunderstanding you again. Let's try to give an example of this. Maybe I should give just start with the opposite example, since it's probably easier the follow. I have a libA that links to a libB. So libA's dependency_libs has libB in it. Then I have a libC, which links against libA, but does not care at all about libB. libC's dependency_libs will have libA and libB in it. Now I start linking libA against libD too. So libA's dependency_libs will have libB and libD in it, but libC's didn't change. Now I try to link to libC
Re: deplibs.test broken.
On Tue, Aug 09, 2005 at 09:41:45AM +0200, Ralf Wildenhues wrote: I have no idea what the intention of this test really is that isn't covered by the other test, so I don't have a suggestion on how to fix it. Did this help? Yes it did. BTW, will you be maintaining the Debian Libtool package? Yes, I will, and that's a problem I came across when trying to make a more recent version of it. I'm just going to disable that test for now. Kurt ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool/ltmain.sh pulling in wrong stdc++
On Wed, Aug 03, 2005 at 01:57:20PM +0200, Graham Leggett wrote: Hi all, I have been having a very strange problem that I have tracked down to libtool, and I don't know how to proceed. I have a Solaris v2.8 machine with a system installed copy of gcc v3.4.2 in /usr/local. Recently a private copy of gcc v4.0.1 was installed in a private directory. The private directory appears first in both PATH and LD_LIBRARY_PATH. I have a project containing C++ code. When this project is built using configure and libtool, an attempt is made to pull in the system stdc++ within /usr/local, and not the stdc++ within the private directory, even though the private gcc and g++ are both in the path and take precedance: Are you sure your libtool has been regenerated for the new g++? Kurt ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: linking of indirect dependencies (dependency_libs) on Linux
On Tue, Aug 02, 2005 at 05:41:32PM +0200, Ralf Wildenhues wrote: Well, I can at least point you to much much more discussion about the general issue. Alas, other (libtool and non-libtool related) work has kept at least me from progressing in this regard. Also, the newer GNU ld switches might want us rethinking this issue, maybe. Are you talking about the --as-needed switch? I've heard this is causing problems in combination with libtool but don't know the details. Maybe Steve knows more? Kurt ___ http://lists.gnu.org/mailman/listinfo/libtool
deplibs.test broken.
Hi, I'm having a few problem with the deplibs.test. It's broken for several reasons: - It's linking a shared lib against a static lib. This is not portable, and we even give a warning about this. - The shared lib is not using any symbols from the static lib. - The test program is linked against the shared lib and using symbols from the static lib. The only reason the test is succesful is that the shared lib isn't using any symbols from the static lib. If it were using symbols from the static lib, the shared lib would have (tried) including whatever is needed to have them, and then linking the shared lib would have failed on some platforms. Using symbols from a library you're not linking to, and is only pulled in by the dependencies really isn't what you want to do either. I have no idea what the intention of this test really is that isn't covered by the other test, so I don't have a suggestion on how to fix it. Kurt ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: shared library depending on static library on Solaris
On Fri, Jun 10, 2005 at 06:31:29PM +0200, Sven Verdoolaege wrote: I just tried this (this is not my development system; I just used the libtool created on another system before) and actually, it passes all tests (and skips one). deplibs_check_method may not be pass_all on your system. [...] SKIP: demo-nopic.test This test is skipped on a few arches like x86-64, hppa and s390, and I think the test shouldn't exists at all. Most arches do not support having non-pic code in a shared lib, for others pic is the default. Afaik, on linux, i386 is the only arch that actually supports non-pic code in a shared lib. Having non-pic code in a shared lib has as effect that the lib actually isn't shared by several processes, so it's a waste of memory. Kurt ___ http://lists.gnu.org/mailman/listinfo/libtool
