[llvm-bugs] [Bug 38965] New: Warn on .lib files with the wrong arch

[via llvm-bugs]

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

            Bug ID: 38965
           Summary: Warn on .lib files with the wrong arch
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: COFF
          Assignee: unassignedbugs at nondot.org
          Reporter: nicolasweber at gmx.de
                CC: llvm-bugs at lists.llvm.org

clang-cl defaults to 64-bit builds. If you accidentally have your env set up to
point to the 32-bit .lib paths, you get these cryptic diags:

$ ./clang-cl.sh foo.cc -fuse-ld=lld
lld-link: error: <root>: undefined symbol: mainCRTStartup
$ ./clang-cl.sh -m32 foo.cc -fuse-ld=lld   # works


link.exe is much better, it has this warning telling you what the actual issue
is:

C:\Program Files (x86)\Windows Kits\10\lib\10.0.17134.0\um\x64\advapi32.lib :
warning LNK4272: library machine type 'x64' conflicts with target machine type
'x86'

(copied from a different bug; it probably complains about a different .lib for
a trivial foo.cc with just main() -- but the warning is the same otherwise)


lld-link should warn on this too.


Hans says: """
.lib files themselves don't have a machine type.

However, the import lib pseudo-files inside them do. lld currently
doesn't check the machine type of those (it would if ImportFile
overrode getMachineType; it probably should).

But, lld will only look at the members of a .lib file lazily, i.e. if
it seems something that it needs in the .lib file's symbol table.
Because of this, I'm not sure that implementing
ImportFile::getMachineType is enough to produce a warning in Bruce's
case. Probably no symbols from advapi32.lib's symbol table are being
referenced, and so we would never parse the .lib file members :-/
"""


Zach says: """
It's pretty rare for a .lib file to have mixed arch object files.  You would
have to go out of your way to make it happen.  Given that, can we just open the
first object file, parse just enough of it to get the object file, and
early-warn if it mismatches on the assumption that all other objects in the
archive will have the same architecture?
"""


We should find some way to make this work.

-- 
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/20180916/5e30af84/attachment.html>