Re: branch-2-0 vs CVS HEAD
* Albert Chin wrote on Tue, Aug 23, 2005 at 04:41:58AM CEST: > On Mon, Aug 22, 2005 at 07:54:59PM +0100, Gary V. Vaughan wrote: > > Ralf Wildenhues wrote on libtool-patches: > > >I kept quiet a while ago when Bob first suggested ditching the CVS > > >branch-2-0 and releasing CVS HEAD as 2.0 after a bit of stabilization. > > The showstopper for this plan is that libtool is holding up the next > > release of all the other autotools[1], so we can't release HEAD as is > > without causing headaches for everyone else, because it relies on > > unreleased versions of the tools that are waiting for another libtool > > release. > > libtool-2.0 should not rely on newer autoconf/automake. People simply > won't adopt it. RHEL 4 ships with autoconf-2.59 and automake-1.9.2. > I'm not against requiring the latest, as of now, autoconf/automake, > but relying on autoconf-2.60 and automake-1.10 seems way too > aggressive. Good argument. But the two questions are almost orthogonal: Practically speaking, if the point is that branch-2-0 is to receive all backported regression fixes HEAD sees now, and then revert to subpackage libltdl so that it works with released autotools -- which branch-2-0 doesn't do now, right? -- then it's *still* a lot less work to fork the release right off of current CVS HEAD after that has been fixed, and it gives us a lot better test coverage. So my point is: get HEAD stable now, then branch off and make 2.59/1.9.6 compatible there. Then bootstrap the release with the couple of naughty system-dependent fixes we know of in those autotools versions. Am I missing anything? Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Call for help: Solaris C++ and Sun CC
On Sun, Aug 21, 2005 at 03:46:13PM +0200, Ralf Wildenhues wrote: > So I looked around. I've found this documentation > http://docs-pdf.sun.com/806-7982/806-7982.pdf (page 21): > > | The Sun WorkShop 6 update 2 C++ compiler (5.3) includes a shared > | version of the libCstd library. > | To use the shared version of libCstd, do the following: > | 1. As superuser, manually create the following symbolic links. > | > | example% ln -s /usr/lib/libCstd.so.1 \ > | /opt/SUNWSpro/lib/libCstd.so > | example% ln -s /usr/lib/libCstd.so.1 \ > | /opt/SUNWSpro/lib/v8plus/libCstd.so > | example% ln -s /usr/lib/sparcv9/libCstd.so.1 \ > | /opt/SUNWSpro/lib/v9/libCstd.so We have this compiler on a Solaris 2.6 system and none of /opt/SUNWSpro/lib/libCstd.so, /opt/SUNWSpro/lib/v8plus/libCstd.so, and /opt/SUNWSpro/lib/v9/libCstd.so exist. There is no libCstd.so anywhere in /opt/SUNWspro/lib. Other bits of useful info: http://forum.sun.com/thread.jspa?threadID=25908 > I'd like any feedback about possible solutions, general ideas about the > issue, or just how *your* Sun CC is set up (with or without these links > etc.). Unfortunately, we don't have CC v5.4 to test against. However, everything about 5.5 works with the patch. I say we gamble and ignore everything below CC v5.4 for this patch. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: branch-2-0 vs CVS HEAD
On Mon, Aug 22, 2005 at 07:54:59PM +0100, Gary V. Vaughan wrote: > [Moved to libtool list] > > Ralf Wildenhues wrote on libtool-patches: > >I kept quiet a while ago when Bob first suggested ditching the CVS > >branch-2-0 and releasing CVS HEAD as 2.0 after a bit of stabilization. > >Now I estimate that, for us combined, it might save us a man month > >(whoohoo, maybe even a mythical one :) or more. > > > >This would be a strong argument to do it, IMVHO. > > > >The only problem is: I don't know how we can get CVS HEAD to work fine > >with released Autoconf/Automake versions. ATM I'm not even sure which > >issues there are: > >- LTLIBOBJS in subdirs > >- ? > > The showstopper for this plan is that libtool is holding up the next > release of all the other autotools[1], so we can't release HEAD as is > without causing headaches for everyone else, because it relies on > unreleased versions of the tools that are waiting for another libtool > release. libtool-2.0 should not rely on newer autoconf/automake. People simply won't adopt it. RHEL 4 ships with autoconf-2.59 and automake-1.9.2. I'm not against requiring the latest, as of now, autoconf/automake, but relying on autoconf-2.60 and automake-1.10 seems way too aggressive. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: branch-2-0 vs CVS HEAD
Hallo Ralf, Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Mon, Aug 22, 2005 at 08:54:59PM CEST: Ralf Wildenhues wrote on libtool-patches: I kept quiet a while ago when Bob first suggested ditching the CVS branch-2-0 and releasing CVS HEAD as 2.0 after a bit of stabilization. The only problem is: I don't know how we can get CVS HEAD to work fine with released Autoconf/Automake versions. ATM I'm not even sure which issues there are: The showstopper for this plan is that libtool is holding up the next release of all the other autotools[1], so we can't release HEAD as is without causing headaches for everyone else, because it relies on unreleased versions of the tools that are waiting for another libtool release. I have not understood the exact nature of the dependencies, I guess. That's okay, I forget the details too... except that I keep getting bashed for holding up M4-2.0 by Stepan and Akim! branch-2-0 doesn't need to be perfect before we release it -- as long as it has no known regressions, and good backwards compatibility, then we can work out the wrinkles in patch releases. The problem is that CVS HEAD still *has* regressions: - enabling/disabling static/shared libs is broken - doing so for individual libs in the package is broken (when using the 1.5.x macro names) Gah... http://tkd.kicks-ass.net/WebWiki/GnuLibtoolProject/BugReports/ needs a record of these so I don't forget again... (maybe actually committing your AU_ALIAS patch 2005-05-07 would help?) I still have other outstanding patches? Heck, guess I need to check for unmerged stuff in [EMAIL PROTECTED]/libtool--gary--1.0! Furthermore, it has at least this serious bug in its new functionality: - using libltdl but not as subpackage does not work as advertised (this bug is in part a documentation bug -- LTDL_INIT needs to be suitably documented -- but also the AC_CONFIG_SUBDIRS call from LT_WITH_LTDL needs to be made configurable) Hmm... I'll look into this when --patch-23 is resolved. Then there are a bunch of smaller, mostly system-dependent issues, which I personally would be happy with working on past a release. Is there a public record of these? TODO file? Search string for the list archives? next mail in this thread? ;-) branch-2-0 has these regressions as well (plus currently a couple more). Same questions. I'm genuinely optimistic that we can release 1.9h within 2 weeks, possibly less. And maybe 2.0 can follow the week after if we've done a good job of testing. Okay, I'll take that back. I thought patch-23 was the last regression :-( Then there is one thing I don't understand: How can you get 2.0 to work with Autoconf-2.59 and Automake-1.9.6, if that isn't possible with CVS HEAD? Either I'm misunderstanding, or you'll just have to find a new set of fixes for branch-2-0 than for CVS HEAD, because those all rely on newer Autoconf/Automake. branch-2-0 doesn't currently need CVS autotools (just lightly patched 2.59 and 1.9.6). I can backport patch-23 without changing that. [1] Autoconf-2.60 needs M4-2.0 needs Libtool-2.0 Why does Autoconf-2.60 need M4-2.0, BTW? I forget. Perhaps it was needing to be able to change the macro search path from m4 code? Someone on the Autoconf list will remember. (ISTR that Automake-1.10 is waiting on something here too, but I can't find a record of it in the archives). Actually, I think automake was waiting on the m4 macro search path improvements, and autoconf-2.60 needs automake-1.10. Someone on the Automake list will remember. I see this whole issue as another reason to push for regular point releases, and general releases more often. I like the fact that Automake has had the former up to now. Agreed. Also a reason why none of the tools should make a stable release that needs a CVS revision of any of the others. Actually, we are doing good in respect of point releases with our stable 1.5 branch, and in respect of CVS revision dependencies with our future stable 2.0 branch. *And* we are doing a better job of backward compatibility than either Automake or Autoconf have historically. :-D Cheers, Gary. -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: branch-2-0 vs CVS HEAD
On Mon, Aug 22, 2005 at 07:54:59PM +0100, Gary V. Vaughan wrote: > [1] Autoconf-2.60 needs M4-2.0 needs Libtool-2.0 (ISTR that For what does Autoconf need M4 2.0? ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: branch-2-0 vs CVS HEAD
Hi Gary, * Gary V. Vaughan wrote on Mon, Aug 22, 2005 at 08:54:59PM CEST: > [Moved to libtool list] Thanks. > Ralf Wildenhues wrote on libtool-patches: > >I kept quiet a while ago when Bob first suggested ditching the CVS > >branch-2-0 and releasing CVS HEAD as 2.0 after a bit of stabilization. > >The only problem is: I don't know how we can get CVS HEAD to work fine > >with released Autoconf/Automake versions. ATM I'm not even sure which > >issues there are: > The showstopper for this plan is that libtool is holding up the next > release of all the other autotools[1], so we can't release HEAD as is > without causing headaches for everyone else, because it relies on > unreleased versions of the tools that are waiting for another libtool > release. I have not understood the exact nature of the dependencies, I guess. > branch-2-0 doesn't need to be perfect before we release it -- as long > as it has no known regressions, and good backwards compatibility, then > we can work out the wrinkles in patch releases. The problem is that CVS HEAD still *has* regressions: - enabling/disabling static/shared libs is broken - doing so for individual libs in the package is broken (when using the 1.5.x macro names) (maybe actually committing your AU_ALIAS patch 2005-05-07 would help?) Furthermore, it has at least this serious bug in its new functionality: - using libltdl but not as subpackage does not work as advertised (this bug is in part a documentation bug -- LTDL_INIT needs to be suitably documented -- but also the AC_CONFIG_SUBDIRS call from LT_WITH_LTDL needs to be made configurable) Then there are a bunch of smaller, mostly system-dependent issues, which I personally would be happy with working on past a release. branch-2-0 has these regressions as well (plus currently a couple more). > I'm genuinely optimistic that we can release 1.9h within 2 weeks, > possibly less. And maybe 2.0 can follow the week after if we've done > a good job of testing. Then there is one thing I don't understand: How can you get 2.0 to work with Autoconf-2.59 and Automake-1.9.6, if that isn't possible with CVS HEAD? Either I'm misunderstanding, or you'll just have to find a new set of fixes for branch-2-0 than for CVS HEAD, because those all rely on newer Autoconf/Automake. > [1] Autoconf-2.60 needs M4-2.0 needs Libtool-2.0 Why does Autoconf-2.60 need M4-2.0, BTW? > (ISTR that Automake-1.10 is waiting on something here too, but I can't > find a record of it in the archives). I see this whole issue as another reason to push for regular point releases, and general releases more often. I like the fact that Automake has had the former up to now. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: branch-2-0 vs CVS HEAD
[Moved to libtool list] Ralf Wildenhues wrote on libtool-patches: I kept quiet a while ago when Bob first suggested ditching the CVS branch-2-0 and releasing CVS HEAD as 2.0 after a bit of stabilization. Now I estimate that, for us combined, it might save us a man month (whoohoo, maybe even a mythical one :) or more. This would be a strong argument to do it, IMVHO. The only problem is: I don't know how we can get CVS HEAD to work fine with released Autoconf/Automake versions. ATM I'm not even sure which issues there are: - LTLIBOBJS in subdirs - ? The showstopper for this plan is that libtool is holding up the next release of all the other autotools[1], so we can't release HEAD as is without causing headaches for everyone else, because it relies on unreleased versions of the tools that are waiting for another libtool release. branch-2-0 doesn't need to be perfect before we release it -- as long as it has no known regressions, and good backwards compatibility, then we can work out the wrinkles in patch releases. I'm genuinely optimistic that we can release 1.9h within 2 weeks, possibly less. And maybe 2.0 can follow the week after if we've done a good job of testing. Cheers, Gary. [1] Autoconf-2.60 needs M4-2.0 needs Libtool-2.0 (ISTR that Automake-1.10 is waiting on something here too, but I can't find a record of it in the archives). -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook signature.asc Description: OpenPGP digital signature ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Documentation patch
* Ralf Wildenhues wrote on Sat, Aug 20, 2005 at 11:03:31AM CEST: > > First, please always send patches in unified diff format (option `-d' Argl. That option should've been `-u', of course. > for diff, or just put the line `diff -u' in ~/.cvsrc). That way, they > can be applied also to slightly changed sources. While I'm at it: we also love patches that include ChangeLog entries. :) (HACKING has is all laid out how they are written.) Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
