question about compile path

Hi,

I have a question about install path.
Some one installs llvm1.4 under /opt/llvm as root. However, when I create a project under my home directory, I cannot do Make correctly. It should be enviroment issue, but I cannot fix it.

The environment is as the following,
/opt/llvm : // llvm 1. 4
/home/qiuyu/ ://my home directory
/home/qiuyu/project/statBB ://my project directory

I create a simple pass to test it. The content of Makefile is

LEVEL = /opt/llvm
LIBRARYNAME = StatBB
SHARED_LIBRARY = 1
include $(LEVEL)/Makefile.common

Once I do make, I got a error like
"
/bin/sh: line 1: cd: /home/qiuyu/project/statBB//opt/llvm/: No such file or directory
^^^^^^^
llvm[0]: Reconfiguring with /opt/llvm/configure
make: *** [/home/qiuyu/project/statBB/config.status] Error 127

"
So I changed the “LEVEL =/opt/llvm” to “LEVEL=…/…/…/…/opt/llvm”, the error message became to
"make: *** No rule to make target /opt/llvm/home/qiuyu/shuffleBB/Makefile', needed by Makefile’. Stop.
^^^^^^^
"

Finally, I swith to be as root and put my project under /opt/llvm/project/statBB, and LEVEL=…/… and I can make it.

Is there any way to make it work on my home directory?

Thanks

Qiuyu Zhang wrote:

Hi,

I have a question about install path.
Some one installs llvm1.4 under /opt/llvm as root. However, when I
create a project under my home directory, I cannot do Make correctly. It
should be enviroment issue, but I cannot fix it.

This should be possible.

The easiest way to do this is to copy one of the samples in
llvm/projects (such as llvm/projects/sample) and use its Makefiles and
configure script as a template for your project. Doing it this way
allows you to re-use the LLVM build system, as opposed to building your
own set of Makefiles.

So, in the top directory of your project (/home/qiuyu/project/statBB),
you should have a configure script, a Makefile.common.in, and a
Makefile. You should create subdirectories for your source code and
list those subdirectories in the DIR variable in the Makefile.

To use a project, you will need to know the location of the LLVM source
tree (the directory where you unpacked the LLVM source files when you
downloaded LLVM) and object tree (where LLVM was built; often times this
is the same as the source tree). Neither of these is the install
directory (the directory specified by the --prefix option to configure
and used when you issue "make install" to the LLVM build system).

Next, you will use your project's configure script to tell your project
where LLVM is installed. For this example, I will assume that you built
LLVM 1.4 in the directory /home/qiuyu/llvm:

% cd /home/qiuyu/project/statBB
% ./configure --with-llvmsrc=/home/qiuyu/llvm
--with-llvmobj=/home/qiuyu/llvm

This should create a Makefile.common inside of
/home/qiuyu/project/statBB. Inside of that Makefile, the variables
LLVM_SRC_ROOT and LLVM_OBJ_ROOT should point to the source tree and
object tree of LLVM 1.4, respectively. This is most likely why your
project fails to build.

After that, you should be able to type "make" inside of
/home/qiuyu/project/statBB.

I recommend that you read the document
http://llvm.cs.uiuc.edu/docs/Projects.html for a more complete
description of the LLVM project build system.

Please note that you do not need to use the LLVM project build system to
use LLVM header files, use LLVM tools, or link your programs with LLVM
libraries. We provide the projects build system as a convenience since
most people will want to do in their Makefiles what the LLVM Makefiles
already do.

Please email the llvmdev list if you still can't get it to work or if
you have any other questions.

Hope this solves the problem.

Regards,

John T. Criswell

Doing it this way
allows you to re-use the LLVM build system, as opposed to building your
own set of Makefiles.

I have pre-LLVM projects in C++ with often used at Unix C++ source file extention .cc
I modify LLVM build system (original LLVM Makefile.rules already partly support .cc extention,
for example, in Sources and FakeSources make vars setup code).

Is attached patch acceptable?

Also I have in Makefile.rules (but not include in patch) some modification for simplify used common Makefile.rules in LLVM projects and non-LLVM project (guarding some LLVM specific parts by ifdef LLVM_OBJ_ROOT/LLVM_SRC_ROOT vars).

Vladimir

Makefile.rules.patch (4.23 KB)

Doing it this way
allows you to re-use the LLVM build system, as opposed to building your
own set of Makefiles.

I have pre-LLVM projects in C++ with often used at Unix C++ source file extention .cc
I modify LLVM build system (original LLVM Makefile.rules already partly support .cc extention,
for example, in Sources and FakeSources make vars setup code).

Is attached patch acceptable?

