`Reader` doesn't skip over Darwin-style symbol table archive members

[chrisnovakovic]

While attempting to fix please-build/cc-rules#95, certain ar-merging targets became unbuildable, but only on Darwin:

$ ./pleasew test
Build stopped after 9.44s. 2 targets failed:
    //test:_multisrc_lib#a
Error building target //test:_multisrc_lib#a: exit status 1
/Library/Developer/CommandLineTools/usr/bin/ranlib: archive member: /Users/csn/contrib/cc-rules/plz-out/tmp/test/_multisrc_lib#a._build/libmultisrc_lib.a(



) size too large (archive member extends past the end of the file)
/Library/Developer/CommandLineTools/usr/bin/ar: internal ranlib command failed

    //test/deps:_lib2#a
Error building target //test/deps:_lib2#a: exit status 1
/Library/Developer/CommandLineTools/usr/bin/ranlib: archive member: /Users/csn/contrib/cc-rules/plz-out/tmp/test/deps/_lib2#a._build/lib2.a(etSecondQuestion) size too large (archive member extends past the end of the file)
/Library/Developer/CommandLineTools/usr/bin/ar: internal ranlib command failed

Upon investigation, it seems to be because this library's Reader isn't skipping over the symbol table that XCode generates as the first member of each input archive, so arcat writes them both into the output archive, breaking the entire archive when ranlib then tries to generate a new symbol table:

$ ./pleasew build --shell //test:_multisrc_lib#a
Temp directories prepared, total time 40ms:
  //test:_multisrc_lib#a: plz-out/tmp/test/_multisrc_lib#a._build
    Command: "$TOOLS_ARCAT" ar --combine && "$TOOLS_AR" s "$OUT"


The default interactive shell is now zsh.
To update your account to use zsh, please run `chsh -s /bin/zsh`.
For more details, please visit https://support.apple.com/kb/HT208050.
bash-3.2$ "$TOOLS_ARCAT" -v debug ar --combine
17:45:14.907   DEBUG: Writing ar to /Users/csn/contrib/cc-rules/plz-out/tmp/test/_multisrc_lib#a._build/libmultisrc_lib.a
17:45:14.908   DEBUG: ar source file: test/_multisrc_lib#multisrc_1_cc.a
17:45:14.909   DEBUG: copying '__.SYMDEF SORTED' in from test/_multisrc_lib#multisrc_1_cc.a, mode 81a4
17:45:14.909   DEBUG: copying 'multisrc_1.o' in from test/_multisrc_lib#multisrc_1_cc.a, mode 1a4
17:45:14.910   DEBUG: ar source file: test/_multisrc_lib#multisrc_2_cc.a
17:45:14.910   DEBUG: copying '__.SYMDEF SORTED' in from test/_multisrc_lib#multisrc_2_cc.a, mode 81a4
17:45:14.910   DEBUG: copying 'multisrc_2.o' in from test/_multisrc_lib#multisrc_2_cc.a, mode 1a4

Drilling down further, it seems this happens because the header.Name check is performed before the file name in a BSD-variant archive has actually been parsed, so the check may actually just be performed against #1/<n> if the tool that generated the input archive treats file names containing exactly 16 characters as long file names:

ar/reader.go

Lines 189 to 196 in d346232

	// The special file name "__.SYMDEF" (and variations of it) indicates that the data section contains a symbol table.
	if header.Name == "__.SYMDEF" || header.Name == "__.SYMDEF SORTED" || header.Name == "__.SYMDEF_64" {
	// The symbol table should be invisible to the caller - skip over it.
	return rd.Next()
	}
	if err := rd.parseBSDFileName(header); err != nil {
	return nil, err
	}