Re: 2.4 Release in 24hrs
Hi Ralf, Den 2010-09-20 19:41 skrev Ralf Wildenhues: I'd really appreciate if you guys could send build logs to the autobuild server as I've been doing lately, much more than just posting non-verbose results on the list here. You don't need to have autobuild installed. When Eric installs autobuild.m4 you don't need to do anything else. Here's what I use, more or less, to create the logs: ( ../libtool/configure [OPTIONS] \ make \ make -k check cat test-suite.log tests/testsuite.log if tail tests/testsuite.log | grep '^| ' /dev/null; then :; else sed 's/^/| /' config.log fi ) logfile $sanitize logfile mail libtool_autobuild.josefsson.org logfile with the underscore replaced by @. For now, OPTIONS includes autobuild_mode=bla if there is anything special about the build. If I do post there, will a human (you?) or a robot process the mail? Is the Subject: important? I have plans to soon mail output from the v2.4 tag with OPTIONS as below on MSYS: autobuild_mode=msvc \ CC=/c/cygwin/home/peda/automake/lib/compile cl \ CFLAGS=-MD -Zi -EHsc \ CXX=/c/cygwin/home/peda/automake/lib/compile cl \ CXXFLAGS=-MD -Zi -EHsc \ LD=link \ NM=dumpbin -symbols \ STRIP=: \ AR=/c/cygwin/home/peda/automake/lib/ar-lib lib \ RANLIB=: \ F77=no \ FC=no \ GCJ=no \ --enable-dependency-tracking and as below on Cygwin: autobuild_mode=msvc \ CC=/home/peda/automake/lib/compile cl \ CFLAGS=-MD -Zi -EHsc \ CXX=/home/peda/automake/lib/compile cl \ CXXFLAGS=-MD -Zi -EHsc \ LD=link \ NM=dumpbin -symbols \ STRIP=: \ AR=/home/peda/automake/lib/ar-lib lib \ RANLIB=: \ F77=no \ FC=no \ GCJ=no \ --enable-dependency-tracking \ lt_cv_to_host_file_cmd=func_convert_file_cygwin_to_w32 \ lt_cv_to_tool_file_cmd=func_convert_file_cygwin_to_w32 \ Should I have set autobuild_mode to something else? I'll fiddle the already generated output if so... Cheers, Peter ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
Hi Gary, Den 2010-09-19 06:03 skrev Gary V. Vaughan: I'm planning to make the belated 2.4 release in about 24 hours. Just a friendly ping, but only just now I pushed a change to the 'compile' script in automake and would like the new version in the release if it's not too much to ask for. Thanks! Cheers, Peter ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On 9/20/2010 1:41 PM, Ralf Wildenhues wrote: I'd really appreciate if you guys could send build logs to the autobuild server... Here's what I use, more or less, to create the logs: ( ../libtool/configure [OPTIONS] \ make \ make -k check cat test-suite.log tests/testsuite.log if tail tests/testsuite.log | grep '^| ' /dev/null; then :; else sed 's/^/| /' config.log fi ) logfile $sanitize logfile mail libtool_autobuild.josefsson.org logfile with the underscore replaced by @. For now, OPTIONS includes autobuild_mode=bla if there is anything special about the build. See, that's what was missing. You had asked about a month ago for me to save all the logs from my various tests...but I had no idea what to DO with them. Anyway, those are all a month out of date, so I'll test the 2.4 release on those platforms and submit new reports. We should probably create some sort of reporting script (post 2.4, of course) and mention it (and its usage) in HACKING. Perhaps also in the message you get at the end of the new testsuite when there are failing tests. Right now that message says (for instance): = Please send `tests/testsuite.log' and all information you think might help: To: bug-libtool_gnu.org Subject: [GNU Libtool 2.2.11a] testsuite: 78 112 failed You may investigate any problem if you feel able to do so, in which case the test suite provides a good starting point. Its output may be found below `tests/testsuite.dir'. = -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
Hi Chuck, Peter, Automakers, On 22 Sep 2010, at 05:02, Charles Wilson wrote: Peter Rosin wrote: Just a friendly ping, but only just now I pushed a change to the 'compile' script in automake and would like the new version in the release if it's not too much to ask for. Thanks! Errr...is that kosher? I thought libtool was only supposed to ship the scripts provided by released versions of automake, not git head copies... Otherwise, if I autoreconf the libtool source archive, then I will downgrade 'compile' et al unless I take special steps. I don't recall having done so in a while but, according to bootstrap: # It is okay for the bootstrap process to require unreleased autoconf # or automake, as long as any released libtool will work with at least # the newest stable versions of each. Generally, newer versions offer # better features, and configure.ac documents oldest version of each # required for bootstrap (AC_PREREQ, and AM_INIT_AUTOMAKE). And in the release template in HACKING: You will then need to have recent (possibly as yet unreleased) versions of Automake and Autoconf installed to bootstrap the checked out sources yourself. So, I will install git automake at the front of my PATH, and if the release process works, then I'll go ahead and use it for the release. Automake gurus: Is there a better way to save rebootstrappers from accidental downgrade than specifying AM_INIT_AUTOMAKE([1.11a]) in libtool's configure.ac? Pity Automake doesn't use gnulibs `git-version-gen' so that I could specify the particular revision with the compile script patch that we want at libtool bootstrap time. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On 9/21/2010 9:21 PM, Gary V. Vaughan wrote: I don't recall having done so in a while but, according to bootstrap: # It is okay for the bootstrap process to require unreleased autoconf # or automake, as long as any released libtool will work with at least # the newest stable versions of each. Generally, newer versions offer # better features, and configure.ac documents oldest version of each # required for bootstrap (AC_PREREQ, and AM_INIT_AUTOMAKE). And in the release template in HACKING: You will then need to have recent (possibly as yet unreleased) versions of Automake and Autoconf installed to bootstrap the checked out sources yourself. So, I will install git automake at the front of my PATH, and if the release process works, then I'll go ahead and use it for the release. OK. If it's documented, then that's fine. Is there a better way to save rebootstrappers from accidental downgrade than specifying AM_INIT_AUTOMAKE([1.11a]) in libtool's configure.ac? Pity Automake doesn't use gnulibs `git-version-gen' so that I could specify the particular revision with the compile script patch that we want at libtool bootstrap time. Well, now that I think about it, it doesn't REALLY matter (to me). The only case, at this time, in which you need the compile script IN libtool to be latest-n-greatest is if you are building libtool itself using cl.exe/MSVC. I'm not. So...it doesn't matter if I downgrade the compile script by rebootstrapping with released automake. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
* Gary V. Vaughan wrote on Wed, Sep 22, 2010 at 03:21:55AM CEST: On 22 Sep 2010, at 05:02, Charles Wilson wrote: Peter Rosin wrote: Just a friendly ping, but only just now I pushed a change to the 'compile' script in automake and would like the new version in the release if it's not too much to ask for. Thanks! Errr...is that kosher? I thought libtool was only supposed to ship the scripts provided by released versions of automake, not git head copies... No. See Makefile.maint, where the 'fetch' target explicitly fetches the git master copies of some scripts, including 'compile'. As long as you run fetch after bootstrap, there is no need for you to do anything else at all. You should not need to use git Automake for this, and please don't, because it currently carries a small regression over 1.11.1. I'll fix it ASAP, but just haven't had the time for it yet. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
* Charles Wilson wrote on Wed, Sep 22, 2010 at 12:10:39AM CEST: On 9/20/2010 1:41 PM, Ralf Wildenhues wrote: I'd really appreciate if you guys could send build logs to the autobuild server... Here's what I use, more or less, to create the logs: See, that's what was missing. You had asked about a month ago for me to save all the logs from my various tests...but I had no idea what to DO with them. Anyway, those are all a month out of date, so I'll test the 2.4 release on those platforms and submit new reports. Even sending out of date logs is worthwhile. We should probably create some sort of reporting script (post 2.4, of course) and mention it (and its usage) in HACKING. Perhaps also in the message you get at the end of the new testsuite when there are failing tests. Yes. All on the TODO list for after this release. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On 22 Sep 2010, at 11:29, Ralf Wildenhues wrote: You should not need to use git Automake for this, and please don't, because it currently carries a small regression over 1.11.1. Ah, okay. If it was taken care of by fetch already, then there was no need for Peter to ping me :) Thanks for the heads up before releasing with 1.11a though. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
* Gary V. Vaughan wrote on Wed, Sep 22, 2010 at 06:42:53AM CEST: On 22 Sep 2010, at 11:29, Ralf Wildenhues wrote: You should not need to use git Automake for this, and please don't, because it currently carries a small regression over 1.11.1. Ah, okay. If it was taken care of by fetch already, then there was no need for Peter to ping me :) I made Peter do it, in case you already started in the HACKING list, as the update to 'compile' might not have otherwise shown up as git changes in Libtool at all. Sorry for the resulting confusion, all mine. Thanks for the heads up before releasing with 1.11a though. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On Sun, 19 Sep 2010, Charles Wilson wrote: Odd. My last test on MinGW was very successful. This was version 1.3266 (ef56e98f3 IIRC). I'll give it another go @ f0584085. MinGW/MSYS: old -- All 122 tests passed (2 tests were not run) new -- 108 tests behaved as expected. 12 tests were skipped. With Charles Wilson's assistance, I updated my MinGW environment to the latest, but using the latest TDM GCC 4.5.1 compiler (only C C++ supported). These were the results: ERROR: 102 tests were run, 6 failed (4 expected failures). 18 tests were skipped. The test which failed (twice) was the C++ exception handling test. Similar tests also failed in the GraphicsMagick test suite so it seems that C++ exceptions are unreliable with this compiler. As a side note, I find that the GNU make delivered with current MinGW is at least 60X slower than before. It takes GNU make 2.5 minutes before it does any actual work (while building GraphicsMagick), which represents most of the compilation time with the previous make. A one-year old Cygwin make takes maybe 1.5 seconds to start working when given the same environment. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On 9/20/2010 11:31 AM, Bob Friesenhahn wrote: On Sun, 19 Sep 2010, Charles Wilson wrote: MinGW/MSYS: old -- All 122 tests passed (2 tests were not run) new -- 108 tests behaved as expected. 12 tests were skipped. With Charles Wilson's assistance, I updated my MinGW environment to the latest, but using the latest TDM GCC 4.5.1 compiler (only C C++ supported). These were the results: ERROR: 102 tests were run, 6 failed (4 expected failures). 18 tests were skipped. The test which failed (twice) was the C++ exception handling test. Similar tests also failed in the GraphicsMagick test suite so it seems that C++ exceptions are unreliable with this compiler. This is really strange. TDM's builds include special support *specifically* addressing C++ exception handling when linking against the static libstdc++ (and, IIUC, linking against the shared libstdc++ Just Works(tm) for both TDM and mingw.org compilers). IIRC, TDM's compilers link against static libstdc++ by default, and mingw.org's link against the shared libstdc++ by default -- but I'll need to double check that. Bob, if I were you I'd raise this as a bug on TDM's sf page: http://tdm-gcc.tdragon.net/bugs http://sourceforge.net/tracker/?group_id=200665atid=974439 because if it works with mingw.org, but fails with TDM...well, that's a TDM bug, since John E. attempts to allow working exceptions-across-dll-boundaries for BOTH -static-libstdc++ and -shared-libstdc++. (Note that mingw.org's g++ WILL fail to propagate exceptions across the DLL boundary unless -shared-libgcc, which is the default for -shared-libstdc++, which itself is the default. Not sure about -static-libstdc++ with -shared-libgcc, but -static-libstdc++ -static-libgcc is right out. However, since it *works* with mingw.org, I don't think a screwup related to these flags is the culprit.) As a side note, I find that the GNU make delivered with current MinGW is at least 60X slower than before. It takes GNU make 2.5 minutes before it does any actual work (while building GraphicsMagick), which represents most of the compilation time with the previous make. A one-year old Cygwin make takes maybe 1.5 seconds to start working when given the same environment. And for this, I'd appreciate it if you could open a bug at mingw.org's tracker: http://sourceforge.net/tracker/?group_id=2435atid=102435 -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On 09/18/2010 10:03 PM, Gary V. Vaughan wrote: I'm planning to make the belated 2.4 release in about 24 hours. If there is any reason you'd like me to hold off for a bit longer, please speak up now! Can we ship libltdl/m4/autobuild.m4 as a static copy of a decently recent autobuild.m4, rather than requiring autobuild to be pre-installed where aclocal can find autobuild.m4? After all, this is how coreutils, m4, and the soon-to-be-released autoconf 2.68 do things. http://git.sv.gnu.org/cgit/autoconf.git/commit/?id=842807af6 And in doing so, it may ease Chuck's burden in porting libtool 2.4 to cygwin: http://cygwin.com/ml/cygwin-apps/2010-09/msg00121.html -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
Hi Eric, * Eric Blake wrote on Mon, Sep 20, 2010 at 06:35:21PM CEST: On 09/18/2010 10:03 PM, Gary V. Vaughan wrote: I'm planning to make the belated 2.4 release in about 24 hours. If there is any reason you'd like me to hold off for a bit longer, please speak up now! Can we ship libltdl/m4/autobuild.m4 as a static copy of a decently recent autobuild.m4, rather than requiring autobuild to be pre-installed where aclocal can find autobuild.m4? After all, this is how coreutils, m4, and the soon-to-be-released autoconf 2.68 do things. http://git.sv.gnu.org/cgit/autoconf.git/commit/?id=842807af6 And in doing so, it may ease Chuck's burden in porting libtool 2.4 to cygwin: http://cygwin.com/ml/cygwin-apps/2010-09/msg00121.html OK with me if it helps that. Be sure to *not* list autobuild.m4 anywhere else, e.g., in Makefile.am. It is picked up automatically. You can make the AB_INIT call in configure.ac unconditional, but then again, no loss in leaving it as it is. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
* Charles Wilson wrote on Mon, Sep 20, 2010 at 01:39:38AM CEST: On 9/19/2010 12:57 PM, Charles Wilson wrote: On 9/19/2010 11:45 AM, Bob Friesenhahn wrote: Unfortunately, my MinGW testing is not so successful. The testing still quits part-way through with some sort of make-related issue (as reported in detail previously). Odd. My last test on MinGW was very successful. This was version 1.3266 (ef56e98f3 IIRC). I'll give it another go @ f0584085. MinGW/MSYS: old -- All 122 tests passed (2 tests were not run) new -- 108 tests behaved as expected. 12 tests were skipped. I'd really appreciate if you guys could send build logs to the autobuild server as I've been doing lately, much more than just posting non-verbose results on the list here. You don't need to have autobuild installed. When Eric installs autobuild.m4 you don't need to do anything else. Here's what I use, more or less, to create the logs: ( ../libtool/configure [OPTIONS] \ make \ make -k check cat test-suite.log tests/testsuite.log if tail tests/testsuite.log | grep '^| ' /dev/null; then :; else sed 's/^/| /' config.log fi ) logfile $sanitize logfile mail libtool_autobuild.josefsson.org logfile with the underscore replaced by @. For now, OPTIONS includes autobuild_mode=bla if there is anything special about the build. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On Mon, 20 Sep 2010, Ralf Wildenhues wrote: I'd really appreciate if you guys could send build logs to the autobuild server as I've been doing lately, much more than just posting non-verbose results on the list here. You don't need to have autobuild installed. When Eric installs autobuild.m4 you don't need to do anything else. No autobuild.m4 here. Only heard mention of it in the past couple of days. I don't know what it is. $sanitize logfile mail libtool_autobuild.josefsson.org logfile Most systems I test on have no email access. Certainly I would not trust a Windows PC dedicated to testing with the ability to send email. Shouldn't there be a username component to that email address? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
* Bob Friesenhahn wrote on Mon, Sep 20, 2010 at 07:53:15PM CEST: On Mon, 20 Sep 2010, Ralf Wildenhues wrote: I'd really appreciate if you guys could send build logs to the autobuild server as I've been doing lately, much more than just posting non-verbose results on the list here. You don't need to have autobuild installed. When Eric installs autobuild.m4 you don't need to do anything else. No autobuild.m4 here. Only heard mention of it in the past couple of days. I don't know what it is. And when that patch is in, you *don't* need to know. Just wait for the commit, git fetch git rebase, profit. $sanitize logfile mail libtool_autobuild.josefsson.org logfile Most systems I test on have no email access. Certainly I would not trust a Windows PC dedicated to testing with the ability to send email. So? Send it from any other system. Certainly you will have some way to transfer data from or to that PC. Shouldn't there be a username component to that email address? Well, in the part of my email that you clipped, I explained the mangling that I used. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
Hi Gary, * Gary V. Vaughan wrote on Mon, Sep 20, 2010 at 02:17:34AM CEST: On Sep 20, 2010, at 3:18 AM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * Gary V. Vaughan wrote on Sun, Sep 19, 2010 at 01:20:17PM CEST: On 19 Sep 2010, at 18:14, Ralf Wildenhues wrote: http://lists.gnu.org/archive/html/bug-libtool/2010-09/msg00032.html I would like to look into it, and try to come up with a fix before the release. Sure. Please ping me when you're ready, since I sometimes lag by a week or more on mailing list posts depending on other demands on my time. I'm ready, in the sense that I think http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/5886/focus=7559 fixes this issue, passes tests for me, needs feedback and approval, and that otherwise, the only pending regression is: http://thread.gmane.org/gmane.comp.gnu.libtool.patches/10713/focus=10740 Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
Hi Gary, * Gary V. Vaughan wrote on Sun, Sep 19, 2010 at 06:03:19AM CEST: I'm planning to make the belated 2.4 release in about 24 hours. Great! If there is any reason you'd like me to hold off for a bit longer, please speak up now! I don't know of any confirmed regression that we have analyzed and a patch for. IOW, anything else can be addressed after the release. Please send a message to the list though right when you require no more changes to the tree though; there still the odd testsuite issue or two in new tests, and while with git, it is not a problem if we push something while you create the release (in that case you can still merge origin/master afterwards, instead of rebase origin/master), it would be nicer to not have this. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
Hallo Ralf, On 19 Sep 2010, at 14:40, Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Sun, Sep 19, 2010 at 06:03:19AM CEST: I'm planning to make the belated 2.4 release in about 24 hours. Great! If there is any reason you'd like me to hold off for a bit longer, please speak up now! I don't know of any confirmed regression that we have analyzed and a patch for. IOW, anything else can be addressed after the release. Excellent. Only 19 hours left to get me to hold off then... ;o) Please send a message to the list though right when you require no more changes to the tree though; there still the odd testsuite issue or two in new tests, and while with git, it is not a problem if we push something while you create the release (in that case you can still merge origin/master afterwards, instead of rebase origin/master), it would be nicer to not have this. Git will send a message to the list when I push the prerelease patch to set the version numbers in configure.ac, libltdl/configure.ac and NEWS. At that point, please don't push anything until I commit postrelease patch that resets the version numbers to 2.4.1a, which will probably come less than an hour later (depending on how long the final `make distcheck' needs on my build machine). Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
* Gary V. Vaughan wrote on Sun, Sep 19, 2010 at 06:03:19AM CEST: I'm planning to make the belated 2.4 release in about 24 hours. If there is any reason you'd like me to hold off for a bit longer, please speak up now! Rainer just confirmed a regression in this thread: http://lists.gnu.org/archive/html/bug-libtool/2010-09/msg00032.html (his latest message hasn't shown up in the archives yet). I would like to look into it, and try to come up with a fix before the release. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
Hallo Ralf, On 19 Sep 2010, at 18:14, Ralf Wildenhues wrote: * Gary V. Vaughan wrote on Sun, Sep 19, 2010 at 06:03:19AM CEST: I'm planning to make the belated 2.4 release in about 24 hours. If there is any reason you'd like me to hold off for a bit longer, please speak up now! Rainer just confirmed a regression in this thread: http://lists.gnu.org/archive/html/bug-libtool/2010-09/msg00032.html (his latest message hasn't shown up in the archives yet). Okay, nice catch. I would like to look into it, and try to come up with a fix before the release. Sure. Please ping me when you're ready, since I sometimes lag by a week or more on mailing list posts depending on other demands on my time. Cheers, -- Gary V. Vaughan (g...@gnu.org) PGP.sig Description: This is a digitally signed message part ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On Sun, 19 Sep 2010, Gary V. Vaughan wrote: Hi Bob, On 19 Sep 2010, at 21:41, Bob Friesenhahn wrote: On Sun, 19 Sep 2010, Gary V. Vaughan wrote: I'm planning to make the belated 2.4 release in about 24 hours. Yesterday I ran the libtool test suite on various machines here. The test suite performed quite well (better than a week or two ago) on Solaris 10 x86 SPARC, FreeBSD 8.0, and OS-X Leopard PPC. That's great news! Thanks for testing :) Unfortunately, my MinGW testing is not so successful. The testing still quits part-way through with some sort of make-related issue (as reported in detail previously). Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On 9/19/2010 11:45 AM, Bob Friesenhahn wrote: Unfortunately, my MinGW testing is not so successful. The testing still quits part-way through with some sort of make-related issue (as reported in detail previously). Odd. My last test on MinGW was very successful. This was version 1.3266 (ef56e98f3 IIRC). I'll give it another go @ f0584085. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
Den 2010-09-19 16:41 skrev Bob Friesenhahn: On Sun, 19 Sep 2010, Gary V. Vaughan wrote: I'm planning to make the belated 2.4 release in about 24 hours. Yesterday I ran the libtool test suite on various machines here. The test suite performed quite well (better than a week or two ago) on Solaris 10 x86 SPARC, FreeBSD 8.0, and OS-X Leopard PPC. And I ran the new testsuite on MSYS/MSVC and Cygwin/gcc this morning and noticed nothing unexpected. Cheers, Peter ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
Hi Bob, * Bob Friesenhahn wrote on Sun, Sep 19, 2010 at 05:45:45PM CEST: Unfortunately, my MinGW testing is not so successful. The testing still quits part-way through with some sort of make-related issue (as reported in detail previously). I don't have that previous report on my radar. Can you point us to it, please? Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On Sun, 19 Sep 2010, Ralf Wildenhues wrote: * Bob Friesenhahn wrote on Sun, Sep 19, 2010 at 05:45:45PM CEST: Unfortunately, my MinGW testing is not so successful. The testing still quits part-way through with some sort of make-related issue (as reported in detail previously). I don't have that previous report on my radar. Can you point us to it, please? This is the situation where the tests quit mid-way like this: PASS: tests/depdemo-shared-unst.test make[4]: *** No rule to make target `.log', needed by `test-suite.log'. Stop. make[4]: Leaving directory `/home/bfriesen/mingw/libtool-head' make[3]: *** [check-TESTS] Error 2 make[3]: Leaving directory `/home/bfriesen/mingw/libtool-head' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/home/bfriesen/mingw/libtool-head' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/bfriesen/mingw/libtool-head' make: *** [check] Error 2 I am not finding this posted to a libtool list so it was probabably in off-list discussion among libtool core developers. The above is produced today after re-installing MinGW/GCC using the latest TDM GCC installer (with GCC 4.5.1). It is similar to what I observed before. The test suite used to work so I assume that the issue is due to some change in the past few months, such as in Automake. There are no autotools installed in this MinGW installation. Libtool is bootstrapped on a Solaris system. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
* Bob Friesenhahn wrote on Sun, Sep 19, 2010 at 08:45:08PM CEST: On Sun, 19 Sep 2010, Ralf Wildenhues wrote: * Bob Friesenhahn wrote on Sun, Sep 19, 2010 at 05:45:45PM CEST: Unfortunately, my MinGW testing is not so successful. The testing still quits part-way through with some sort of make-related issue (as reported in detail previously). I don't have that previous report on my radar. Can you point us to it, please? This is the situation where the tests quit mid-way like this: PASS: tests/depdemo-shared-unst.test make[4]: *** No rule to make target `.log', needed by `test-suite.log'. Stop. make[4]: Leaving directory `/home/bfriesen/mingw/libtool-head' make[3]: *** [check-TESTS] Error 2 make[3]: Leaving directory `/home/bfriesen/mingw/libtool-head' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/home/bfriesen/mingw/libtool-head' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/bfriesen/mingw/libtool-head' make: *** [check] Error 2 I am not finding this posted to a libtool list so it was probabably in off-list discussion among libtool core developers. The above is produced today after re-installing MinGW/GCC using the latest TDM GCC installer (with GCC 4.5.1). It is similar to what I observed before. The test suite used to work so I assume that the issue is due to some change in the past few months, such as in Automake. Yeah, this is a GNU make 3.80 bug exposed by Automake 1.11, fixed by Automake 1.11.1, and re-exposed in git Automake (I am working on a fix that tries to avoid this and another bug about long $(TESTS) on MinGW). We /could/ work around it in Libtool by making sure the last entry in $(TESTS) is non-optional. OTOH, since the release will be done with Automake 1.11.1, I don't see why we would need to do that. Thanks for the feedback, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
* Bob Friesenhahn wrote on Sun, Sep 19, 2010 at 09:27:08PM CEST: On Sun, 19 Sep 2010, Ralf Wildenhues wrote: The above is produced today after re-installing MinGW/GCC using the latest TDM GCC installer (with GCC 4.5.1). It is similar to what I observed before. The test suite used to work so I assume that the issue is due to some change in the past few months, such as in Automake. Yeah, this is a GNU make 3.80 bug exposed by Automake 1.11, fixed by Automake 1.11.1, and re-exposed in git Automake (I am working on a fix that tries to avoid this and another bug about long $(TESTS) on MinGW). The 'make' used is GNU make 3.79.1. Yeah, that has the same bug. There is a 'mingw32-make' which is GNU make 3.82, but does not seem to work under MSYS. That one's not for you, normally. IIUC it's for the development of, not with, MSYS. I tried building my own GNU make 3.82 under MinGW and the result behaves the same as 'mingw32-make'. When you build stuff yourself, it matters where you install it. Some directories are treated specially by the MSYS runtime. Please see the MinGW wiki for details. Anyway, I still don't see why we should care, as long as the Libtool release is done with Automake 1.11.1 (which our configure.ac ensures). Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On Sun, 19 Sep 2010, Ralf Wildenhues wrote: The 'make' used is GNU make 3.79.1. Yeah, that has the same bug. There is a 'mingw32-make' which is GNU make 3.82, but does not seem to work under MSYS. That one's not for you, normally. IIUC it's for the development of, not with, MSYS. It is not an 'msys' application since it is delivered with the MinGW compiler rather than with 'msys'. As such, it must be a native application similar to my own attempt to build a working 'make'. I am curious to know what is causing the libtool test suite to work for other people using MinGW (a continually evolving/varying environment) and not for me. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On 9/19/2010 3:27 PM, Bob Friesenhahn wrote: The 'make' used is GNU make 3.79.1. Yikes. Where did THAT come from? MSYS has provided at least make-3.81 for several years; the current msys make is 3.82. There is a 'mingw32-make' which is GNU make 3.82, but does not seem to work under MSYS. Right. mingw32-make is for when you do NOT have msys installed, and just want to use a makefile with MinGW gcc. Obviously, without msys, you can't run configure scripts, or generate Makefile's from Makefile.in's, etc -- or use libtool. Just as obviously, when building libtool itself, you darned well better have msys installed, so mingw32-make is not appropriate. Besides, mingw32-make doesn't grok msys-style pathnames. I sounds like your msys installation is WAY out of date. What I would suggest is the following: 1) download and install mingw-get (get the .zip file, and unpack it somewhere innocuous like C:\Temp\MinGW-Installer -- NOT C:\MinGW, because we don't want to disturb your existing TDM mingw compiler. You do not want to use easier mingw-get-inst wrapper, because it will automatically also install mingw.org's gcc, and you're using TDM. You *could* use mingw-get-inst, but (a) you'd have to pick a different installation directory, and (b) by default, your new msys would be in C:\mingw-inst-dir\msys\1.0, NOT C:\msys\1.0. 2) edit C:\Temp\MinGW-Installer\var\lib\mingw-get\data\profile.xml (if it doesn't exist, copy default.xml). You should change the following two lines: sysroot subsystem=mingw32 path=%R / sysroot subsystem=MSYS path=%R/msys/1.0 / To this: sysroot subsystem=mingw32 path=%R / sysroot subsystem=MSYS path=C:/msys/1.0 / The default configuration will install a new MinGW into whereever mingw-get is, and a new MSYS into whereever mingw-get-is/msys/1.0. You don't want that...so you have to edit the defaults. You might want to move your existing msys installation out of the way. Then, from a cmd prompt, cd to C:\Temp\MinGW-Installer\bin and do this: mingw-get update mingw-get install mingw-dtk The first command updates all of the locally cached package manifests to the latest version. The second command downloads and installs a selection to tools that will closely mimic the old MSYS-DTK package -- into C:\msys\1.0\*. However, as mingw-dtk (and the old MSYS-DTK) collection includes mingw-ish autoconf/automake/libtool, THOSE tools will get installed into wherever-mingw-get-is/*. It's up to you whether you should brute force copy these files over onto your existing TDM C:\MinGW or not (but do NOT put them into C:\msys\1.0!!!) Alternatively, of course, you could edit the mingw32 subsystem path specification in profile.xml, and install THOSE components directly into C:\MinGW. After that, you need to edit C:\msys\1.0\etc\fstab to add C:\MinGW /mingw as usual...but that's old hat. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
* Gary V. Vaughan wrote on Sun, Sep 19, 2010 at 01:20:17PM CEST: On 19 Sep 2010, at 18:14, Ralf Wildenhues wrote: Rainer just confirmed a regression in this thread: http://lists.gnu.org/archive/html/bug-libtool/2010-09/msg00032.html (his latest message hasn't shown up in the archives yet). Okay, nice catch. I would like to look into it, and try to come up with a fix before the release. Sure. Please ping me when you're ready, since I sometimes lag by a week or more on mailing list posts depending on other demands on my time. Can I ask for 24 hour delay? I won't be able to finish this tonight. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On 9/19/2010 12:57 PM, Charles Wilson wrote: On 9/19/2010 11:45 AM, Bob Friesenhahn wrote: Unfortunately, my MinGW testing is not so successful. The testing still quits part-way through with some sort of make-related issue (as reported in detail previously). Odd. My last test on MinGW was very successful. This was version 1.3266 (ef56e98f3 IIRC). I'll give it another go @ f0584085. MinGW/MSYS: old -- All 122 tests passed (2 tests were not run) new -- 108 tests behaved as expected. 12 tests were skipped. MinGW.org gcc 4.5.0 MinGW.org binutils 2.20.51.20100613 MSYS 1.0.15(0.47/3/2) 2010-07-06 22:04 i686 Msys make-3.81-3 (not 3.82! I should probably update...) msys-bash-3.1.17-3 msys-coreutils-5.97-3 msys-m4-1.4.14-1 mingw-runtime-3.18 (/mingw/include/_mingw.h) w32api-3.14(/mingw/include/w32api.h) -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On Sep 20, 2010, at 3:18 AM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * Gary V. Vaughan wrote on Sun, Sep 19, 2010 at 01:20:17PM CEST: On 19 Sep 2010, at 18:14, Ralf Wildenhues wrote: Rainer just confirmed a regression in this thread: http://lists.gnu.org/archive/html/bug-libtool/2010-09/msg00032.html (his latest message hasn't shown up in the archives yet). Okay, nice catch. I would like to look into it, and try to come up with a fix before the release. Sure. Please ping me when you're ready, since I sometimes lag by a week or more on mailing list posts depending on other demands on my time. Can I ask for 24 hour delay? I won't be able to finish this tonight. Of course. I'll wait until you ping me to confirm that you're ready. Cheers, -- Gary V. Vaughan (g...@gnu.org) ___ http://lists.gnu.org/mailman/listinfo/libtool
