[llvm-bugs] [Bug 46886] New: Clang does not set /DEFAULTLIB:OLDNAMES when invoking link.exe on Windows

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=46886

            Bug ID: 46886
           Summary: Clang does not set /DEFAULTLIB:OLDNAMES when invoking
                    link.exe on Windows
           Product: new-bugs
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: clay.Sweetser at gmail.com
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org

Created attachment 23787
  --> https://bugs.llvm.org/attachment.cgi?id=23787&action=edit
Test case

When using Clang together with the Windows SDK, Clang doesn't set
"/DEFAULTLIB:OLDNAMES" when invoking "link.exe". This flag is required in order
to access various standard C functions ("_fdopen", "_atoi64") through their
"deprecated" names ("fdopen", "atoi64"). For comparison, "cl.exe" sets this
flag by default when invoking "link.exe", unless told not to (for example, by
passing "/NODEFAULTLIB".

If this option is not passed, programs that access the functions through their
alternate name will fail at link-time with an undefined reference error (at
least with Clang's default configuration, the function declarations appear to
always be defined).

>From a user perspective, this is highly confusing, since a casual internet
search doesn't reveal why such functions would throw linker errors. I was
tipped off by looking at the Mingw project's source code, since it seems to do
something similar.

Attached is a program that demonstrates the error. It will fail to compile when
run in a Clang+Windows SDK environment:
  clang example.c
but succeed when run with "--for-linker=-DEFAULTLIB:OLDNAMES":
  clang --for-linker=-DEFAULTLIB:OLDNAMES example.c

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200729/380dafff/attachment.html>