Re: [egagnon@j-meg.com: Bug#97759: libtool: build problem]
Alexandre Oliva wrote: > Which only means libtool 1.3.5 is buggy for not taking into account > that: > > # Is this an already installed library? > > installed=no > > Looks like someone goofed in the installation of libffi. Hah! So, maybe we should redirect this bug against libffi1-dev. (As a "non" debian developer, I can only submit new bugs;-) Thanks to all for your help. Etienne -- -- Etienne M. Gagnon, M.Sc. e-mail: [EMAIL PROTECTED] Author of SableCC: http://www.sablecc.org/ and SableVM: http://www.sablevm.org/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: custom wrapper script hooks
On May 17, 2001, Havoc Pennington <[EMAIL PROTECTED]> wrote:
> Does that sound like a reasonable feature?
While this has pretty much nothing to do with building and using
libraries, I'll give you that this is a very nice feature, and it fits
in nicely with one of the most important features of libtool, which is
that of helping testing of uninstalled programs, so I'd vote for
installing a patch that implemented it. Would any other libtool
maintainer oppose to this feature?
I suppose this new switch could be useful not only at library creation
time, but also at program creation time.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: [egagnon@j-meg.com: Bug#97759: libtool: build problem]
On May 17, 2001, "Etienne M. Gagnon" <[EMAIL PROTECTED]> wrote:
> Hi,
> Alexandre Oliva wrote:
>> My first guess would be that libffi has been mis-installed. What does
>> /usr/lib/libffi.la look like?
> I have attached it. FYI, everything works well with libtool 1.3.5 &
> automake 1.4.
Which only means libtool 1.3.5 is buggy for not taking into account
that:
> # Is this an already installed library?
> installed=no
Looks like someone goofed in the installation of libffi.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
custom wrapper script hooks
Hi,
I've been setting up the 4 packages glib, pango, atk, and gtk+ to
build as part of one giant tarball.
So this means I link each library against the libtool libs in the
builddir of the other libraries.
The problem here is getting our test and demo programs to run without
actually installing the packages. The issue is that the libraries
depend on various files installed to known locations.
For example, Pango installs a font configuration file in sysconfdir.
When running a test or demo program prior to installation, it can't
find the files in sysconfdir, obviously. Pango supports a
PANGO_RC_FILE env variable, so we hack around the issue with code like
this in each test program:
if (file_exists ("./pangorc")
putenv ("PANGO_RC_FILE=./pangorc");
Or in GTK, where we need to find image loading modules for dlopen()
and an input method config file, we have the following broken hack:
if (g_file_test ("../../gdk-pixbuf/.libs/libpixbufloader-pnm.so",
G_FILE_TEST_EXISTS))
{
putenv ("GDK_PIXBUF_MODULEDIR=../../gdk-pixbuf/.libs");
putenv ("GTK_IM_MODULE_FILE=../../modules/input/gtk.immodules");
}
I'm setting this up to build without installing Pango, so the GTK
programs now all need the Pango hack added as well...
One of the problems with these hacks is that the demo programs
actually get installed. But then we have an installed program with
these bizarre hacks in it, and you can even imagine it being a
security issue.
Getting around to the point: this situation is pretty much equivalent
to setting LD_LIBRARY_PATH in the libtool wrapper scripts around the
test programs. So what would you think of a solution as follows:
- a libtool option such as "-wrapper-script-hook mycode.sh"
- the option forces a wrapper script to be created in all cases
- it inserts mycode.sh into the wrapper script
So mycode.sh.in would contain something like:
export PANGO_RC_FILE=@TEST_PANGO_RC_FILE@
export GDK_PIXBUF_MODULEDIR=@UNINSTALLED_MODULES_DIR@
export GTK_IM_MODULE_FILE=@TEST_IM_MODULES_FILE@
or whatever, mycode.sh is created by configure, and then the wrapper
script ends up with those exports in it, so test programs run nicely.
Does that sound like a reasonable feature?
Havoc
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: [egagnon@j-meg.com: Bug#97759: libtool: build problem]
Hi, Alexandre Oliva wrote: > My first guess would be that libffi has been mis-installed. What does > /usr/lib/libffi.la look like? I have attached it. FYI, everything works well with libtool 1.3.5 & automake 1.4. Etienne -- -- Etienne M. Gagnon, M.Sc. e-mail: [EMAIL PROTECTED] Author of SableCC: http://www.sablecc.org/ and SableVM: http://www.sablevm.org/ # libffi.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.3.5 (1.385.2.206 2000/05/27 11:12:27) # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='' # Names of this library. library_names='libffi.so.1.1.3 libffi.so.1 libffi.so' # The name of the static archive. old_library='libffi.a' # Libraries that this one depends upon. dependency_libs='' # Version information for libffi. current=2 age=1 revision=3 # Is this an already installed library? installed=no # Directory that this library needs to be installed in: libdir='/usr/lib'
Re: [MLB] BUG in install when piecewise linking
On May 17, 2001, Robert Boehne <[EMAIL PROTECTED]> wrote:
> Can we get around these problems easier in the binary-branch?
I'm not sure it's going to be easier, but it's hopefully going to be
far more efficient :-)
> I envision a binary libtool that could do all of the processing
> itself, without needing to use sed or shell until it needed to
> call a compiler.
Yep.
> Since users can use GNU sed on the two affected platforms, there's a
> simple workaround, and that leads me to a more protracted but more
> complete solution to the problem.
Agreed. In fact, that's the only way out for the moment. I wish we
could at least warn the users about the problem, though. That would
be better than simply failing.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: lots of -lresolv added to command line?
On May 17, 2001, Ossama Othman <[EMAIL PROTECTED]> wrote:
> On the other hand, shouldn't libtool be able to handle stuff like this
> without producing dozens of consecutive duplicates?
The heuristics we use is that, if a library is explicitly listed more
than once in the dependence list of a single library, we don't ever
remove duplicates of it. If such a library is used as a dependence of
multiple other libraries, the duplicate dependency will end up
appearing multiple times in their dependency lists.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: [egagnon@j-meg.com: Bug#97759: libtool: build problem]
On May 17, 2001, Ossama Othman <[EMAIL PROTECTED]> wrote:
> Bug report for libtool 1.4 from a Debian user. Any ideas?
My first guess would be that libffi has been mis-installed. What does
/usr/lib/libffi.la look like?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: [MLB] BUG in install when piecewise linking
On Thursday 17 May 2001 5:49 pm, Robert Boehne wrote: > Alexandre Oliva wrote: > > On May 9, 2001, Robert Boehne <[EMAIL PROTECTED]> wrote: > > > So the problem seems to be that when relink_command is formed, > > > it's passed through bug-ridden vendor sed. If there is another way > > > to build $relink_command without running into this problem, I'd > > > like to hear suggestions. :) > > > > One alternative would be to try to figure out the maximum line length > > supported by sed, and use that as an upper bound for the command-line > > length limit. Then, we could use new-lines instead of semicolons as > > command separators in relink_command. > > Alexandre: > > Can we get around these problems easier in the binary-branch? > I envision a binary libtool that could do all of the processing > itself, without needing to use sed or shell until it needed to > call a compiler. Since users can use GNU sed on the two affected > platforms, there's a simple workaround, and that leads me to a > more protracted but more complete solution to the problem. > Is that part of the current plan, and do you all think it > should be? This sounds like a reasonable plan to me. If the binary-branch implementation is a way off, it would be nice to try to detect the failure mode and warn the user that they need to install GNU sed for sanity's sake. Failing that, add something to the TODO file so we don't forget that it needs addressing. Cheers, Gary. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' `& `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook=`---d__/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: lots of -lresolv added to command line?
Hi Thomas, On Thu, May 17, 2001 at 07:02:50PM +0200, Thomas Tanner wrote: > On 17-May-2001 Ossama Othman wrote: > > /bin/sh ../../libtool --mode=link gcc -Wall -Wmissing-prototypes > > -Wpointer-arith -Wbad-function-cast -Wmissing-declarations -Wnested-externs > > -g -O2 -o ipropd-slave ipropd_slave.o libkadm5srv.la > > ../../lib/hdb/libhdb.la ../../lib/krb5/libkrb5.la ../../lib/asn1/libasn1.la > > -lcrypto ../../lib/vers/libvers.la ../../lib/roken/libroken.la -ldb -lgdbm > > -ldl -lresolv -lresolv > > ^^^ simply remove the second -lresolv Okay, I'll pass your suggestion on to the Debian user who had the problem. Thanks Thomas! On the other hand, shouldn't libtool be able to handle stuff like this without producing dozens of consecutive duplicates? -Ossama -- Ossama Othman <[EMAIL PROTECTED]> Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
RE: lots of -lresolv added to command line?
Hi On 17-May-2001 Ossama Othman wrote: > /bin/sh ../../libtool --mode=link gcc -Wall -Wmissing-prototypes > -Wpointer-arith -Wbad-function-cast -Wmissing-declarations -Wnested-externs > -g -O2 -o ipropd-slave ipropd_slave.o libkadm5srv.la > ../../lib/hdb/libhdb.la ../../lib/krb5/libkrb5.la ../../lib/asn1/libasn1.la > -lcrypto ../../lib/vers/libvers.la ../../lib/roken/libroken.la -ldb -lgdbm > -ldl -lresolv -lresolv ^^^ simply remove the second -lresolv Thomas Tanner - email: tanner@(ffii.org|gnu.org|gmx.de) web: http://home.pages.de/~tanner UMI: http://umi.ffii.org ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
DLLs with mingw or cygwin
Hi, I though that now that libtool-1.4 was released, I could finally have my project to directly release a dll. Unfortunately, that is not the case. So I made a fake very simple library using autoconf, automake, libltdl, libtool-1.4. Making it as clean as I could, reading the autobook and libtool info pages. It works perfectly well under linux. It compiles without any error under both cygwin and mingw... _but_ it does not create any dll under both of them. So is this possible to get dlls that way without any post compilation magical command lines? If so, would someone be as helpfull as taking a look at this: http://inova.snv.jussieu.fr/~sable/libfake.tar.gz and explaining me what I am doing wrong. If not, any trick that could generate a dll from this package would be welcomed. thanks in advance -- Sébastien Sablé <[EMAIL PROTECTED]> http://inova.snv.jussieu.fr/~sable/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [MLB] BUG in install when piecewise linking
Alexandre Oliva wrote: > > On May 9, 2001, Robert Boehne <[EMAIL PROTECTED]> wrote: > > > So the problem seems to be that when relink_command is formed, > > it's passed through bug-ridden vendor sed. If there is another way > > to build $relink_command without running into this problem, I'd > > like to hear suggestions. :) > > One alternative would be to try to figure out the maximum line length > supported by sed, and use that as an upper bound for the command-line > length limit. Then, we could use new-lines instead of semicolons as > command separators in relink_command. > Alexandre: Can we get around these problems easier in the binary-branch? I envision a binary libtool that could do all of the processing itself, without needing to use sed or shell until it needed to call a compiler. Since users can use GNU sed on the two affected platforms, there's a simple workaround, and that leads me to a more protracted but more complete solution to the problem. Is that part of the current plan, and do you all think it should be? Robert -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: lots of -lresolv added to command line?
Hi Robert, > > -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv >-lresolv -lresolv -lresolv ../../lib/krb5/.libs/libkrb5.so -lresolv -lresolv -lresolv >/home/bam/source/ext2fs/heimdal-0.3e/build-tree/heimdal-0.3e/lib/asn1/.libs/libasn1.so > -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv >/home/bam/source/ext2fs/heimdal-0.3e/build-tree/heimdal-0.3e/lib/roken/.libs/libroken.so > -lresolv -lresolv -lresolv -lresolv -lresolv ../../lib/asn1/.libs/libasn1.so >/home/bam/source/ext2fs/heimdal-0.3e/build-tree/heimdal-0.3e/lib/com_err/.libs/libcom_err.so > -lresolv -lresolv -lresolv -lresolv ../../lib/vers/.libs/libvers.al -lresolv >-lresolv ../../lib/roken/.libs/libroken.so -lresolv -lcrypto -lresolv -lresolv -ldb >-lgdbm -ldl -lresolv -lresolv > > creating ipropd-slave > > > > Ossama: > > That depends on your point of view. :) I don't think we totally > resolved this issue when it came up last time, so I'll rehash. > The duplicate library opetions are preserved to support some systems' > static library linking that needs to have dependent libraries > linked in particular order, sometimes that means with duplicates. > So code was added to Libtool to preserve duplicates, or rather > duplicate removal code was taken out. This turned out to cause > problems when the list of duplicates gets long, often too long > for the shell to execute. So this code was revised to find 'special' > libraries $special_deplibs, and preserve only those in duplicates. > I can't tell you how these get deemed "special" though. Right, I recall that. However, having a dozen or so libraries with the same name one after the other such as above seems really unnecessary. Can't we just check if two consecutive libraries in the link command are the same, and if so then zap the second one. A library certainly shouldn't depend on itself. Doing so would fix the duplicate consecutive libraries (e.g. "-lresolv -lresolv -lresolv") and still retain the semantics of having more than one instance of the library in the link command such as "-lgcc -lfoo -lgcc." -Ossama -- Ossama Othman <[EMAIL PROTECTED]> Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: lots of -lresolv added to command line?
Ossama Othman wrote: > > Hi, > > Here's another libtool 1.4 bug report from a Debian user: > > --- > Is this a bug or a feature? > > /bin/sh ../../libtool --mode=link gcc -Wall -Wmissing-prototypes -Wpointer-arith >-Wbad-function-cast -Wmissing-declarations -Wnested-externs -g -O2 -o ipropd-slave >ipropd_slave.o libkadm5srv.la ../../lib/hdb/libhdb.la ../../lib/krb5/libkrb5.la >../../lib/asn1/libasn1.la -lcrypto ../../lib/vers/libvers.la >../../lib/roken/libroken.la -ldb -lgdbm -ldl -lresolv -lresolv > gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wbad-function-cast >-Wmissing-declarations -Wnested-externs -g -O2 -o .libs/ipropd-slave ipropd_slave.o >./.libs/libkadm5srv.so -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv >-lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv >-lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv >/home/bam/source/ext2fs/heimdal-0.3e/build-tree/heimdal-0.3e/lib/hdb/.libs/libhdb.so >-lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv >-lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv >-lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv >-lresolv -lresolv ../../lib/hdb/.libs/libhdb.so >/home/bam/source/ext2fs/heimdal-0.3e/build-tree/heimdal-0.3e/lib/krb5/.libs/libkrb5.so > -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv >-lresolv -lresolv -lresolv -lresolv -lresolv ! -lresolv > -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv >-lresolv -lresolv -lresolv ../../lib/krb5/.libs/libkrb5.so -lresolv -lresolv -lresolv >/home/bam/source/ext2fs/heimdal-0.3e/build-tree/heimdal-0.3e/lib/asn1/.libs/libasn1.so > -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv >/home/bam/source/ext2fs/heimdal-0.3e/build-tree/heimdal-0.3e/lib/roken/.libs/libroken.so > -lresolv -lresolv -lresolv -lresolv -lresolv ../../lib/asn1/.libs/libasn1.so >/home/bam/source/ext2fs/heimdal-0.3e/build-tree/heimdal-0.3e/lib/com_err/.libs/libcom_err.so > -lresolv -lresolv -lresolv -lresolv ../../lib/vers/.libs/libvers.al -lresolv >-lresolv ../../lib/roken/.libs/libroken.so -lresolv -lcrypto -lresolv -lresolv -ldb >-lgdbm -ldl -lresolv -lresolv > creating ipropd-slave > Ossama: That depends on your point of view. :) I don't think we totally resolved this issue when it came up last time, so I'll rehash. The duplicate library opetions are preserved to support some systems' static library linking that needs to have dependent libraries linked in particular order, sometimes that means with duplicates. So code was added to Libtool to preserve duplicates, or rather duplicate removal code was taken out. This turned out to cause problems when the list of duplicates gets long, often too long for the shell to execute. So this code was revised to find 'special' libraries $special_deplibs, and preserve only those in duplicates. I can't tell you how these get deemed "special" though. Has this changed in the merge? Did we ever find a solution that makes everyone happy? Cheers, Robert -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
