Deploy latest version of GNU make on all build machines

RESOLVED WONTFIX

Status

P3
normal
RESOLVED WONTFIX
7 years ago
6 months ago

People

(Reporter: joey, Unassigned)

Tracking

Details

(Whiteboard: [puppet])

(Reporter)

Description

7 years ago
Latest version is v3.82: http://ftp.gnu.org/gnu/make/
Build machines are using a mix of version >= 3.81.

One of my try jobs reported variant make function behavior on a single platform (fedora/b2g).  Trying to determine if this may be the culprit.

cmd version gathering:
https://tbpl.mozilla.org/?tree=Try&rev=25b462d2d947
===================================================
try-android-bm09-try1-build2458.txt.gz
GNU Make 3.81
try-android-debug-bm27-try1-build1210.txt.gz
GNU Make 3.81
try-android-xul-bm27-try1-build1147.txt.gz
GNU Make 3.81
try-b2g-bm14-try1-build165.txt.gz
GNU Make 3.82
try-linux64-bm27-try1-build908.txt.gz
GNU Make 3.81
try-linux-bm27-try1-build1297.txt.gz
GNU Make 3.81
try-linux-debug-bm27-try1-build1294.txt.gz
GNU Make 3.81
try-macosx64-bm09-try1-build8022.txt.gz
GNU Make 3.81
try-macosx64-debug-bm09-try1-build7551.txt.gz
GNU Make 3.81
try-macosx-debug-bm09-try1-build8594.txt.gz
GNU Make 3.81
try-win32-bm14-try1-build3845.txt.gz
GNU Make 3.81.90
try-win32-debug-bm14-try1-build3426.txt.gz
GNU Make 3.81.90
(Reporter)

Comment 1

7 years ago
make v3.82 is able to report a problem where a recursively expanded macro referenced its-self across circular/nested user function calls.

3.81 +/- will silently accept the problem.
Priority: -- → P3
Whiteboard: [puppet][opsi]
Joey: any change in the version of make we should be targeting after 15 months? Has anything in the intervening time rendered this moot?
Flags: needinfo?(joey)
Whiteboard: [puppet][opsi] → [puppet]
(Assignee)

Updated

5 years ago
Product: mozilla.org → Release Engineering
(Reporter)

Comment 3

5 years ago
It probably would still be beneficial to upgrade make from 3.81 -> 3.82.

A quick perusal of the change log between 3.81 -> 3.82 mentions fixes for: buffer overrun, *alloc() changes, implicit rule sorting, win64 addresses and several windows specific fixes around headers and string compare functions:

	* misc.c (concat): Fix buffer overrun.

	* implicit.c (stemlen_compare): Fix qsort() compare bug that
	caused implicit rules with equal stem lengths to be sorted
	indeterminately.

	* main.c (handle_runtime_exceptions): Use %p to print addresses,
	to DTRT on both 32-bit and 64-bit hosts.  Savannah bug #27809.

	(int w32_kill): Use pid_t for process ID argument.
	* w32/subproc/sub_proc.c: Include stdint.h.
	(sub_process_t): Use intptr_t for file handles and pid_t for
	process ID.
	(process_pipes, process_init_fd, process_begin): Use intptr_t for
	file handles and pid_t for process ID.  Fixes Savannah bug #27809.

	* job.c (w32_kill, start_job_command, create_batch_file): Use
	pid_t for process IDs and intptr_t for the 1st arg of
	_open_osfhandle.


	* misc.c (strncasecmp): Local implementation for systems without.
	* config.h.W32.template (HAVE_STRNICMP): Define on Windows.
	* configure.in: Check for strncasecmp/strncmpi/strnicmp.
	* job.c [WINDOWS32]: Don't define dup2 on Windows.
	(pid2str): Use "%Id" even with MSVC
	(exec_command): Cast to pid_t when calling pid2str().
	* w32/subproc/sub_proc.c [WINDOWS32]: Include config.h first.
	Use stddef.h on MSVC to get intptr_t.
	* w32/subproc/misc.c [WINDOWS32]: Include config.h first.
	* w32/compat/dirent.c [WINDOWS32]: Include config.h first.
	(readdir): Cast -1 to correct type for d_ino.
	* w32/pathstuff.c [WINDOWS32]: Ensure make.h is included first.
	* make.h [WINDOWS32]: Don't prototype alloca() on Windows.
	Add configuration for strncasecmp().
	* main.c (ADD_SIG) [WINDOWS32]: Avoid warnings in MSVC.
	* config.h.W32.template [WINDOWS32]: Don't warn on unsafe
	functions or variables.
	* NMakefile.template [WINDOWS32]: Remove /MACHINE:I386.
	* main.c (clean_jobserver): Cast due to MSVC brokenness.
	(decode_switches): Ditto.
	* vpath.c (construct_vpath_list): Ditto.
	* rule.c (freerule): Ditto.
	* ar.c (ar_glob): Ditto.
Flags: needinfo?(joey)
Do we still care about this since we use pymake?
Flags: needinfo?(joey)
Flags: needinfo?(coop)
(Reporter)

Comment 5

5 years ago
(In reply to Ben Hearsum [:bhearsum] from comment #4)
> Do we still care about this since we use pymake?

I'll have to check what the current state is.  A newer version was released (3.99-4.0?) that corrected problems with make -j on windows and provided a workaround for a few inherent pymake performance problems.  Just not sure how ready for prime time the new version is.
Flags: needinfo?(joey)
(Reporter)

Updated

5 years ago
Flags: needinfo?(joey)
We can lower the priority here, but I think it's still worth standardizing on a single version.
Flags: needinfo?(coop)

Comment 7

5 years ago
We don't care about this bug (much). We do care about bug 927672 a lot because that will make Windows builds significantly faster in automation.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX

Updated

5 years ago
Flags: needinfo?(joey)
(Reporter)

Comment 8

5 years ago
https://bugzilla.mozilla.org/show_bug.cgi?id=927213
https://bugzilla.mozilla.org/show_bug.cgi?id=927671

>> It's a goal to make this happen this quarter.

This bug should be kept open so make
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
(Reporter)

Comment 9

5 years ago
[...] kept open so make can be brought up to a consistent version c#6
Seems like we're happy with where we're at.
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago3 years ago
Resolution: --- → WONTFIX
(Assignee)

Updated

6 months ago
Component: Platform Support → Buildduty
Product: Release Engineering → Infrastructure & Operations
You need to log in before you can comment on or make changes to this bug.