This is an archive of the discontinued LLVM Phabricator instance.

[clang] [msvc] Automatically link against oldnames just as linking against libcmt
ClosedPublic

Authored by mstorsjo on Oct 19 2020, 8:10 AM.

Details

Summary

If invoking clang-cl, both libcmt (or another lib, depending on the /M[TD](|d) options) and oldnames are passed as dependent libs. If compiling and linking via the clang driver, we used to just pass libcmt when linking; include oldnames consistently there.

Diff Detail

Event Timeline

mstorsjo created this revision.Oct 19 2020, 8:10 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 19 2020, 8:10 AM
mstorsjo requested review of this revision.Oct 19 2020, 8:10 AM
rnk accepted this revision.Oct 19 2020, 1:28 PM

lgtm

We need to invent spellings for /MD /MT for the GCC-style driver if we want it to be usable in the MSVC environment. I don't think there's a precise translation to the -static-* family of options, unless I'm mistaken.

This revision is now accepted and ready to land.Oct 19 2020, 1:28 PM
amccarth accepted this revision.Oct 19 2020, 1:30 PM

It seems weird that we're implicitly adding defaultlib options without checking if the user specified nodefaultlib. But given that's already the case, I don't see a big problem with also adding oldnames.lib.

In D89702#2339716, @rnk wrote:

lgtm

We need to invent spellings for /MD /MT for the GCC-style driver if we want it to be usable in the MSVC environment. I don't think there's a precise translation to the -static-* family of options, unless I'm mistaken.

Yeah I don't think there's any good match in existing GCC-style options. I guess the most appropriate in such a case would be to use -nostdlib or something such, and explicitly mention msvcrt.lib and oldnames.lib. (If compiling with the GCC-style driver but linking by invoking (lld-)link directly, that's essentially what one has to do anyway.)

It seems weird that we're implicitly adding defaultlib options without checking if the user specified nodefaultlib. But given that's already the case, I don't see a big problem with also adding oldnames.lib.

Well we do check for the -nostdlib and -nostartupfiles options - I guess making it react to -nodefaultlibs also could be considered sensible - as an orthogonal change to this one.