Looks great, applied, thanks!
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050131/023931.html

Also I have in Makefile.rules (but not include in patch) some modification for simplify used common Makefile.rules in LLVM projects and non-LLVM project (guarding some LLVM specific parts by ifdef LLVM_OBJ_ROOT/LLVM_SRC_ROOT vars).

I'm not sure about this, perhaps Reid would like to comment?

-Chris

Is attached patch acceptable?

Looks great, applied, thanks!
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050131/023931.html

Thanks!

Also I have in Makefile.rules (but not include in patch) some modification for simplify used common Makefile.rules in LLVM projects and non-LLVM project (guarding some LLVM specific parts by ifdef LLVM_OBJ_ROOT/LLVM_SRC_ROOT vars).

At this moment I am test ability use installed LLVM version to build project instead requare have builded LLVM object dir.

And i have problem with installed LLVM include dir.

Makefile.rules install only $(PROJ_SRC_ROOT)/include (including *.in files) and ignore headers in $(PROJ_OBJ_ROOT)/include
As result installed LLVM does't have all headers for building external projects, for example, llvm/ADT/iterator

Proposed patch attached.

It tested making full LLVM build, install and uninstall.

Vladimir

Makefile.rules.patch (1.38 KB)

Hi,

I have been trying to randomize blocks in a program and modified “BasicBlockPlacement.cpp” for the purpose but getting segmentation fault.I am not able to determine the problem.Can anyone please decrypt these error messages or suggest what might be the possible cause of failure?

I have been trying to randomize blocks in a program and modified "BasicBlockPlacement.cpp" for the purpose but getting segmentation fault.I am not able to determine the problem.Can anyone please decrypt these error messages or suggest what might be the possible cause of failure?

I'd be happy to fix this, but I need a proper testcase and instructions to reproduce it. Can you please send me the bytecode file and commands you are using to do this?

Also, have you tried out bugpoint? Please give it a try first, as it will probably shrink the testcase down to something small. You should be able to run it like:

bugpoint -block-placement -other-options-you-need test.bc

... and it should hopefully give you a smaller .bc file. Regardless, if you send me the testcase, I'll fix the bug.

Thanks!

-Chris

-----------------------------------------------------------------------------------------------------

opt((anonymous namespace)::PrintStackTrace()+0x18)[0x8691968]
opt((anonymous namespace)::SignalHandler(int)+0xd8)[0x8691bc8]
/lib/tls/libc.so.6[0x688a48]
opt(llvm::BasicBlock::getNext()+0x6)[0x83d36d0]
opt(llvm::SymbolTableListTraits<llvm::BasicBlock, llvm::Function, llvm::Function, llvm::ilist_traits<llvm::BasicBlock> >::getNext(llvm::BasicBlock*)+0x11)[0x83d36c5]
opt(llvm::ilist_iterator<llvm::BasicBlock>::operator++()+0x17)[0x83d011d]
opt(llvm::ilist_iterator<llvm::BasicBlock>::operator++(int)+0x1c)[0x849c64e]
/home/tsharma/ankur/llvm/Debug/lib/LLVMHello.so((anonymous namespace)::Hello::PlaceBlocks(llvm::BasicBlock*)+0x196)[0x115616]
/home/tsharma/ankur/llvm/Debug/lib/LLVMHello.so((anonymous namespace)::Hello::runOnFunction(llvm::Function&)+0x68)[0x115450]
opt(llvm::PassManagerTraits<llvm::Function>::runPass(llvm::FunctionPass*, llvm::Function*)+0x1b)[0x8645e0b]
opt(llvm::PassManagerT<llvm::Function>::runOnUnit(llvm::Function*)+0x5c5)[0x8645739]
opt(llvm::PassManagerTraits<llvm::Function>::runOnFunction(llvm::Function&)+0x1b)[0x86463af]
opt(llvm::FunctionPass::runOnModule(llvm::Module&)+0xa4)[0x85ef606]
opt(llvm::PassManagerTraits<llvm::Module>::runPass(llvm::ModulePass*, llvm::Module*)+0x1b)[0x8640f7b]
opt(llvm::PassManagerT<llvm::Module>::runOnUnit(llvm::Module*)+0x5c5)[0x863ff8b]
opt(llvm::PassManagerTraits<llvm::Module>::runOnModule(llvm::Module&)+0x1b)[0x8642f0d]
opt(llvm::PassManager::run(llvm::Module&)+0x1f)[0x85ee965]
opt(main+0x988)[0x83b225c]
/lib/tls/libc.so.6(__libc_start_main+0xe3)[0x675e33]
opt(__gxx_personality_v0+0x111)[0x83b1751]
Segmentation fault
------------------------------------------------------------------------------------------------------

