Re: make -j1 fails
On Fri, Jan 14, 2011 at 6:27 PM, Ralf Wildenhues ralf.wildenh...@gmx.de wrote: * Pippijn van Steenhoven wrote on Fri, Jan 14, 2011 at 09:38:36AM CET: On Thu, Jan 13, 2011 at 07:22:20PM +0100, Ralf Wildenhues wrote: If the failure persists, please post short configure.ac and Makefile.am which expose the problem for you. You can start with what I show below, and adjust that if it doesn't expose it. The code didn't trigger the bug and I couldn't easily reproduce it by modifying it. It involves considerable effort to modify my existing project and upload it to the FreeBSD build machine and I don't have time to do that, now. Understood. This sounds like a FreeBSD make bug, but I'm not sure. Can you make your project available for us to try and reproduce the bug (I have access to a couple of FreeBSD systems)? If not, then I'm afraid I'll not be able to pursue this further before seeing a reduced version. While you're waiting for that, perhaps you could pursue the problem I did take the time to provide a reduced test case for in November: http://lists.gnu.org/archive/html/automake/2010-11/msg00135.html Note that this issue is no longer a problem for NTP -- autogen's libopts now provides LIBOPTS_CHECK_NOBUILD, which sidesteps the need to conditionalize AC_CONFIG_FILES([libopts/Makefile]), and works correctly on Automake 1.10, which doesn't support AM_COND_IF conditionalization of AC_CONFIG_FILES. I am annoyed no one has taken the time to follow up after I took the time to produce a reduced test case illustrating the automake misbehavior, and each time I see a request for a reduced repro, I wonder what I might have done wrong in anticipating the request and providing the reduced test case in the initial report. Cheers, Dave Hart
bug reports, and lack of feedback (was: make -j1 fails)
* Dave Hart wrote on Tue, Jan 18, 2011 at 09:49:02AM CET: On Fri, Jan 14, 2011 at 6:27 PM, Ralf Wildenhues wrote: Can you make your project available for us to try and reproduce the bug (I have access to a couple of FreeBSD systems)? If not, then I'm afraid I'll not be able to pursue this further before seeing a reduced version. While you're waiting for that, FWIW, I was offered non-public access to the code. Maybe it is helpful to repeat in public my stance toward this: I treat non-public code, or public code that is not well-known, rather cautiously, even more so if I don't know the author(s) well either. This is not to place mistrust in any particular person, just application of the internet principle be careful in what downloaded stuff you execute, even in a jail. This means it takes (quite) some initial time to get past a cursory review of the code for nastiness. perhaps you could pursue the problem I did take the time to provide a reduced test case for in November: http://lists.gnu.org/archive/html/automake/2010-11/msg00135.html Note that this issue is no longer a problem for NTP -- autogen's libopts now provides LIBOPTS_CHECK_NOBUILD, which sidesteps the need to conditionalize AC_CONFIG_FILES([libopts/Makefile]), and works correctly on Automake 1.10, which doesn't support AM_COND_IF conditionalization of AC_CONFIG_FILES. Good to know. I am annoyed no one has taken the time to follow up after I took the time to produce a reduced test case illustrating the automake misbehavior, and each time I see a request for a reduced repro, I wonder what I might have done wrong in anticipating the request and providing the reduced test case in the initial report. I looked at it for maybe half an hour back then, and didn't see an easy way to fix it. Sorry. I should maybe have followed up to let you know. You didn't do anything wrong, otherwise I would eventually have asked. But anyway we should've thanked you for the report, so please allow me to thank you now for the nice and well-written bug report! Generally, there are more bug reports than there are people looking at them, analyzing and fixing them. As is the case in so many free software projects. If you are dissatisfied with that, and you have resources, you are very welcome to help out. Other than that, I guess I should encourage using our new-ish debbugs bug tracker (just write to bug-automake to open a new PR) to be a little more sure issues don't get lost. I typically try to make sure rather quickly that a report is complete, so that when someone eventually gets to it, they have a chance to do something productive with it even if the original reporter has gone off to some other pasture in the meantime. Since you now have a workaround for your bug, I hope you understand that the priority of it is rather low. Sorry again, but that's how bug economics work, necessarily. Cheers, Ralf
Re: bug reports, and lack of feedback (was: make -j1 fails)
On Tue, Jan 18, 2011 at 19:30 UTC, Ralf Wildenhues wrote: * Dave Hart wrote on Tue, Jan 18, 2011 at 09:49:02AM CET: While you're waiting for that, perhaps you could pursue the problem I did take the time to provide a reduced test case for in November: http://lists.gnu.org/archive/html/automake/2010-11/msg00135.html Note that this issue is no longer a problem for NTP -- autogen's libopts now provides LIBOPTS_CHECK_NOBUILD, which sidesteps the need to conditionalize AC_CONFIG_FILES([libopts/Makefile]), and works correctly on Automake 1.10, which doesn't support AM_COND_IF conditionalization of AC_CONFIG_FILES. Good to know. I am annoyed no one has taken the time to follow up after I took the time to produce a reduced test case illustrating the automake misbehavior, and each time I see a request for a reduced repro, I wonder what I might have done wrong in anticipating the request and providing the reduced test case in the initial report. I looked at it for maybe half an hour back then, and didn't see an easy way to fix it. Sorry. I should maybe have followed up to let you know. You didn't do anything wrong, otherwise I would eventually have asked. But anyway we should've thanked you for the report, so please allow me to thank you now for the nice and well-written bug report! Thank you for the update. Knowing that you were able to understand my less-than-succinct report, and to recognize the problem, satisfies most of my concerns. Generally, there are more bug reports than there are people looking at them, analyzing and fixing them. As is the case in so many free software projects. If you are dissatisfied with that, and you have resources, you are very welcome to help out. I understand. Other than that, I guess I should encourage using our new-ish debbugs bug tracker (just write to bug-automake to open a new PR) to be a little more sure issues don't get lost. I typically try to make sure rather quickly that a report is complete, so that when someone eventually gets to it, they have a chance to do something productive with it even if the original reporter has gone off to some other pasture in the meantime. Since you now have a workaround for your bug, I hope you understand that the priority of it is rather low. Sorry again, but that's how bug economics work, necessarily. I do understand the priority is low for practical reasons. From an engineering standpoint, I remain unsatisfied that Automake claims to allow conditionalizing AC_CONFIG_FILES in AM_COND_IF but flubs this instance. I will open a PR, thanks for pointing out what should have been obvious to me as I knew of the debbugs tracker for automake. Thanks for your time, Dave Hart
Re: make -j1 fails
On Thu, Jan 13, 2011 at 07:22:20PM +0100, Ralf Wildenhues wrote: Thanks for the bug report. Which version of Automake are you using? If older than v1.10b-62-g0e411a0, then please update to 1.11.1 and retry. It may be possible that we overlooked one case in the above-mentioned commit, but I don't see where that should be. I am using automake (GNU automake) 1.11.1 from Debian squeeze. If the failure persists, please post short configure.ac and Makefile.am which expose the problem for you. You can start with what I show below, and adjust that if it doesn't expose it. The code didn't trigger the bug and I couldn't easily reproduce it by modifying it. It involves considerable effort to modify my existing project and upload it to the FreeBSD build machine and I don't have time to do that, now. GNU make does not misbehave this way, so for now I'll use that. Does the failure happen reliably, i.e., every time, or only sometimes? It happens reliably with any N in make -jN. Does 'make -B -jN' work for you reliably? Yes, that works as expected and executes the right command (the one also executed without -jN). Which exact FreeBSD version are you using? I'm kind of suspecting a bug in the make implementation, or we're overlooking something with one-shell issues. I am using FreeBSD 8.0-RELEASE-p4. -- Pippijn van Steenhoven signature.asc Description: Digital signature
Re: make -j1 fails
* Pippijn van Steenhoven wrote on Fri, Jan 14, 2011 at 09:38:36AM CET: On Thu, Jan 13, 2011 at 07:22:20PM +0100, Ralf Wildenhues wrote: If the failure persists, please post short configure.ac and Makefile.am which expose the problem for you. You can start with what I show below, and adjust that if it doesn't expose it. The code didn't trigger the bug and I couldn't easily reproduce it by modifying it. It involves considerable effort to modify my existing project and upload it to the FreeBSD build machine and I don't have time to do that, now. Understood. This sounds like a FreeBSD make bug, but I'm not sure. Can you make your project available for us to try and reproduce the bug (I have access to a couple of FreeBSD systems)? If not, then I'm afraid I'll not be able to pursue this further before seeing a reduced version. Thanks, Ralf
make -j1 fails
Hi, I am using the FreeBSD make utility to build an automake based distribution. When I run make with a -j option (even -j1), it fails. Running make with a -j option makes the utility behave differently. The issue only arises with built sources (in my case, yacc generated C code), since those trigger the inference rule .c.lo. Perhaps a solution would be to also generate explicit rules for built sources. I have attached the output of running make with and without -j1. Regards, Pippijn van Steenhoven make V=1 axl.lo /bin/sh ../autoconf/ylwrap `test -f 'src/compiler/phases/parse/axl.y' || echo '../'`src/compiler/phases/parse/axl.y y.tab.c axl.c y.tab.h axl.h y.output axl.output -- byacc -d axl.h is unchanged /bin/sh ./libtool --tag=CC--mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I./include/config -I../include -I./include -I../include -I./include -D_DEBUG -DPREFIX='/usr/local' -I../`echo axl.c | grep -o 'src/library/\w\+'`/include -g -O2 -pipe -ggdb3 -pedantic -ansi -fvisibility=hidden -MT axl.lo -MD -MP -MF .deps/axl.Tpo -c -o axl.lo axl.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I./include/config -I../include -I./include -I../include -I./include -D_DEBUG -DPREFIX=\/usr/local\ -I..//include -g -O2 -pipe -ggdb3 -pedantic -ansi -fvisibility=hidden -MT axl.lo -MD -MP -MF .deps/axl.Tpo -c axl.c -fPIC -DPIC -o .libs/axl.o mv -f .deps/axl.Tpo .deps/axl.Plo make V=1 axl.lo -j1 /bin/sh ../autoconf/ylwrap `test -f 'src/compiler/phases/parse/axl.y' || echo '../'`src/compiler/phases/parse/axl.y y.tab.c axl.c y.tab.h axl.h y.output axl.output -- byacc -d axl.h is unchanged /bin/sh ./libtool --tag=CC--mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I./include/config -I../include -I./include -I../include -I./include -D_DEBUG -DPREFIX='/usr/local' -I../`echo axl.c | grep -o 'src/library/\w\+'`/include -g -O2 -pipe -ggdb3 -pedantic -ansi -fvisibility=hidden -MT axl.lo -MD -MP -MF .deps/src/compiler/phases/parse/axl.Tpo -c -o axl.lo axl.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I./include/config -I../include -I./include -I../include -I./include -D_DEBUG -DPREFIX=\/usr/local\ -I..//include -g -O2 -pipe -ggdb3 -pedantic -ansi -fvisibility=hidden -MT axl.lo -MD -MP -MF .deps/src/compiler/phases/parse/axl.Tpo -c axl.c -fPIC -DPIC -o .libs/axl.o axl.c:3626: fatal error: opening dependency file .deps/src/compiler/phases/parse/axl.Tpo: No such file or directory compilation terminated. *** Error code 1 1 error signature.asc Description: Digital signature
Re: make -j1 fails
Hello Pippijn, * Pippijn van Steenhoven wrote on Thu, Jan 13, 2011 at 09:24:42AM CET: I am using the FreeBSD make utility to build an automake based distribution. When I run make with a -j option (even -j1), it fails. Running make with a -j option makes the utility behave differently. The issue only arises with built sources (in my case, yacc generated C code), since those trigger the inference rule .c.lo. Perhaps a solution would be to also generate explicit rules for built sources. I have attached the output of running make with and without -j1. Thanks for the bug report. Which version of Automake are you using? If older than v1.10b-62-g0e411a0, then please update to 1.11.1 and retry. It may be possible that we overlooked one case in the above-mentioned commit, but I don't see where that should be. If the failure persists, please post short configure.ac and Makefile.am which expose the problem for you. You can start with what I show below, and adjust that if it doesn't expose it. Does the failure happen reliably, i.e., every time, or only sometimes? You can try in a loop with something like for i in 1 2 3 4 5 6 7 8 9 10; do rm -f axl.[clo]* make V=1 -j1 done Does 'make -B -jN' work for you reliably? Which exact FreeBSD version are you using? I'm kind of suspecting a bug in the make implementation, or we're overlooking something with one-shell issues. cat configure.ac \END AC_INIT([a], [1]) AC_CONFIG_AUX_DIR([autoconf]) AM_INIT_AUTOMAKE([foreign]) AC_CONFIG_FILES([Makefile]) AC_PROG_CC AC_PROG_LIBTOOL AC_PROG_YACC AC_OUTPUT END cat Makefile.am \END lib_LTLIBRARIES = libfoo.la libfoo_la_SOURCES = src/compiler/phases/parse/axl.y END Thanks, Ralf /bin/sh ./libtool --tag=CC--mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I./include/config -I../include -I./include -I../include -I./include -D_DEBUG -DPREFIX='/usr/local' -I../`echo axl.c | grep -o 'src/library/\w\+'`/include -g -O2 -pipe -ggdb3 -pedantic -ansi -fvisibility=hidden -MT axl.lo -MD -MP -MF .deps/axl.Tpo -c -o axl.lo axl.c /bin/sh ./libtool --tag=CC--mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I./include/config -I../include -I./include -I../include -I./include -D_DEBUG -DPREFIX='/usr/local' -I../`echo axl.c | grep -o 'src/library/\w\+'`/include -g -O2 -pipe -ggdb3 -pedantic -ansi -fvisibility=hidden -MT axl.lo -MD -MP -MF .deps/src/compiler/phases/parse/axl.Tpo -c -o axl.lo axl.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I./include/config -I../include -I./include -I../include -I./include -D_DEBUG -DPREFIX=\/usr/local\ -I..//include -g -O2 -pipe -ggdb3 -pedantic -ansi -fvisibility=hidden -MT axl.lo -MD -MP -MF .deps/src/compiler/phases/parse/axl.Tpo -c axl.c -fPIC -DPIC -o .libs/axl.o axl.c:3626: fatal error: opening dependency file .deps/src/compiler/phases/parse/axl.Tpo: No such file or directory
