Re: Call for help: Solaris C++ and Sun CC
In regard to: Re: Call for help: Solaris C++ and Sun CC, Ralf Wildenhues...: These two threads contain the patches recently applied to fix the failure with undefined symbols on Solaris with CC (Sun C++ compiler): http://lists.gnu.org/archive/html/libtool-patches/2005-07/msg00088.html http://lists.gnu.org/archive/html/libtool-patches/2005-08/msg00043.html I've never (manually) created these links or the links for libiostream. The system I tested on does not have above unversioned symlinks, and so links against a libCstd.a with PIC objects. Obviously, the libbaz.so created by the 'tagdemo-shared tagdemo-make' tests then has half of libCstd contained in it. Having this huge lib is both uncomfortable and dangerous: when you start linking against several C++ libraries, you can end up with all sorts of very subtle problems. Then I found this documentation. Now I'm unsure whether we should guard against this issue (I'd like to), but more importantly: I don't know how we _can_ guard against it easily. If I'm following that thread correctly, the original problem (needing -lCstd -lCrun -lc for C++) is fixed with Peter's patch and your subsequent fixups. The new issue is that at least Cstd and probably Crun will be linked statically if the admin hasn't added the symlinks in the appropriate place. While I agree in principle that it would be nice for libtool to help people avoid shooting themselves in the foot, I think in this case it's more important to document the danger than it is to completely mitigate it. I say this primarily because there might be quite a lot of work to actually get libtool to protect the user. A comment in the docs and likely also in the Solaris C++ section of the code would be "good enough", I think, unless someone comes up with an easy way to guard against the issue. I suppose the test could be special-cased for Solaris, and ldd or some other tool used after linking to verify that a library we're expecting would show up on the list of NEEDED shared libraries, but that seems like a lot of work. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: CVS branch-2-0 R.I.P.
Hi Albert, On 26 Aug 2005, at 16:38, Albert Chin wrote: On Fri, Aug 26, 2005 at 04:26:57PM +0200, Ralf Wildenhues wrote: * Peter Ekberg wrote on Fri, Aug 26, 2005 at 04:06:05PM CEST: What is the requirements on the autotools for a libtoolized package from HEAD? I heard a rumor that cvs versions were required, at least at some point, is that really the case or was it just a rumor? At the moment they are required after a cvs checkout of Libtool HEAD for building itself. When will HEAD be able to bootstrap with the latest released autoconf/automake? Just as soon as autoconf and automake put out new releases ;-) But really, we would have to back out a lot of patches from libtool HEAD (including another major reorganisation of the source tree) to make that work. And the whole point of dropping branch-2-0 is to bring a 2.0 release closer. The 3 patches I attached to an earlier mail are not too onerous. With those applied to autoconf-2.59 and automake-1.9.6, you can bootstrap right now. Cheers, Gary. -- Gary V. Vaughan ())_. gary@ {lilith.warpmail.net,gnu.org},[EMAIL PROTECTED] Research Scientist ( '/ http://www.tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/{libtool,m4} Technical Author `(_~)_ http://sources.redhat.com/autobook PGP.sig Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: CVS branch-2-0 R.I.P.
On Fri, Aug 26, 2005 at 04:26:57PM +0200, Ralf Wildenhues wrote: > * Peter Ekberg wrote on Fri, Aug 26, 2005 at 04:06:05PM CEST: > > > > What is the requirements on the autotools for a libtoolized > > package from HEAD? I heard a rumor that cvs versions were > > required, at least at some point, is that really the case > > or was it just a rumor? > > At the moment they are required after a cvs checkout of Libtool HEAD for > building itself. When will HEAD be able to bootstrap with the latest released autoconf/automake? -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: CVS branch-2-0 R.I.P.
Hi Peter, On 26 Aug 2005, at 15:06, Peter Ekberg wrote: Gary V. Vaughan wrote: Unless someone yells to the contrary real soon now, I see no reason to continue to maintain branch-2-0 from here on in. What is the requirements on the autotools for a libtoolized package from HEAD? I heard a rumor that cvs versions were required, at least at some point, is that really the case or was it just a rumor? I've just successfully run 'make distcheck' on current libtool HEAD on darwin, using very lightly patch autoconf-2.59, and automake-1.9.6 (patches attached). The resulting libtool tarball should be installable and useable with considerably older versions of the other autotools (there is a small series of automake CVS revisions that won't work, but no released versions... except possibly the extremely ancient). I can personally live with that the person doing the actual libtoolize needs cvs-autotools, but the rest of the developers on the package should not be required to use cvs-autotools. Agreed. Infact, apart from those of us bootstrapping a libtool release, it is a bug for an installed released libtool (including libtoolize) to require non-released autotools. Cheers, Gary. -- Gary V. Vaughan ())_. gary@ {lilith.warpmail.net,gnu.org},[EMAIL PROTECTED] Research Scientist ( '/ http://www.tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/{libtool,m4} Technical Author `(_~)_ http://sources.redhat.com/autobook autoconf-2.59--patch-1--honour-libobj-dir.patch Description: Binary data autoconf-2.59--patch-2--darwin-fortran-crt2-fix.patch Description: Binary data automake-1.9.6--patch-1--honour-libobj-dir.patch Description: Binary data PGP.sig Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: CVS branch-2-0 R.I.P.
* Peter Ekberg wrote on Fri, Aug 26, 2005 at 04:06:05PM CEST: > > What is the requirements on the autotools for a libtoolized > package from HEAD? I heard a rumor that cvs versions were > required, at least at some point, is that really the case > or was it just a rumor? At the moment they are required after a cvs checkout of Libtool HEAD for building itself. Packages libtoolized with CVS Libtool do not need CVS Automake/Autoconf. Packages `libtoolize -ldtl'ed with CVS Libtool /might/ at the moment need CVS Autotools, but I am not sure. Any of the restrictions mentioned in the former paragraph must and will be removed before a stable release. But that will most likely happen after removing all other regressions are fixed and the branch point is created. And yes, we plan on testing all of this before the release. > I can personally live with that the person doing the actual > libtoolize needs cvs-autotools, but the rest of the > developers on the package should not be required to use > cvs-autotools. Neither of them should need this. Not even people working on the release branch of Libtool. Rationale: Libtool is a user of libltdl and should work similar to other users of libltdl. If that use needs CVS Autotools, other packages that use libltdl most likely do, too. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
RE: CVS branch-2-0 R.I.P.
Gary V. Vaughan wrote: > Sent: Friday, August 26, 2005 14:10 > To: Libtool > Subject: CVS branch-2-0 R.I.P. > > Fellow Libtoolers (if you're reading, that means you!), > > I still have reservations, but am otherwise somewhat convinced that > dropping development of branch-2-0 in favour of HEAD is a reasonable > thing > to do at this juncture. Unless someone yells to the contrary > real soon > now, I see no reason to continue to maintain branch-2-0 from > here on in. > > In due course, I think it is fine to release 2.0 from HEAD (or a new > release branch from future trunk HEAD to be precise) even with known > minor bugs, provided that we list them in the release > announcement. In > order to speed the release, and in the spirit of "release early, > release > often", I say we identify the actual showstoppers, and > release 1.9h from > HEAD with just those fixed. There is a list of showstoppers > on my wiki > at http://tkd.kicks-ass.net/GnuLibtoolProject/RoadMap. > > If 1.9h is well received, I believe we should release 2.0 soon after > (minor bugs and all), and then work on the remaining regressions for a > quick 2.0.2. In order to prevent any further slippage, until 2.0.2 is > out there we should reject all patches, and commit changes only for: > > - bugs > - regressions > - documentation > - testsuite improvements > - and maybe MSVC support, iff we can confine changes to this system. > > Speak now, or forever hold your peace. What is the requirements on the autotools for a libtoolized package from HEAD? I heard a rumor that cvs versions were required, at least at some point, is that really the case or was it just a rumor? I can personally live with that the person doing the actual libtoolize needs cvs-autotools, but the rest of the developers on the package should not be required to use cvs-autotools. Cheers, Peter ___ http://lists.gnu.org/mailman/listinfo/libtool
CVS branch-2-0 R.I.P.
Fellow Libtoolers (if you're reading, that means you!), I still have reservations, but am otherwise somewhat convinced that dropping development of branch-2-0 in favour of HEAD is a reasonable thing to do at this juncture. Unless someone yells to the contrary real soon now, I see no reason to continue to maintain branch-2-0 from here on in. In due course, I think it is fine to release 2.0 from HEAD (or a new release branch from future trunk HEAD to be precise) even with known minor bugs, provided that we list them in the release announcement. In order to speed the release, and in the spirit of "release early, release often", I say we identify the actual showstoppers, and release 1.9h from HEAD with just those fixed. There is a list of showstoppers on my wiki at http://tkd.kicks-ass.net/GnuLibtoolProject/RoadMap. If 1.9h is well received, I believe we should release 2.0 soon after (minor bugs and all), and then work on the remaining regressions for a quick 2.0.2. In order to prevent any further slippage, until 2.0.2 is out there we should reject all patches, and commit changes only for: - bugs - regressions - documentation - testsuite improvements - and maybe MSVC support, iff we can confine changes to this system. Speak now, or forever hold your peace. Cheers, Gary. -- Gary V. Vaughan ())_. gary@ {lilith.warpmail.net,gnu.org},[EMAIL PROTECTED] Research Scientist ( '/ http://www.tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/{libtool,m4} Technical Author `(_~)_ http://sources.redhat.com/autobook PGP.sig Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool