[llvm-bugs] [Bug 27389] New: lld-link shouldn't rely on lib.exe for creating empty import libraries

[via llvm-bugs]

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

            Bug ID: 27389
           Summary: lld-link shouldn't rely on lib.exe for creating empty
                    import libraries
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: nicolasweber at gmx.de
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

I'm trying to build chromium's base library on a non-Windows host, using
clang-cl, lld-link, and a few local patches.

Everything works fine until the final link, which fails with:

python gyp-win-tool link-wrapper environment.x86 False
/Users/thakis/src/llvm-build/bin/lld-link /nologo /IMPLIB:./base.dll.lib /DLL
/OUT:./base.dll /PDB:./base.dll.pdb @./base.dll.rsp
unable to find lib.exe in PATH: : No such file or directory


(also note the duplicate :s)

Since lld includes a /lib mode, it seems that it's in scope that lld shouldn't
have to rely on lib.exe to create empty import libraries. lld-link /lib
currently doesn't know a /def: flag, but it should probably learn about it. But
once LibDriver knows that flag, maybe lld doesn't even have to spawn a
subprocess for creating the empty import lib but could just do a function call
to LibDriver.

(rc.exe and ctres.exe seem less in scoped for a linker :-) )

-- 
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/20160417/327d1266/attachment.html>