If you are going to roll your own GNU make with the change mentioned: http://git.savannah.gnu.org/cgit/make.git/commit/?id=757849cd93a9bc361a5113e3aaafe516773aad44
.. then you should take care to also apply: http://git.savannah.gnu.org/cgit/make.git/commit/?id=e1863c05d82096aa2bfcddb436da1b54a41369e3 as 757849 introduced a memory overrun. Cheers, Ray. On Thu, Apr 17, 2014 at 4:04 PM, Tom Kacvinsky <tom.kacvin...@vectorcast.com> wrote: > Martin, > > Thanks. Does anyone know when is the next release of make 4.0 is planned? > I'd rather not use development code for production purposes. > > Thanks, > > Tom > > > On Thu, Apr 17, 2014 at 10:49 AM, Martin Dorey <martin.do...@hds.com> wrote: >> >> The vsnprintf thing was (probably) fixed in git under >> http://savannah.gnu.org/bugs/?40361. >> >> From: Tom Kacvinsky [mailto:tom.kacvin...@vectorcast.com] >> Sent: Thursday, April 17, 2014 07:23 AM >> To: Bug-make@gnu.org <Bug-make@gnu.org> >> Subject: GNU make 4.0 crashes on Solaris 8 >> >> I have successfully built GNU make 4.0 on a Solaris 8 machine, using GCC >> 4.7.3 and Sun Studio 11, but when I run "make check", make dumps core >> >> Core was generated by >> `/Datastore/Public/tjk/make/src/make-4.0/tests/../make -f >> work/features/se_expli'. >> Program terminated with signal 11, Segmentation fault. >> #0 0xff108ac8 in vsnprintf () from /lib/libc.so.1 >> (gdb) where >> #0 0xff108ac8 in vsnprintf () from /lib/libc.so.1 >> #1 0x0003dbd8 in vfmtconcat (fmt=0x5d26c "prerequisites cannot be defined >> in recipes", args=0xffbfe8dc) at output.c:631 >> #2 0x0003e038 in fatal (flocp=0xffbfe9e8, fmt=0x5d26c "prerequisites >> cannot be defined in recipes", ...=0x2e680000) at output.c:737 >> #3 0x00042c30 in record_files (filenames=0x854d0, pattern=0x0, >> pattern_percent=0x0, depstr=0x854e0 "proj1.c", cmds_started=1, >> commands=0x86840 "", commands_idx=0, two_colon=0, >> prefix=9 '\t', flocp=0xffbfe9e8) at read.c:1951 >> #4 0x00040160 in eval (ebuf=0xffbfeab4, set_default=1) at read.c:1008 >> #5 0x0003ece4 in eval_buffer (buffer=0x866a0 "proj1.o : proj1.c", >> floc=0x0) at read.c:482 >> #6 0x00029bd8 in func_eval (o=0x7f140 "e : proj1.o $(eval $(test))", >> argv=0xffbfec08, funcname=0x5aec4 "eval") at function.c:1352 >> #7 0x0002af3c in expand_builtin_function (o=0x7f140 "e : proj1.o $(eval >> $(test))", argc=1, argv=0xffbfec08, entry_p=0x6f0b4 >> <$XA6sV5Q1G_TT35K.function_table_init+408>) >> at function.c:2294 >> #8 0x0002b41c in handle_function (op=0xffbfecf0, stringp=0xffbfecf8) at >> function.c:2415 >> #9 0x00021754 in variable_expand_string (line=0x7f138 "proj1.o e : >> proj1.o $(eval $(test))", string=0x833f8 "proj1.o $(eval $(test))", >> length=-1) at expand.c:256 >> #10 0x00021dcc in variable_expand (line=0x833f8 "proj1.o $(eval $(test))") >> at expand.c:419 >> #11 0x00022020 in variable_expand_for_file (line=0x833f8 "proj1.o $(eval >> $(test))", file=0x886a0) at expand.c:478 >> #12 0x00023c88 in expand_deps (f=0x886a0) at file.c:605 >> #13 0x00023f34 in snap_deps () at file.c:688 >> #14 0x00037a04 in main (argc=3, argv=0xffbffc0c, envp=0xffbffc1c) at >> main.c:2076 >> >> Any ideas as to what is going on? I would like to see if an issue I >> encountered in 3.82 (related to a file compiling twice when running make in >> parallel) is fixed in this version. >> >> Thanks, >> >> Tom > > > > _______________________________________________ > Bug-make mailing list > Bug-make@gnu.org > https://lists.gnu.org/mailman/listinfo/bug-make > _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make