llvm dev - Dec 2009 - [LLVMdev] getAnalysisIfAvailable<>(...)

Hello again,

In order to avoid the set jump/long jump dependency of DLLs built under Visual
C++, we're trying to build the libraries and tools under LLVM-GCC so it will
use DWARF exception handling instead of SJ/LJ.  The problem we're running
into is that the libraries that we just finished creating cannot be found later
in the build process when OPT tries to build.  My partner has MinGW and MSYS
installed on his system and we're trying to build version 2.5 of LLVM using
CMake.  Can anybody make recommendations on how to get this to work?

The basic reason we're doing this rather than taking the easy way out with
MinGW's implementation of G++ for linking is that we want to be able to
create a build script that can be called from an installer.  The LLC command,
the libraries it calls, the GAS assembler and LD linker and any other parts of
the Binutils package used should be the only requirements for the solution.  The
bitcode we are trying to compile has already been linked by llvm-link but
contains code that is written in C++.

--Sam Crow

Hello
> In order to avoid the set jump/long jump dependency of DLLs built under
Visual C++, we're trying to build the libraries and tools under LLVM-GCC so
it will use DWARF exception handling instead of SJ/LJ.  The problem we're
running into is that the libraries that we just finished creating cannot be
found later in the build process when OPT tries to build.  My partner has MinGW
and MSYS installed on his system and we're trying to build version 2.5 of
LLVM using CMake.  Can anybody make recommendations on how to get this to work?
There are two things to try:
1. Use 2.6 release (I believe mingw build with cmake definitely worked there)
2. Do not use cmake. Use normal configure + make process (this worked
since LLVM pre 1.8 iirc).

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

Some additional information about the setup may be of interest:

I'm using CMake to generate the make files for MSYS.  All appears to go well
until the tools are compiled.

The undefined references seem to be coming from the libraries that were just 
compiled:

../../lib/libLLVMBitReader.a(BitcodeReader.cpp.obj):fake:(.rdata$linkonce_ZTVN4llvm8ConstantE+0x10):
undefined reference to `llvm::Value::dump() const'

Apparently it's not being linked with libLLVMCore.a among other libs.

The command line it's using is:

cd /C/Development/llvm-2.5/tools/opt && 
/C/Development/llvm-gcc/bin/llvm-g++.exe 
"CMakeFiles/opt.dir/AnalysisWrappers.cpp.obj" 
"CMakeFiles/opt.dir/GraphPrinters.cpp.obj" 
"CMakeFiles/opt.dir/PrintSCC.cpp.obj"
"CMakeFiles/opt.dir/opt.cpp.obj"   -o
../../bin/opt.exe -Wl,--out-implib,../../lib/libopt.dll.a
-Wl,--major-image-version,0,--minor-image-version,0
../../lib/libLLVMipo.a ../../lib/libLLVMScalarOpts.a 
../../lib/libLLVMInstrumentation.a ../../lib/libLLVMBitWriter.a 
../../lib/libLLVMBitReader.a -limagehlp -lpsapi -lkernel32 -luser32 -lgdi32  
-lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32

Which clearly doesn't link against LLVMCore.

--Mike Ness

--------------------------------------------------
From: "Samuel Crow" <samuraileumas at yahoo.com>
Sent: Tuesday, December 08, 2009 12:11 PM
To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
Subject: [LLVMdev] Rebuilding LLVM libraries with LLVM-GCC on Windows
> Hello again,
>
> In order to avoid the set jump/long jump dependency of DLLs built under 
> Visual C++, we're trying to build the libraries and tools under
LLVM-GCC
> so it will use DWARF exception handling instead of SJ/LJ.  The problem 
> we're running into is that the libraries that we just finished creating
> cannot be found later in the build process when OPT tries to build.  My 
> partner has MinGW and MSYS installed on his system and we're trying to 
> build version 2.5 of LLVM using CMake.  Can anybody make recommendations 
> on how to get this to work?
>
> The basic reason we're doing this rather than taking the easy way out
with
> MinGW's implementation of G++ for linking is that we want to be able to
> create a build script that can be called from an installer.  The LLC 
> command, the libraries it calls, the GAS assembler and LD linker and any 
> other parts of the Binutils package used should be the only requirements 
> for the solution.  The bitcode we are trying to compile has already been 
> linked by llvm-link but contains code that is written in C++.
>
> --Sam Crow
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Is it consistent to have a Pass instance's run method's implementation
use getAnalysisIfAvailable<AnalysisType>() (vs just using getAnalysis<
AnalysisType >) when that same instance's getAnalysisUsage(AnalysisUsage
&au) implementation invokes au.addRequired<AnalysisType>()?

For example in the implementation of SelectionDAGISel::runOnMachineFunction(...)
(called from MachineFunctionPass::runOnFunction(...)):

DwarfWriter *DW = getAnalysisIfAvailable<DwarfWriter>();

is used vs:

DwarfWriter &DW = getAnalysis<DwarfWriter>();

even though SelectionDAGISel::getAnalysisUsage(AnalysisUsage &AU) sets:

AU.addRequired<DwarfWriter>();

Since this occurs in 2.6 and trunk, and this pattern is repeated with other
analysis passes, I'm wondering if I'm not understanding something.

Thanks in advance 

Garrison

"Michael Ness" <mike at liquido2.com> writes:
> Some additional information about the setup may be of interest:
>
> I'm using CMake to generate the make files for MSYS.  All appears to go
well
> until the tools are compiled.
>
> The undefined references seem to be coming from the libraries that were
just
> compiled:
>
>
../../lib/libLLVMBitReader.a(BitcodeReader.cpp.obj):fake:(.rdata$linkonce_ZTVN4llvm8ConstantE+0x10):
> undefined reference to `llvm::Value::dump() const'
>
> Apparently it's not being linked with libLLVMCore.a among other libs.
What's the output of this command:

bin/llvm-config --libs "bitreader asmparser bitwriter instrumentation
scalaropts ipo"

(executed from the root of your build directory)

Does it mention libLLVMCore ? From your command line it seems that CMake
was unable to determine the library dependencies. Either the
dependencies are wrong (hence the llvm-config check above) or the CMake
build is misinterpreting the output of llvm-config.

I don't know how well the LLVM cmake build worked for 2.5. In theory, it
should work the same way as for a unix host. In practice...

-- 
Óscar