Re: FYI: duplicate removal patch [Was Re: ok, new libtool for cygwinupdates]
Hi, On Sun, 1 Apr 2001, Gary V. Vaughan wrote: > > >> Not really. We really must fix the bug that causes us to remove > > >> duplicate libraries before releasing 1.4. > > > > > > Huh? Seems like I'm missing something here. What is this bug exactly? > > > > There is this chunk of code that removes duplicate `-l' flags that > > appear in a link command. The order of `-l' flags is relevant; we > > tell whether it's safe to remove -l flags from the beginning or from > > the end without looking into all other libraries. So we shouldn't do > > it. > > 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. Ciao, Michael. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
AC_TRY_LINK with libtool libraries
Hi, I've been using libtool 1.3c for a while due to needing it so dependency information is correctly obtained from the la files. However, I came to build a binary which uses libtool libraries and found that this version detects that my system should use an executable extention of ".C". This is wrong for my Linux Mandrake 7.2 system. I have however realised that I can also use 1.3b and it detects correctly as "no" in that version. Lastly, I've been trying to check for working version of a custom static library created with libtool which has dependencies on other libraries. In acinclude.m4 I have code which seaches for what it thinks is the correct library and then does an AC_TRY_LINK on it to see if it works ok. The AC_TRY_LINK is failing because it does not use libtool to convert the link line to what it should be. Is there anyway to achieve this as when it does the proper build with libtool it works fine? Thanks for your help, Simon ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: FYI: duplicate removal patch [Was Re: ok, new libtool for cygwin updates]
On Sunday 01 April 2001 11:50 am, Michael Matz wrote: > Hi, > > On Sun, 1 Apr 2001, Gary V. Vaughan wrote: > > > >> Not really. We really must fix the bug that causes us to remove > > > >> duplicate libraries before releasing 1.4. > > > > > > > > Huh? Seems like I'm missing something here. What is this bug > > > > exactly? > > > > > > There is this chunk of code that removes duplicate `-l' flags that > > > appear in a link command. The order of `-l' flags is relevant; we > > > tell whether it's safe to remove -l flags from the beginning or from > > > the end without looking into all other libraries. So we shouldn't do > > > it. > > > > 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? This patch prevents removal of duplicate deplibs; in the test script it tries to link depdemo/l1/libl1.la and depdemo/l2/libl2.la into an executable. Before the patch, the libl2 deplib `libl1.la' was removed from the link command because it was also specified explicitly. Both HEAD and MLB correctly handled `.. -la -lb -la' already. Is there some other situation where duplicates are removed erroneously that I missed? > Ciao, > Michael. Cheers, Gary. -- ___ _ ___ __ _ 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
Re: FYI: duplicate removal patch [Was Re: ok, new libtool for cygwinupdates]
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. Furthermore it really makes no sense to _not_ remove duplicates for shared libs (it only applies to archives), because anyway only the first one is searched for undefined symbols. Ciao, Michael. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: AC_TRY_LINK with libtool libraries
On Sunday 01 April 2001 12:18 pm, s_a_white wrote:
> Hi,
>
> I've been using libtool 1.3c for a while due to needing it so dependency
> information is correctly obtained from the la files. However, I came to
> build a binary which uses libtool libraries and found that this version
> detects that my system should use an executable extention of ".C". This is
> wrong for my Linux Mandrake 7.2 system. I have however realised that I can
> also use 1.3b and it detects correctly as "no" in that version.
libtool uses AC_EXEEXT to detect the executable extension, so I'm surprised
that your results depend on the version of libtool that you are using. Could
you try and debug it?
start by putting something like this near the top of your configure.in:
set -x
AC_EXEEXT
set +x
> Lastly, I've been trying to check for working version of a custom static
> library created with libtool which has dependencies on other libraries. In
> acinclude.m4 I have code which seaches for what it thinks is the correct
> library and then does an AC_TRY_LINK on it to see if it works ok. The
> AC_TRY_LINK is failing because it does not use libtool to convert the link
> line to what it should be. Is there anyway to achieve this as when it does
> the proper build with libtool it works fine?
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
> Thanks for your help,
> Simon
Don't thank me yet =)O|
Cheers,
Gary.
--
___ _ ___ __ _ 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
Re: Support for C++ under Win32
On Friday 30 March 2001 3:54 am, Kevin Atkinson wrote: > I was wondering what the status is for supporting C++ on Win32 in the > multi-language branch of libtool. The g++ support for win32 should not be any worse than for other libtool supported platforms. > In particular I would like to know how > possible it is to build a shared library (dll) with the Win32 version of > Gcc (either, cygwin or mingw). It is a little torturous, but seems to work most of the time. Take a look at CVS m4, or libsnprintfv (on my homepage) for an idea of how to build libtool dlls. > I also need ltdl to work properly under > Win32 so that I can dynamically load a dll at run time so that Pspell will > work under Win32. Apart from brokenness in the DLL design, this also more or less works. It is easy if you build your project from scratch knowing you want DLL builds, but becomes difficult quite quickly if the package author assumed ELF type libs. There is a chapter about all of thes issues in the Goat book, http://sources.redhat.com/autobook/ by the way. > Thanks in advance. Cheers, Gary. -- ___ _ ___ __ _ 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
Re: Libtool eats redundant link objects
On Thursday 15 February 2001 4:47 am, Sam TH wrote: > On Tue, Feb 06, 2001 at 09:12:12PM -0600, Sam TH wrote: > > On Wed, Feb 07, 2001 at 01:02:52AM -0200, Alexandre Oliva wrote: > > > On Feb 6, 2001, Sam TH <[EMAIL PROTECTED]> wrote: > > > > /bin/sh ../../libtool --mode-link c++ -o foo lib1.la lib2.la lib1.la > > > > \ lib2.la lib1.la lib2.la > > > > > > > > Which is what I want. However, libtool then issues this command. > > > > > > > > c++ -o foo ./libs/lib1.a ./libs/lib2.a > > > > > > Which version of libtool are you using? This would definitely be a > > > bug, but I don't think it's a bug present in current CVS versions nor > > > in the latest stable release. > > > > Sadly, this is CVS from a couple days ago. > > > > [sam@bur-jud-175-135 ~/projects/abi-auto/abi]$ ./libtool --version > > ltmain.sh (GNU libtool) 1.3c (1.859 2001/02/02 20:38:52) > > Well, I wrote that message a week ago. Does anyone have any idea why > this is happening? Does it happen on other peoples' systems? After the patch I just applied, I see this: $ cd libtool/depdemo $ ./libtool --version ltmain.sh (GNU libtool) 1.3c (1.878 2001/03/31 23:51:07) $ ./libtool -n --mode=link c++ -o foo l1/libl1.la l2/libl2.la l1/libl1.la c++ -o .libs/foo l1/.libs/libl1.so l2/.libs/libl2.so /home/gary/devel/savannah/libtool/depdemo/l1/libl1.la l1/.libs/libl1.so -Wl,--rpath -Wl,/home/gary/devel/savannah/libtool/tests/_inst/lib Here we have three libl1.so, two from the link line, and a third as a deplib of libl2. > Thanks lots. I'm really at a loss here. I don't want to include > ./libs in the library search path. Thanks for your patience. Could you try again with the HEAD release, and let us know if it is still broken for you? Cheers, Gary. -- ___ _ ___ __ _ 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
Re: DLL problem
On Thursday 08 March 2001 9:09 pm, Lars Stavholm wrote: > > /bin/sh ./libtool --mode=link gcc -g -O2 > > -Lc:/ossasn1/win32.tgt/5.2.0/bin -o libencdec.la -rpath > > /home/stava/proj/nbap_alcap/encdec/lib -no-undefined -release 6.1C > > decoder_main.lo decoder_translate.lo decoder_util.lo encoder_encode_1.lo > > encoder_encode_2.lo encoder_get.lo encoder_main.lo encoder_manage.lo > > encoder_util.lo nbap.lo nbap_decode.lo nbap_encode.lo -lossapi -lcygwin > > -lcygwin libtool is trying (and failing) to find libossapi.la. Since it doesn't understand .lib files, it will find libossapi.a, but refuses to link a static library into a shared library since that is illegal on some platforms. I think you need to make a libossapi.la for libtool to find, so that it can tell the the library it is detecting is an import lib and not a static lib. > Is there any way to accomplish a link with the ossapi.dll in this case? If libossapi is not built by you, you might try specifying the full path to the dll, which should force libtool to use impgen to generate its own import lib on the fly. > /Lars Stavholm ([EMAIL PROTECTED]) Cheers, Gary. -- ___ _ ___ __ _ 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
Re: FYI: duplicate removal patch [Was Re: ok, new libtool for cygwin updates]
Hello. On Sunday 01 April 2001 1:16 pm, Michael Matz wrote: > 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. Yes it does =(O| Although ugly, Robert has applied the following to MLB so that portability at least is not affected in that case: * ltconfig.in: Add a test to find the approximate limit to the length of command line arguments. The number calculated here should always be lower than the actual limit. * ltmain.in: Test the length of the command line to be executed and use an incremtnal linking scheme if the command is too long to be interpreted without error. * doc: Test the length of the command line to be executed and use an incremtnal linking scheme if the command is too long to be interpreted without error. * doc/libtool.texi (Reloadable Objects): Added a few sentences to describe how piecewise linking is done for shared objects by creating reloadable object files. > 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. Removing the deplib listings from Makefile.am would probably make a huge difference to the length of the link lines where deep dependency trees are being used... > Furthermore it really makes no sense to _not_ remove > duplicates for shared libs (it only applies to archives), because anyway > only the first one is searched for undefined symbols. Certainly for modern UNIX architectures, however, I get the impression from Alexandre that there are platforms which do require topologically ordered listings of shared libraries in the final link line in order to be able to locate all of the symbols shared between those libraries. So, unless I am mistaken, the only way to fix that would be to have another case statement to remove shared deplibs only on platforms that are known to handle it well. Yuck. I'm prepared to put the support for that into libtool if Alexandre concurs, but I'll (once again) rely on people to send me host triplets for platforms that can definitely survive the duplicate removal. This is something we can debate between 1.3d and 1.4. > Ciao, > Michael. Cheers, Gary. -- ___ _ ___ __ _ 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
Re: FYI: duplicate removal patch [Was Re: ok, new libtool for cygwinupdates]
Hi, On Sun, 1 Apr 2001, Gary V. Vaughan wrote: > > > > I see. Argh, This then again means, that libtool will probably generate > > excessively large link commands for KDE. > > Yes it does =(O| Although ugly, Robert has applied the following to MLB so > that portability at least is not affected in that case: I know about the incremental linking (but I'm not sure it also applies to libraries, or only to .o files. Given how it works (using ld -r IIRC) it normally only _can_ work with .o's, because _all_ libs have to be mentioned in one link command, to have any effect). But apart from sheer ugliness in link commands I think about another problem I first saw on HP-UX. When a shared lib is mentioned mutiple times on the link command it somehow also ends up multple times in the executable, and when this is run, it tries to load/relocate the same lib again and again (at least an ldd equivalent makes me think so). > > We sometimes list also dependent libs in the makefiles (history and > > Removing the deplib listings from Makefile.am would probably make a huge > difference to the length of the link lines where deep dependency trees are > being used... Yep. I'll see to remove the duplicated stuff from our Makefile.am's. (But those are many ;-) ) > > Furthermore it really makes no sense to _not_ remove > > duplicates for shared libs (it only applies to archives), because anyway > > only the first one is searched for undefined symbols. > > Certainly for modern UNIX architectures, however, I get the impression from > Alexandre that there are platforms which do require topologically ordered > listings of shared libraries in the final link line in order to be able to Hmm, Alexandre? Are there really platforms where this is the case for shared libs? Ciao, Michael. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: FYI: duplicate removal patch [Was Re: ok, new libtool for cygwin updates]
Hello. On Sunday 01 April 2001 3:59 pm, Michael Matz wrote: > On Sun, 1 Apr 2001, Gary V. Vaughan wrote: > > > I see. Argh, This then again means, that libtool will probably > > > generate excessively large link commands for KDE. > > > > Yes it does =(O| Although ugly, Robert has applied the following to MLB > > so that portability at least is not affected in that case: > > I know about the incremental linking (but I'm not sure it also applies to > libraries, or only to .o files. Given how it works (using ld -r IIRC) it > normally only _can_ work with .o's, because _all_ libs have to be > mentioned in one link command, to have any effect). That's true... I was thinking about problems that might arise due to massively increased command line lengths. I suppose we have a new problem now though: What to do where a link command has so many libraries listed, that the command line length limit is reached on certain hosts? Ugh. Perhaps we do need to reinstate duplicate removal on a per-platform basis, and just hope that we don't find a host with severe command line length limits *and* an inability to cope with unordered dependent library lists. Experience shows that platforms that have brain-damage tend to have it in many places or else not at all (or hardly at all), so I expect hoping otherwise is naive. Our only hope is that the original bug remained undetected for so long because no one is trying to use libtool on such a platform right now =(O| > > > Furthermore it really makes no sense to _not_ remove > > > duplicates for shared libs (it only applies to archives), because > > > anyway only the first one is searched for undefined symbols. > > > > Certainly for modern UNIX architectures, however, I get the impression > > from Alexandre that there are platforms which do require topologically > > ordered listings of shared libraries in the final link line in order to > > be able to > > Hmm, Alexandre? Are there really platforms where this is the case for > shared libs? It seems that even if there are, there is little option but to do platformwise duplicate removal if we are to avoid common problems with command line lengths. I'll post a patch in the next day or two. Cheers, Gary. -- ___ _ ___ __ _ 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
Re: FYI: duplicate removal patch [Was Re: ok, new libtool for cygwin updates]
On Apr 1, 2001, "Gary V. Vaughan" <[EMAIL PROTECTED]> wrote:
> On Sunday 01 April 2001 3:59 pm, Michael Matz wrote:
>> On Sun, 1 Apr 2001, Gary V. Vaughan wrote:
>> > Certainly for modern UNIX architectures, however, I get the impression
>> > from Alexandre that there are platforms which do require topologically
>> > ordered listings of shared libraries in the final link line in order to
>> > be able to
>> Hmm, Alexandre? Are there really platforms where this is the case for
>> shared libs?
I don't think so. To the best of my knowledge, ordering is only
relevant for static libraries. But then, shared-library oddities
don't cease to surprise me :-(
> It seems that even if there are, there is little option but to do
> platformwise duplicate removal if we are to avoid common problems with
> command line lengths.
Yep. I think I see a way around the problem. Shared libraries don't
need duplication (we hope), and static libraries can be included in
reloadable links (I hope).
Hmm... But if I static library is listed after a shared library, to
supply undefined symbols in the shared library, we can't reload the
static library disregarding the shared one then put the shared library
back in afterwards. It's not as simple as I had thought :-(
--
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: FYI: duplicate removal patch [Was Re: ok, new libtool for cygwin updates]
On Apr 1, 2001, "Gary V. Vaughan" <[EMAIL PROTECTED]> wrote:
> I have applied the following to HEAD (and similar to MLB).
Thanks
> Okay to release 1.3d?
Ok with me.
--
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: FYI: duplicate removal patch [Was Re: ok, new libtool for cygwin updates]
On Monday 02 April 2001 12:49 am, Alexandre Oliva wrote: > On Apr 1, 2001, "Gary V. Vaughan" <[EMAIL PROTECTED]> wrote: > > It seems that even if there are, there is little option but to do > > platformwise duplicate removal if we are to avoid common problems with > > command line lengths. > > Yep. I think I see a way around the problem. Shared libraries don't > need duplication (we hope), and static libraries can be included in > reloadable links (I hope). > > Hmm... But if I static library is listed after a shared library, to > supply undefined symbols in the shared library, we can't reload the > static library disregarding the shared one then put the shared library > back in afterwards. It's not as simple as I had thought :-( So we reorder the libraries (after deplib expansion) such that the static libs remain in the same relative order, and the shared libs have duplicates removed, and are all listed before the first static lib. Right? The problem we then have is how do we detect what is a shared lib vs a static lib? Especially on pass_all platforms =(O| This is fast becoming a large post-1.4 issue to my mind... Cheers, Gary. -- ___ _ ___ __ _ 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
Re: FYI: duplicate removal patch [Was Re: ok, new libtool for cygwin updates]
On Apr 1, 2001, "Gary V. Vaughan" <[EMAIL PROTECTED]> wrote:
> This is fast becoming a large post-1.4 issue to my mind...
What? Did you really mean to have this problem addresses in 1.4? 1.4
doesn't even have piecewise linking, IIRC.
--
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: FYI: duplicate removal patch [Was Re: ok, new libtool for cygwin updates]
On Monday 02 April 2001 2:31 am, Alexandre Oliva wrote: > On Apr 1, 2001, "Gary V. Vaughan" <[EMAIL PROTECTED]> wrote: > > This is fast becoming a large post-1.4 issue to my mind... > > What? Did you really mean to have this problem addresses in 1.4? Yeah, I though it was going to be a simple matter of adding back the loop that I took out, but having it fire only if `linker_requires_topological_libs' was set to no. Silly me! =)O| > 1.4 doesn't even have piecewise linking, IIRC. That's right. Cheers, Gary. -- ___ _ ___ __ _ 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
[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. * Support for hardcoding run-time paths (-R) into libraries. * Support -dlopen and -dlpreopen for libraries. * Libtool now allows you to link shared libraries against static code. * New functions in libltdl: lt_dlgetinfo, lt_dlhandle_next and lt_dlforeach provide access to module specific data in handles. lt_dlcaller_register, lt_dlcaller_set_data and lt_dlcaller_get_data provide management for user storage of per module data. lt_dlloader_next, lt_dlloader_name, lt_dlloader_find, lt_dlloader_add and lt_dlloader_remove can be used for adding new types of module loaders. lt_dladderror, lt_dlseterror integrate user module loaders with lt_dlerror. * "-Xcompiler" and "-Wc," does now work in compile mode, too. * Support recent dlltool formats. * Start of support code for cross-compiling to win32. * libltdl can now be built as a dll with win32. * m4 macros needed to configure libltdl split out into libltdl/ltdl.m4. * New port to NEWS-OS Release 6. * Improved support for darwin (rhapsody), mingw32, NetBSD, Compaq Tru64 V5.0 and Digital Unix V4.*. * Initial support for ia64 linux. * Initial support for a.out freebsd shared libs. * Initial support for Paul Sokolovsky's pw32 POSIX over win32 layer. * Many bugfixes (especially in libltdl) Happy bug hunting! The libtool team. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
RE: [ANNOUNCE] libtool-1.3d
> -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 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
