Bug 61299 - LLVM 3.2 fails to link with Mesa 9.0.2 on Windows; missing link libraries
Summary: LLVM 3.2 fails to link with Mesa 9.0.2 on Windows; missing link libraries
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Other (show other bugs)
Version: 9.0
Hardware: x86 (IA32) Windows (All)
: medium normal
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-22 18:33 UTC by Keith Kriewall
Modified: 2013-02-28 15:41 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Keith Kriewall 2013-02-22 18:33:54 UTC
Linking of Mesa 9.0.2 with LLVM 3.2 fails with unresolved external symbol:

LLVMJIT.lib(JITMemoryManager.obj) : error LNK2019: unresolved external symbol "p
ublic: virtual __thiscall llvm::RTDyldMemoryManager::~RTDyldMemoryManager(void)"
 (??1RTDyldMemoryManager@llvm@@UAE@XZ) referenced in function "public: virtual _
_thiscall llvm::JITMemoryManager::~JITMemoryManager(void)" (??1JITMemoryManager@
llvm@@UAE@XZ)

The problem appears to be that the link library list in \Mesa-9.0.2\scons\llvm.py is missing two LLVM libraries (LLVMRuntimeDyld and LLVMObject).

Workaround is to modify llvm.py at line 95 to read:

        if llvm_version >= distutils.version.LooseVersion('3.0'):
            # 3.0
            env.Prepend(LIBS = [
                'LLVMBitWriter', 'LLVMX86Disassembler', 'LLVMX86AsmParser',
                'LLVMX86CodeGen', 'LLVMX86Desc', 'LLVMSelectionDAG',
                'LLVMAsmPrinter', 'LLVMMCParser', 'LLVMX86AsmPrinter',
                'LLVMX86Utils', 'LLVMX86Info', 'LLVMJIT',
                'LLVMExecutionEngine', 'LLVMCodeGen', 'LLVMScalarOpts',
                'LLVMInstCombine', 'LLVMTransformUtils', 'LLVMipa',
                'LLVMAnalysis', 'LLVMTarget', 'LLVMMC', 'LLVMCore',
                'LLVMSupport', 'LLVMRuntimeDyld', 'LLVMObject'
            ])
Comment 1 Jose Fonseca 2013-02-25 19:05:19 UTC
You saw this problem with LLVM 3.2, but the code you suggest changing also applies to LLVM 3.0 and 3.1.

Are you sure this is correct. That is, that this won't cause problems with 3.0 / 3.1?
Comment 2 Keith Kriewall 2013-02-25 19:14:56 UTC
No, I have not investigated LLVM 3.0 or 3.1 to see if the same libraries need to be specified for them.  I only mentioned what I did as a workaround with the 3.2 source.  A safer permanent solution would be to add a new version block in llvm.py for 3.2 or higher.

-Keith
Comment 3 Jose Fonseca 2013-02-28 15:41:57 UTC
Pushed. Thanks.

commit efd8311a54a945953d5372dded0d6f88349bf58b
Author: Keith Kriewall <keith.kriewall@attachmate.com>
Date:   Thu Feb 28 15:40:02 2013 +0000

    scons: Fix Windows build with LLVM 3.2
    
    Fixes fdo bug 61299
    
    NOTE: This is a candidate for the stable branches.
    
    Signed-off-by: José Fonseca <jfonseca@vmware.com>


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.