Thanks

Tanu

---------------------------------
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.

-Chris

Also I have in Makefile.rules (but not include in patch) some modification for simplify used common Makefile.rules in LLVM projects and non-LLVM project (guarding some LLVM specific parts by ifdef LLVM_OBJ_ROOT/LLVM_SRC_ROOT vars).

I'm not sure about this, perhaps Reid would like to comment?

Patch attached.

This patch with header installation patch ( http://mail.cs.uiuc.edu/pipermail/llvmdev/2005-February/003300.html )
let external project (I am test it at my YAFL frontend for LLVM) build using installed LLVM version instead using LLVM obj/src dirs.

After patch applying:

If LLVM_SRC_ROOT/LLVM_OBJ_ROOT variables set
project use for build LLVM object/source dir (current behavior)
or else if LLVM_ROOT set
project use for build installed LLVM dir
or else
project can use only LLVM tools in PATHs if installed LLVM dir added to PATH

Also i remove LLVMExmplDir (i not found any it uses in llvm, llvm-java, llvm-test CVS modules)
And remove redundent line (as i think):
.PRECIOUS: $(LLVMLibDir)/.dir $(LLVMToolDir)/.dir $(LLVMExmplDir)/.dir

Any comments?

Vladimir

Makefile.rules.patch (6 KB)

Thanks a lot for replying Chris,

I m trying to randomize the blocks in a program.I generate a random number( between the
current “InsertPos” and the last block), and then iterate through the list of basicblocks , picking up block with position equal to that of the random number and place it into the current InsertPos and increment InsertPos.

Running it like this:

Hello.cpp (3.1 KB)

helloprog.bc (252 Bytes)

Thanks a lot for replying Chris,

I m trying to randomize the blocks in a program.I generate a random number( between the current "InsertPos" and the last block), and then iterate through the list of basicblocks , picking up block with position equal to that of the random number and place it into the current InsertPos and increment InsertPos.

Running it like this:
-------------------------------------------------------------------
opt -load /home/tsharma/ankur/llvm/Debug/lib/LLVMHello.so -hello <helloprog.bc> /dev/null
---------------------------------------------------------------------

I wish to make it more sophisticated but initially was trying to see whether a simple modification to BasicBlockPlacement works or not.

Ok, that makes sense. The only thing to be careful about is the entry block. The first block in a function is automatically designated as the entry block, so be careful not to move it :slight_smile:

Also when I try to run the -block-placement pass , I get the following message:
---------------------------------------------------------------------------------
[tsharma@strauss programs]$ opt -load /home/tsharma/ankur/llvm/Debug/lib/LLVMScalarOpts.so -block-placement <helloprog.bc> /dev/null
Two passes with the same argument (-tailcallelim) attempted to be registered!
Aborted
---------------------------------------------------------------------------------

I think it is a simple bug but being very new to llvm , not able to detect.

The issue there is that 'opt' already includes all of the scalar optimizations. Please try it again without the -load option and it should work. Note that the -block-placement pass really wants to be profile driven, so you need to pass in profile info generated by the utils/profile.pl script, and loaded with the -profile-loader pass.

-Chris

I think the patch looks basically sane. The one wierd thing I notice is the replacement of mklib with libtool.

However, this is definitely something Reid should review. I think he's currently out of town but will be back next week.

-Chris

Looks good to me, patch applied:
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050207/023978.html

Thanks!

-Chris

Patch attached.

This patch with header installation patch ( http://mail.cs.uiuc.edu/pipermail/llvmdev/2005-February/003300.html )
let external project (I am test it at my YAFL frontend for LLVM) build using installed LLVM version instead using LLVM obj/src dirs.

I think the patch looks basically sane. The one wierd thing I notice is the replacement of mklib with libtool.

Ops... I must be more careful. Updated patch attached.

I use for build libtool "ltmain.sh (GNU libtool) 1.5.10" without problems.
But I add code to preserve use $(LLVM_OBJ_ROOT)/mklib if LLVM_OBJ_ROOT set
In other cases if $(LLVM_OBJ_ROOT)/mklib using important it installation can be added to LLVM/PROJ install process

However, this is definitely something Reid should review. I think he's currently out of town but will be back next week.

Waiting... :slight_smile:

Vladimir

Makefile.rules.patch (6.08 KB)

Vladimir,

I took a *very quick* look at your patch. I won't be able to look at it in more detail until this weekend, but perhaps you can address a couple of concerns:

1. I don't understand the need for LLVMToolDirSlash. This seems like a
    gratuitous change to me.
2. I don't think the change to CPP.Flags is right. It won't find the LLVM
    header files
3. Removing the .PRECIOUS line will interfere with correct operation of
    parallel (make -j N) builds.
4. I don't understand why LLVMUsedLibs and other variables should only be
    set if LLVMLibDir is defined.

Before this change is committed, you need to test that all our scenarios, in each combination:

1. Both with and without OBJ_DIR == SRC_DIR
2. Single and Parallel builds
3. Building LLVM versus building a project (and now building from installed)

Reid.

Vladimir Merzliakov wrote:

Vladimir,

I took a *very quick* look at your patch. I won't be able to look at it in
more detail until this weekend, but perhaps you can address a couple of
concerns:

1. I don't understand the need for LLVMToolDirSlash. This seems like a
   gratuitous change to me.

If LLVM_OBJ_ROOT (with LLVM_SRC_ROOT) and LLVM_ROOT both not set
without LLVMToolDirSlash we will have "/gccas$(EXEEXT)", for example.
This is not problem for project that not use LLVM tools and libs.
But this not permite one useful case: project that use only LLVM tools and LLVM tools
directory added to PATH.
In this case using LLVMToolDirSlash we have correct tool name
"gccas$(EXEEXT)" and tool can find by PATHs.

2. I don't think the change to CPP.Flags is right. It won't find the LLVM
   header files

I build my frontend in LLVM_ROOT set case and LLVM headers find fine.

I already found bug in LLVM_OBJ_ROOT case in proposed patch :frowning:
+ LLVMIncDirs := $(LLVM_OBJ_ROOT)/$(BuildMode)/include
instead

+ LLVMIncDirs := $(LLVM_OBJ_ROOT)/include

3. Removing the .PRECIOUS line will interfere with correct operation of
   parallel (make -j N) builds.

When external project build
$(LLVMLibDir)/.dir $(LLVMToolDir)/.dir $(LLVMExmplDir)/.dir files and
directories already exist and then
using .PRECIOUS redundent in this case (as i think).
In time LLVM build this files and directories listed in line:
.PRECIOUS: $(ObjDir)/.dir $(LibDir)/.dir $(ToolDir)/.dir $(ExmplDir)/.dir
I will test patch with parallel builds.

Related question lines:
-LLVMExmplDir:= $(LLVM_OBJ_ROOT)/$(BuildMode)/examples
and
-.PRECIOUS: $(LLVMLibDir)/.dir $(LLVMToolDir)/.dir $(LLVMExmplDir)/.dir

Is removing LLVMExmplDir definition is ok? It not used anywhere in LLVM CVS

4. I don't understand why LLVMUsedLibs and other variables should only be
   set if LLVMLibDir is defined.

I don link strange filenames if LLVMLibDir will not define and project
tooldir/Makefile set LLVMLIBS.
But i will skip this part of changes in next version of patch.

Before this change is committed, you need to test that all our scenarios,
in each combination:

1. Both with and without OBJ_DIR == SRC_DIR
2. Single and Parallel builds
3. Building LLVM versus building a project (and now building from
installed)

ok, will do...

I found some bugs in my patch and then I will send updated version after it testing.

Thank you for comments!

Vladimir

Before this change is committed, you need to test that all our scenarios,
in each combination:

1. Both with and without OBJ_DIR == SRC_DIR
2. Single and Parallel builds
3. Building LLVM versus building a project (and now building from
installed)

ok, will do...

I found some bugs in my patch and then I will send updated version after it testing.

I finish testting new patch version (attached):
Build and install LLVM (4 variant: OBJ_DIR != SRC_DIR, OBJ_DIR == SRC_DIR in single and parallel ( -j 4 ))
Build llvm-java using 2 variant LLVM (OBJ_DIR != SRC_DIR, OBJ_DIR == SRC_DIR)
Build my frontend using LLVM_ROOT

Vladimir

Makefile.rules.patch (5.78 KB)

Sorry, wrong (outdated) patch attached in prev. mail :frowning:

Sending correct patch.

Before this change is committed, you need to test that all our scenarios,
in each combination:

1. Both with and without OBJ_DIR == SRC_DIR
2. Single and Parallel builds
3. Building LLVM versus building a project (and now building from
installed)

ok, will do...

I found some bugs in my patch and then I will send updated version after
it testing.

I finish testting new patch version (attached):
Build and install LLVM (4 variant: OBJ_DIR != SRC_DIR, OBJ_DIR == SRC_DIR in
single and parallel ( -j 4 ))
Build llvm-java using 2 variant LLVM (OBJ_DIR != SRC_DIR, OBJ_DIR ==
SRC_DIR)
Build my frontend using LLVM_ROOT

Vladimir

Makefile.rules.patch (5.78 KB)