Re: 1.5 release
* Alexandre Oliva wrote on Mon, Apr 25, 2005 at 09:27:24PM CEST: On Apr 24, 2005, Ralf Wildenhues [EMAIL PROTECTED] wrote: AC_PROVIDE_IFELSE is not in Autoconf 2.50 (AFAICT it's in 2.52). I don't know if we left its usability through other patches already, but we do still advertise 2.50 compatibility. We have a fallback AC_PROVIDE_IFELSE early in libtool.m4, which enables us to use it even in earlier autoconf. And we actually do use it in AC_PROG_LIBTOOL. Whoops. Blush. :-) I have not tested your patch, but would feel the need to do so quite a bit if I were to put it in. (I have wondered whether to simply answer not strictly a bug, but that would be making it a bit too easy on my side, I guess.) I'm fine with such a decision. I was just surprised when a co-worker reported this bug to me, and it took me a while to even admit this was possible :-) Oh well. I'm sorry then for being dumb. OTOH, I really did not want to start testing _again_, and people have been waiting for this release because of the Solaris regression. Will have a look at it after I'm done forward-porting the couple of patches which are in branch-1-5 only ATM. Unless the other maintainers beat me for it, I will still work on bugs in all three branches, getting 2.0 out should be the prime objective, however. Regards, Ralf
Re: 1.5 release
Hi Alexandre, * Alexandre Oliva wrote on Sun, Apr 24, 2005 at 12:42:42AM CEST: On Apr 23, 2005, Ralf Wildenhues [EMAIL PROTECTED] wrote: -New in 1.5.15a: 2005-??-??; CVS version 1.5.15a, Libtool team: +New in 1.5.16: 2005-04-23; CVS version 1.5.15a, Libtool team: Erhm... If this is going out soon, could we perhaps get the patch I posted for libtool.m4 in, to avoid configuring CXX and F77 in every single libtool script, part of packages that only care about C? I wanted to do the release today, but I will at least wait for the Solaris feedback now. AC_PROVIDE_IFELSE is not in Autoconf 2.50 (AFAICT it's in 2.52). I don't know if we left its usability through other patches already, but we do still advertise 2.50 compatibility. Also, this has been fixed properly in branch-2-0 and above. I have not tested your patch, but would feel the need to do so quite a bit if I were to put it in. (I have wondered whether to simply answer not strictly a bug, but that would be making it a bit too easy on my side, I guess.) So, I'm unsure about this patch. Regards, Ralf Index: ChangeLog from Alexandre Oliva [EMAIL PROTECTED] * libtool.m4 (_LT_AC_TAGCONFIG): Don't bring in CXX and F77 unless the corresponding AC_PROG_ macro was provided.
Re: 1.5 release
Hi Gary, others, * Gary V. Vaughan wrote on Sat, Apr 23, 2005 at 09:40:05AM CEST: Ralf Wildenhues wrote: Another couple of questions that turned up for me and are not dealt with in HACKING (resp. README-alpha): Thanks for catching these! We should capture the concensus in HACKING... Yep. Do I have to increase the serial on libtool.m4 before releasing? Or after releasing? No, because people might like to use CVS versions (once their favourite patches have been incorporated for example), and we want to support them too. The serial on each M4 file should be incremented each time the interface changes, independently of release schedules. OK. No change necessary for branch-1-5 then. For M4 files on branches, we ought to be using cvs like `.' delimited #serial numbers, otherwise a busy branch might end up with a serial number that overtakes the trunk :-o Only version.m4 does this right at the moment. Good thing I don't have to think about this ATM. :) Also the library version of libltdl in libltdl/Makefile.am, right? (libltdl hasn't changed yet from the previous release, but I will try to incorporate the memleak patch). Same answer -- in order to support people who use CVS versions of libtool, the libltdl library versions should be incremented at the time we change the interface. OK. Supporting branched revisions is more difficult here, because we need to be sure that a branch release doesn't 'catch up' with the trunk and start using the same interface numbers that were once used on an older trunk revision. I think the best way to prevent these problems is to incorporate the branch number in the libltdl soname. Ouch. Let's avoid doing anything like that if we can. I think -release is ugly, but it is all we have right now. Releases from branch-1-5 haven't used it thus far, and 1.5.16 doesn't break binary compatibility with 1.5.14, so for branch-1-5 it is too late already I think. If you ask me, I don't want to see _any_ changes on a stable branch except incrementing REVISION, unless absolutely necessary. For branch-2-0, I think we should start using `-release 2.0' right away. Opinions? IMVHO no. We already have a higher CURRENT on branch-2-0 than on HEAD. We need just release 2.2 with a higher CURRENT than 2.0 and be done with it. All I wanted to do is increase REVISION, on branch-1-5. Thanks for answering so quickly. I'll post my proposed README as soon as I have it done (should be today). Regards, Ralf
Re: 1.5 release
On Sat, 23 Apr 2005, Ralf Wildenhues wrote: + +8) Note that using libltdl in conjunction with direct uses of dlopening +mechanisms is not supported. For example, it may work if you use +libltdl but another library you use uses dlopen() directly, but it is +unsupported. What inspired the above? It is normal for there to be multiple users of dlopen() in one program. Without it, most programs won't run at all. They would not even get off the ground. The second sentance is not gramatically correct. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: 1.5 release
* Bob Friesenhahn wrote on Sat, Apr 23, 2005 at 05:13:45PM CEST: On Sat, 23 Apr 2005, Ralf Wildenhues wrote: Suppose, the module libfoo depends on libbar. - main calls lt_dlopen(libfoo) - uses unrelated library libbaz - libbaz dlopens libbar as well - main lt_dlclose(libfoo) leads to dlclose(libbar) - libbaz might still be in use and want to use libbar. You might argue main should have made libbar resident. If so, we should mention that in the docs. Same situation the other way round (lib dlclose()s a module which libltdl still thinks open). Ahhh, I see. But this is not at all close to what the original statement implies. The original statement causes FUD, and implies that terrible things may happen if a program depends on a library which choses to use a different module loader than libltdl for its own modules. That is pretty much the same as saying that KDE and Gnome need not apply. :-) Oooops. Actually, the oops thought occurred to me after your first response. I honestly did not think of the far-reaching consequences of my hastily written words. :-) 8) Note that use of libltdl and a native dlopening mechanism for the same module within one program is not supported. That is much better and makes the failure scenario much more clear. I like this one. Good. It's not completely accurate because of the deplib loading, but I guess it's good enough. For branch-2-0/HEAD I will try to put this into the texinfo documentation. Thank you very much for correcting me on this! Ralf
Re: 1.5 release
On Sat, 23 Apr 2005, Ralf Wildenhues wrote: That is much better and makes the failure scenario much more clear. I like this one. Good. It's not completely accurate because of the deplib loading, but I guess it's good enough. For branch-2-0/HEAD I will try to put this into the texinfo documentation. Adding a reminder that libltdl may load more modules than the requested module (due to module dependencies) would be a good idea. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: 1.5 release
Hi Peter, others, * Peter O'Gorman wrote on Mon, Apr 11, 2005 at 03:54:09PM CEST: Ralf Wildenhues wrote: Oh, I'd be happy either way. If you want to do it, fine with me, too. :) In the unlikely event that you do not upload access to ftp.gnu.org in time, please ask me. Otherwise, thanks for volunteering :) I have it. Severe problems notwithstanding, I'll try. Another couple of questions that turned up for me and are not dealt with in HACKING (resp. README-alpha): Do I have to increase the serial on libtool.m4 before releasing? Or after releasing? Also the library version of libltdl in libltdl/Makefile.am, right? (libltdl hasn't changed yet from the previous release, but I will try to incorporate the memleak patch). Thanks, Ralf
Re: 1.5 release
On Apr 23, 2005, Ralf Wildenhues [EMAIL PROTECTED] wrote: -New in 1.5.15a: 2005-??-??; CVS version 1.5.15a, Libtool team: +New in 1.5.16: 2005-04-23; CVS version 1.5.15a, Libtool team: Erhm... If this is going out soon, could we perhaps get the patch I posted for libtool.m4 in, to avoid configuring CXX and F77 in every single libtool script, part of packages that only care about C? For reference: Index: ChangeLog from Alexandre Oliva [EMAIL PROTECTED] * libtool.m4 (_LT_AC_TAGCONFIG): Don't bring in CXX and F77 unless the corresponding AC_PROG_ macro was provided. Index: libtool.m4 === RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v retrieving revision 1.314.2.81 diff -u -p -r1.314.2.81 libtool.m4 --- libtool.m4 15 Apr 2005 14:40:09 - 1.314.2.81 +++ libtool.m4 17 Apr 2005 04:49:36 - @@ -1701,6 +1701,7 @@ if test -f $ltmain test -n $tagnam echo appending configuration tag \$tagname\ to $ofile case $tagname in +AC_PROVIDE_IFELSE([AC_PROG_CXX],[ CXX) if test -n $CXX ( test X$CXX != Xno ( (test X$CXX = Xg++ `g++ -v /dev/null 21` ) || @@ -1711,6 +1712,8 @@ if test -f $ltmain test -n $tagnam fi ;; +])dnl +AC_PROVIDE_IFELSE([AC_PROG_F77],[ F77) if test -n $F77 test X$F77 != Xno; then AC_LIBTOOL_LANG_F77_CONFIG @@ -1719,6 +1722,7 @@ if test -f $ltmain test -n $tagnam fi ;; +])dnl GCJ) if test -n $GCJ test X$GCJ != Xno; then AC_LIBTOOL_LANG_GCJ_CONFIG -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: 1.5 release
Ralf Wildenhues wrote: Oh, I'd be happy either way. If you want to do it, fine with me, too. :) In the unlikely event that you do not upload access to ftp.gnu.org in time, please ask me. Otherwise, thanks for volunteering :) Peter -- Peter O'Gorman - http://www.pogma.com
