Why are these flags OS-specific? I think the assumption here is that clang is always used on darwin, and gcc is always used on linux and windows, but that's not a safe assumption.

Is there any way you can get the right flags out of cc_common from the toolchain? If not, I think it would be better to look at the name of the compiler or linker binary to guess which flags will be accepted.

Why is "js" included here by the way? What toolchain is expected there?

Why are these flags OS-specific? I think the assumption here is that clang is always used on darwin, and gcc is always used on linux and windows, but that's not a safe assumption.
[...]
Why is "js" included here by the way? What toolchain is expected there?

I cribbed that from #1879.

Is there any way you can get the right flags out of cc_common from the toolchain? If not, I think it would be better to look at the name of the compiler or linker binary to guess which flags will be accepted.

If there is a way to do that, that would be great; I have no idea, though. There doesn't appear to be any sort of sort of sanctioned forum to ask the devs and others in the know, and I have no ties with Google or the Bazel devs, so I don't know how to inquire. Any advice here would be great.

I don't see anything directly in cc_common that would help.

I think a "good enough" solution would be to check go.env["CC"], which will be the CC environment variable passed to actions. If the string after the last slash contains clang, let's use the clang flags. Otherwise, let's use the gcc flags. I'm not 100% sure that will always be set, so let's assume gcc if it's not.

(For asking questions by the way, the bazel-discuss mailing list is usually pretty good. There's also a public Slack, though I'm not sure if it's still active).

This will crash if go.mode.goos isn't in the dict above.

That's a good point. I'd love to scrap _WHOLE_ARCHIVE_FLAGS_BY_GOOS and replace this code with something more robust, though I don't (yet) know how I would do that.

Hmm, let's replace _WHOLE_ARCHIVE_FLAGS_BY_GOOS with a function:

def _library_args(go, library_to_link):

If alwayslink is false, it can just return a list with the file path. Otherwise, it can return a list with the file path surrounded by the appropriate flags. It can test go.env["CC"] to decide which flags to use.

Why return a list from this function instead of a single value?

Why return a list from this function instead of a single value?

When I extracted that from the original source, I misread the code -- I thought I had read a set of four distinct if conditions (implying that library_to_link might have multiple files that need to be handled), not one chain of if ... elif. I'll change that.

This list is now distinct from the libraries returned by _cc_libs, but the names are really similar. What's the distinction? Won't there be an error if there are differences?

The old _cc_libs fished out the archive/dso path from each LibraryToLink in d, giving back a list of those paths. At that point, we no longer have LibraryToLink.alwayslink to inspect.

So, as the code stands now:

• _cc_libs(library_to_link): gets the archive/dso path for the given library (currently as singleton list, but as you pointed out, this ought to just return the path itself).
• _cc_libs_for_target(target): returns the list of all lib paths for a given target (as _cc_libs used to).
• _cc_libraries_to_link(target): returns the list of all LibraryToLinks for a given target.

The names are terrible, I will admit. Ultimately, my changes were intended to address the fact I need the respective LibraryToLink so I can inspect alwayslink.

With that said, I noticed something odd about the code before I got involved (my notes as comments):

            
            # cc_libs has the path of all libs for target `d`
            cc_libs = _cc_libs(d)
            # the existing implementation immediately extends inputs_direct and deps_direct with cc_libs
            inputs_direct.extend(cc_libs)
            deps_direct.extend(cc_libs)
            # [... elided ...]
            for lib in cc_libs:
                if (lib.basename.startswith("lib") and
                    libname = lib.basename[len("lib"):lib.basename.rindex(".")]
                    clinkopts.extend(["-L", lib.dirname, "-l", libname])
                    inputs_direct.append(lib) # <===== isn't this superfluous, since we extended inputs_direct with all of cc_libs above???
                elif (lib.basename.startswith("lib") and
                      has_versioned_shared_lib_extension(lib.basename)):
                    libname = ":%s" % lib.basename
                    clinkopts.extend(["-L", lib.dirname, "-l", libname])
                    inputs_direct.append(lib) # <===== ditto
                else:
                    lib_opts.append(lib.path)

Assuming I'm tracking how the code is intended to work, my next commit (which I will push shortly) will greatly clean things up.