duplicates
Hi! I found this in libtol/Changelog 2001-03-31 Gary V. Vaughan <[EMAIL PROTECTED]> * ltmain.in: Remove the code for stripping duplicate deplibs from libtool link lines -- duplicates are somtimes necessary to satisfy inter-library dependencies, and never cause link to fail even if they are spurious. And would like to note that this has been added back then because the Solaris shell dies when the link line becomes longer then ~1000 bytes, which happens quite fast if you're having 12 libs requiring each other in a chain (e.g. KDE libraries). Back then it was also about duplicating -L entries, maybe it works now nonetheless. Greetings, Stephan -- Teigwaren heissen Teigwaren, weil sie Teig waren * J. v. d. Lippe MFCH ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: FYI: duplicate removal patch [Was Re: ok, new libtool for cygwinupdates]
Michael Matz wrote: > > Hi, > > On Sun, 1 Apr 2001, Gary V. Vaughan wrote: > > > > > > > > I have applied the following to HEAD (and similar to MLB). > > > > > > Why also MLB? Was it really broken there too? I ask, because I > > > _definitely_ got multiple libraries in link commands. > > > > Try out the new depdemo-dups.test on an old libtool script, and you'll see > > what I mean. Perhaps I have found and fixed a similar but different bug? > > I see. Argh, This then again means, that libtool will probably generate > excessively large link commands for KDE. We sometimes list also dependent > libs in the makefiles (history and lazyness), and this then cumulates over > many libraries. Hmm, OK I need to check, if this really is so, but I > suspect it. I can confirm this. Some .la files created by NetBSD KDE 2 pkgs have dependency_libs entries that are bigger than 2048 characters long. ATM, the buffer in ltdl.c is currently set to 1024. -lm and -lXmu appear far more than they need to... Nick -- aka [EMAIL PROTECTED], [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [ANNOUNCE] libtool-1.3d
Ooops. Well. Err. You should read it like a ChangeLog, with more recent changes at the top. Yeah, that's it. Cheers, Gary. On Monday 02 April 2001 5:46 am, Robert Collins wrote: > > -Original Message- > > From: Gary V. Vaughan [mailto:[EMAIL PROTECTED]] > > Sent: Monday, April 02, 2001 12:43 PM > > To: Libtool > > Subject: [ANNOUNCE] libtool-1.3d > > > > > > After 21 months in heavy development, the Libtool Team is > > pleased to announce > > alpha release 1.3d of GNU libtool. If this release generates > > a low number of > > bug reports, libtool-1.4 could be just a few short weeks away! > > > > libtool-1.3d is be available from alpha.gnu.org and via > > anonymous CVS, using > > the tag release-1-3d. See > > http://www.gnu.org/software/libtool/libtool.html#AnonymousCVS for > > instructions on how to retrieve libtool from anonymous cvs. > > Diffs and xdeltas > > from 1.3b to 1.3d, are also available from the ftp server. > > > > The most important user-visible changes since release 1.3b follow: > > > > New in 1.3d: 2001-04-02 > > * ltconfig is no more. Generation of libtool happens directly from > > the configure file. > > * Multithread safe with lt_dlmutex_register callback registration. > > * New -no-install flag to avoid the use of executable wrapper scripts. > > * New --with-pic, -prefer-pic and -prefer-non-pic flags to control > > the generation of PIC/non-PIC code. > > * New --build flag to ltconfig to help with build cross compilation > > environments is inherited from --build flag passed to configure. > > Uhmm, but ltconfig is no more. I'm confused :] > > Rob -- ___ _ ___ __ _ mailto: [EMAIL PROTECTED] / __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ [EMAIL PROTECTED] | (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \ \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/ home page: /___/ /___/ gpg public key: http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/key.asc ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
(no subject)
Dear libtool'ers, just played around with libtool-1.3d.tar.gz ... under Win32. It worked perfectly with a Cygwin distro. Thanks for your efforts on that. Now I do have two feature request (do not know if ever possible...): 1) AC_LIBTOOL_WIN32_DLL should have two optional arguments like AC_LIBTOOL_WIN32_DLL(__FOO_EXPORT__, __FOO_IMPORT__) specifying the ex- and import flag when building/linking to the library. The default pic_flag is DLL_EXPORT which is hardcoded into libtool. 2) Will it be possible to make the same efforts for MinGW ? I tried that too and ran into a problem with unresolved symbols when linking to the dll, which got correctly build anyway. Furthermore there ran a minor text formatting "bug" into my configure script. It states: --disable-libtool-lock avoid locking (might break parallel builds) dnl --with-pic try to use only PIC/non-PIC objects [default=use both] I guess the "dnl" line should not be there. Anyway, great work 'till now ! Thanks in advacnce, [EMAIL PROTECTED] PS: Could you please reply to my personal address too, when replying at all ? ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: AC_TRY_LINK with libtool libraries
On Apr 1, 2001, "Gary V. Vaughan" <[EMAIL PROTECTED]> wrote:
> This is a known deficiency in the coupling between libtool and autoconf,
> which needs fixing at some point. In the mean time how about (wild guess
> here!):
> save_CC=$CC
> CC="${SHELL-/bin/sh} ${top_srcdir)/libtool $CC"
> AC_TRY_LINK(blah)
> CC=$save_CC
This doesn't work. libtool needs two-pass compile&link, whereas
AC_TRY_LINK assumes $CC can take a source file and generate an
executable directly out of it.
--
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
