mdemo ltdl failure (was: export.at failure on MinGW)
A (very small) progress report. On Tue, Feb 27, 2007 at 11:02:01PM +0100, Ralf Wildenhues wrote: * Charles Wilson wrote on Tue, Feb 27, 2007 at 05:42:50AM CET: > Ralf Wildenhues wrote: > >The only thing that's then still worrying me is that on Cygwin, the > >mdemo and mdemo_static programs sometimes throw segmentation faults > >on my system. Not all the time though. > > Well, it's failing all the time for me, but I'm not sure it's a > segfault. What does "Hangup" mean, when reported by the shell after > executing the app: Good question, I don't know. I suppose there is memory corruption earlier, and due to it anything weird can happen later, so the exit status is not really reliable. It's exposed by try_iterate which calls lt_dlforeachfile. I think it's somewhere in dirent code. I have a feeling that it's not caused by anything in Libtool, but am not sure. (Only noting this because it may ring a bell, not because I have any evidence.) This works: $ mdemo/mdemo mdemo/foo1.la $ mdemo/mdemo `pwd`/mdemo/foo1.la This fails: $ mdemo/mdemo ./mdemo/foo1.la Cheers, Ralf
Re: 319-gary-refactor-m4sh-rules
On 7 Mar 2007, at 09:54, Ralf Wildenhues wrote: Hello Gary, Hallo Ralf, I would like for 2.1b to be released when the libltdl memory fault on Cygwin is fixed and I've managed to put Charles' documentation patch into a somewhat more general form. And NEWS documents very clearly all other regressions that we should be caring about. If you want to add one, then let's discuss that. And if you have a test failure on some system and see an easy fix, then I'm all ears, too. ACK. But other than that, I'm simply going to have a blanket "No", and it's going to get more capitalized with time. Let's release with all the suboptimal and ugly and duplicated code that we have. We've had more than three years now where we were too lazy to fix it or not to introduce it in the first place. So let's live with it now. If this keeps going on for long, I'm going to invest less effort in saying no, too: patch reviews take time, too, time that also pushes a release further away. This one for one has taken way too much of my time already. ACK. Thanks again for the review. I'll apply those changes to my patch and maintain it in my quilt stack until post-2.0, then resubmit. No. Please no more factoring. The last factoring changes cost months if not years to get bug free. Please pick one of the regressions if you want to fix something. If you rather want to fix test failures, please say so, and I will post a couple of open ones. I'll start by making the longhand changes to the copyright notices I posted here: http://lists.gnu.org/archive/html/libtool-patches/2007-02/ msg00146.html And then I'll help work on regressions and testing for 2.0. We can merge all the changes from the masters of getopt.m4sh and general.m4sh somewhere down the line. Cheers, Gary -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912 PGP.sig Description: This is a digitally signed message part
Re: 319-gary-refactor-m4sh-rules
Hello Gary, * Gary V. Vaughan wrote on Wed, Mar 07, 2007 at 09:31:58AM CET: > On 6 Mar 2007, at 14:23, Ralf Wildenhues wrote: > >* Gary V. Vaughan wrote on Tue, Mar 06, 2007 at 08:33:50PM CET: > >>This makes code sharing with forthcoming func_version test cases > >>easier. > >> > >>Okay to commit? > > > >IMHO this is definitely post 2.0: it doesn't fix an important bug. > > It is not touching much code at all though, and without doing it this > way, I'll need to copy and paste the m4sh -> in -> sh rules into the > test case, which will mean manually keeping it all in synch, and that > the test itself won't actually exercise the live code. > (Not to mention that without the patch we already have to manually > synch several copies of the same code in the existing Makefile.am > implementation). Yes, certainly. It still does not fulfill the "fix only important bugs and regressions" criteria. It simply doesn't. If you insist, then it's simply easier to not apply your func_version changes at all: they don't either fix an _important_ bug. I can certainly live well with that one single long copyright line in ltmain.m4sh, which I'd not even qualify as an unimportant bug, it's at most a negligible annoyance. And if I were to fix it, then I would make func_version more stupid by just letting it output a constant string, and have a copy of that in each script. I'll anyway have to grep the source tree for several instances of '2007' next January, the func_version automatization doesn't even avoid all that much work for me. But let's not discuss the bikeshed's color. I would like for 2.1b to be released when the libltdl memory fault on Cygwin is fixed and I've managed to put Charles' documentation patch into a somewhat more general form. And NEWS documents very clearly all other regressions that we should be caring about. If you want to add one, then let's discuss that. And if you have a test failure on some system and see an easy fix, then I'm all ears, too. But other than that, I'm simply going to have a blanket "No", and it's going to get more capitalized with time. Let's release with all the suboptimal and ugly and duplicated code that we have. We've had more than three years now where we were too lazy to fix it or not to introduce it in the first place. So let's live with it now. If this keeps going on for long, I'm going to invest less effort in saying no, too: patch reviews take time, too, time that also pushes a release further away. This one for one has taken way too much of my time already. If the Libtool developers disagree with me here on my stance, then by all means speak up, please. I have postponed patches including thorough test cases that actually have been extensively exercised, but do not fit the above criteria. I'd love to see these applied, but refrain from it. I'm also open to reconsider my Libtool commitment, should there be irresolvable differences. > >Moreover it's wrong, too: the $(srcdir) are there for a reason. > >Sorry. > > It was my understanding that the $(srcdir) are required on the left > of the ':' in a rule, but not on the right. If you mention $(srcdir)/file as a prerequisite somewhere, then you also have to mention it as the target. We mentioned it with $(srcdir)/ on the right in order to avoid surprise by Solaris make's VPATH rewriting rules in the rule commands, IIRC. > From Autoconf manual 11.13.5: > > It seems the sole solution that would please every `make' > implementation is to never rely on `VPATH' searches for targets. In > other words, `VPATH' should be reserved to unbuilt sources. Yes. I think that supports my point. > If I'm correct, then I've just removed a little unnecessary fluff > from the right hand sides. If I'm wrong, then there was already > enough inconsistency that things would have already been broken by > missing $(srcdir) on the right in other rules. In either case, I'd > still like to commit the factoring parts of the patch. No. Please no more factoring. The last factoring changes cost months if not years to get bug free. Please pick one of the regressions if you want to fix something. If you rather want to fix test failures, please say so, and I will post a couple of open ones. > >If you're out to relax the requirement for GNU make, then I suggest > >you give some information as to which make implementations you have > >successfully tested with. > > Nope. Although now you mention it, I believe we're already requiring > GNU make for VPATH builds, no? Yes. At the moment we do. But we want to get away from it, users obviously don't like the additional requirement. So please don't make it harder to do so in the future, by relying even more on GNU make. > In which case, we can remove the > $(srcdir) fluff and repeated associated comments from the left side > of ':' in several rules. The first non-GNU system I tried (on irix, > which has a SYSV4 based make) with a fresh HEAD checkout (bootstrapped > wi
Re: 319-gary-refactor-m4sh-rules
On 6 Mar 2007, at 14:23, Ralf Wildenhues wrote: Hello Gary, Hallo Ralf, Thanks for the review. * Gary V. Vaughan wrote on Tue, Mar 06, 2007 at 08:33:50PM CET: This makes code sharing with forthcoming func_version test cases easier. Okay to commit? IMHO this is definitely post 2.0: it doesn't fix an important bug. It is not touching much code at all though, and without doing it this way, I'll need to copy and paste the m4sh -> in -> sh rules into the test case, which will mean manually keeping it all in synch, and that the test itself won't actually exercise the live code. (Not to mention that without the patch we already have to manually synch several copies of the same code in the existing Makefile.am implementation). Moreover it's wrong, too: the $(srcdir) are there for a reason. Sorry. It was my understanding that the $(srcdir) are required on the left of the ':' in a rule, but not on the right. From Autoconf manual 11.13.5: It seems the sole solution that would please every `make' implementation is to never rely on `VPATH' searches for targets. In other words, `VPATH' should be reserved to unbuilt sources. If I'm correct, then I've just removed a little unnecessary fluff from the right hand sides. If I'm wrong, then there was already enough inconsistency that things would have already been broken by missing $(srcdir) on the right in other rules. In either case, I'd still like to commit the factoring parts of the patch. If you're out to relax the requirement for GNU make, then I suggest you give some information as to which make implementations you have successfully tested with. Nope. Although now you mention it, I believe we're already requiring GNU make for VPATH builds, no? In which case, we can remove the $(srcdir) fluff and repeated associated comments from the left side of ':' in several rules. The first non-GNU system I tried (on irix, which has a SYSV4 based make) with a fresh HEAD checkout (bootstrapped with automake-1.10, autoconf-2.60) blows up pretty fast from a VPATH build, failing to find a source file: $ cd +mips-sgi-irix6.5 $ ../configure [[...]] $ make [[...]] /bin/sh ./libtool --tag=CC--mode=compile cc -DHAVE_CONFIG_H - I. -I.. -DLT_CONFIG_H='' -DLTDL -I. -I.. -Ilibltdl -I../ libltdl -I../libltdl/libltdl -g -c -o libltdl/loaders/dlopen.lo libltdl/loaders/dlopen.c libtool: compile: cc -DHAVE_CONFIG_H -I. -I.. "- DLT_CONFIG_H=" -DLTDL -I. -I.. -Ilibltdl -I../libltdl -I../ libltdl/libltdl -g -c libltdl/loaders/dlopen.c -DPIC -o libltdl/ loaders/.libs/dlopen.o cc ERROR: file does not exist: libltdl/loaders/dlopen.c *** Error code 1 (bu21) *** Error code 1 (bu21) *** Error code 1 (bu21) $ ls libltdl/loaders libltdl_libltdl_la-preopen.lo libltdl_libltdl_la-preopen.o $ ls ../libltdl/loaders CVSdlopen.c load_add_on.c preopen.c dld_link.c dyld.c loadlibrary.c shl_load.c Compared to an otherwise identical in-tree build: $ cd .. $ ./configure [[...]] $ make [[...]] $ echo $? 0 $ gmake MAKE=gmake gmake all-recursive gmake[1]: Entering directory `/home/gary/devel/savannah/libtool-- devo--0' gmake[2]: Entering directory `/home/gary/devel/savannah/libtool-- devo--0' gmake[2]: Leaving directory `/home/gary/devel/savannah/libtool-- devo--0' gmake[1]: Leaving directory `/home/gary/devel/savannah/libtool-- devo--0' I did test pretty thoroughly with gmake from a fresh checkout with only this patch applied and in my dev tree with just this patch applied and leaving all the file debris from previous builds still laying around, with both in-tree and VPATH builds, and I haven't introduced any regressions. from Gary V. Vaughan <[EMAIL PROTECTED]> Factorize make rules used for m4sh sources: * Makefile.am (EXTRA_DIST, libtoolize, libtool): No need to explicitly name $(srcdir) in dependencies, VPATH will look there automatically. (SUFFIXES, .m4sh.in, .m4sh.sh): New suffix rules... ($(srcdir)/tests/defs, $(srcdir)/$(auxdir)/ltmain.sh): ...factored out from here... ($(srcdir)/tests/defs.in): ...and here. * Makefile.maint (.SUFFIXES): Add explicitly for bootstrap, as bootstrap's quick-n-dirty Makefile doesn't have the correct syntax. (.in.tmp): New suffix rule... ($(srcdir)/commit, $(srcdir)/mailnotify): ...factored out from here. Cheers, Gary -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912 PGP.sig Description: This is a digitally signed message part
