build optimizing(轉改)

 

linux共享庫位置配置(LD_LIBRARY_PATH環境變量 或者 更改/etc/ld.so.conf 或者 使用-R選項)html

 

今天下午嘗試使用libosip2,安裝比較簡單,按照自帶的help文檔裏面的操做進行便可。mysql

$>mkdir linux-build linux

$>cd linux-buildgit

$>../libosip2-2.2.0/configuresql

$>make                          (最後2步要在管理員權限下執行)shell

# make install bash

完成以後,會在/usr/local/lib路徑下生成一些lioosipXXX.so的文件,在/usr/local/include下生成關於osip的頭文件。app

爲了測試安裝是否正確,在eclipse下建了個測試項目,寫了很簡單的代碼:less

#include //不加的話,編譯時會報錯,可能osip依賴於time.heclipse

#include

//之因此能找到/usr/local/include下關於osip的頭文件,是由於eclipse默認把/usr/local/include放到Include directories裏面了。在eclipse的項目屬性-->C++ General-->Path and symbols -->Include裏面能夠看到。若是本身寫makefile文件的話,要加上-I 選項,表示程序裏include的頭文件去哪裏找。參見

http://blog.csdn.net/liuzhuan_1986/archive/2009/07/05/4323274.aspx 關於頭文件說明

 

#include

using namespace std;

int main()

{

int i;

osip_t *osip;

i = osip_init(&osip);

if(i != 0)

cout << "error" << endl;

cout << "ok" << endl;

return 0;

}

 

而且在eclipse的項目屬性-->C/C++ Build-->Settings-->Tool settings-->GCC C++ Linker-->Libraries加上-lpthread -losip2的選項。

編譯連接都沒有問題,運行時報錯:

error while loading shared libraries: libosip2.so.4: cannot open shared object file: No such file or directory

 

而後查到多是由於共享庫設置的問題:

下面的幾段是轉載的,看了以後明白linux怎麼找到共享庫的

===========================================================================================

Linux 運行的時候,是如何管理共享庫(*.so)的?在 Linux 下面,共享庫的尋找和加載是由 /lib/ld.so 實現的。 ld.so 在標準路經(/lib, /usr/lib) 中尋找應用程序用到的共享庫。

可是,若是須要用到的共享庫在非標準路經,ld.so 怎麼找到它呢?

目前,Linux 通用的作法是將非標準路經加入 /etc/ld.so.conf,而後運行 ldconfig 生成 /etc/ld.so.cache。 ld.so 加載共享庫的時候,會從 ld.so.cache 查找。

傳統上,Linux 的先輩 Unix 還有一個環境變量:LD_LIBRARY_PATH 來處理非標準路經的共享庫。ld.so 加載共享庫的時候,也會查找這個變量所設置的路經。

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:./lib

export LD_LIBRARY_PATH

可是,有很多聲音主張要避免使用 LD_LIBRARY_PATH 變量,尤爲是做爲全局變量。這些聲音是:

* LD_LIBRARY_PATH is not the answer - http://prefetch.net/articles/linkers.badldlibrary.html

* Why LD_LIBRARY_PATH is bad - http://xahlee.org/UnixResource_dir/_/ldpath.html 

* LD_LIBRARY_PATH - just say no - http://blogs.sun.com/rie/date/20040710

解決這一問題的另外一方法是在編譯的時候經過 -R 選項指定 run-time path。

1. 往/lib和/usr/lib裏面加東西,是不用修改/etc/ld.so.conf的,可是完了以後要調一下ldconfig,否則這個library會找不到

2. 想往上面兩個目錄之外加東西的時候,必定要修改/etc/ld.so.conf,而後再調用ldconfig,否則也會找不到。

好比安裝了一個mysql到/usr/local/mysql,mysql有一大堆library在/usr/local/mysql/lib下面,這時就須要在/etc/ld.so.conf下面加一行/usr/local/mysql/lib,保存事後ldconfig一下,新的library才能在程序運行時被找到。

3. 若是想在這兩個目錄之外放lib,可是又不想在/etc/ld.so.conf中加東西(或者是沒有權限加東西)。那也能夠,就是export一個全局變量LD_LIBRARY_PATH,而後運行程序的時候就會去這個目錄中找library。通常來說這只是一種臨時的解決方案,在沒有權限或臨時須要的時候使用。

4. ldconfig作的這些東西都與運行程序時有關,跟編譯時一點關係都沒有。編譯的時候仍是該加-L就得加,不要混淆了。

5. 總之,就是無論作了什麼關於library的變更後,最好都ldconfig一下,否則會出現一些意想不到的結果。不會花太多的時間,可是會省不少的事。

LD_LIBRARY_PATH 這個環境變量是你們最爲熟悉的,它告訴loader:在哪些目錄中能夠找到共享庫。能夠設置多個搜索目錄,這些目錄之間用冒號分隔開。在linux下,還提供了另一種方式來完成一樣的功能,你能夠把這些目錄加到/etc/ld.so.conf中,而後調用ldconfig。固然,這是系統範圍內全局有效的,而環境變量只對當前shell有效。按照慣例,除非你用上述方式指明,loader是不會在當前目錄下去找共享庫的,正如shell不會在當前目前找可執行文件同樣。

================================================================================================

 

在shell下嘗試設置LD_LIBRARY_PATH,如下面這種形式設置,總是報錯bash: LD_LIBRARY_PATH: command not found,

LD_LIBRARY_PATH=/usr/local/lib

LD_LIBRARY_PATH = $ LD_LIBRARY_PATH:/usr/local/lib

多是由於系統以前沒有設置過LD_LIBRARY_PATH,因而改爲這樣:

export LD_LIBRARY_PATH=/usr/local/lib

而後用 echo $LD_LIBRARY_PATH檢查一下是否真的設置成功,發現能夠。

接着在該shell下運行eclipse生成的可執行文件,沒有錯誤。

 

另外,若是不想每次新啓一個shell都設置LD_LIBRARY_PATH,能夠編輯~/.bash_profile文件:

$ vi ~/.bash_profile 

添加:

LD_LIBRARY_PATH=/usr/local/lib

export LD_LIBRARY_PATH

這兩行,完成以後.bash_profile以下所示:

 

# .bash_profile

# Get the aliases and functions

if [ -f ~/.bashrc ]; then

        . ~/.bashrc

fi

# User specific environment and startup programs

PATH=$PATH:$HOME/bin

LD_LIBRARY_PATH=/usr/local/lib

export PATH

export LD_LIBRARY_PATH

而後運行
$ source ~/.bash_profile 就好了。

 

可是這種方法只能用在shell下,想在eclipse裏面運行,仍是不行:

嘗試了eclipse項目properties裏面的各類設置都不起做用。

用「eclipse LD_LIBRARY_PATH」做爲關鍵字(可見關鍵字多麼重要)才搜到這麼篇文章 《eclipse+cdt+gcc編譯選項控制》 http://hi.baidu.com/zsffei/blog/item/7b17c043ceb51e1772f05de1.html

才知道應該在eclipse的項目屬性-->C/C++ Build-->Settings-->Tool settings-->GCC C++ Linker-->Miscellaneous的Other options (-Xlinker [option])添加 -R/usr/local/lib

運行,一切正常,折騰了一下午,太感動了。

##############################

Build Targets
Prev  Chapter 11.  Kernel build command line reference  Next

Build Targets

These targets build the kernel itself in a variety of ways.

Table 11.4. Build targets

 

Target

Description

all

Builds all of the different targets needed for this kernel to be able to be used. This includes both the modules and the static portion of the kernel.

vmlinux

Builds just the static portion of the kernel, not any loadable modules.

modules

Builds all of the loadable kernel modules for this configuration.

modules_install

Installs all of the modules into the specified location. If no location is specified with the INSTALL_MODULE_PATH environment variable, they are installed in the default root directory of the machine.

dir/

Builds all of the files in the specified directory and in all subdirectories below it.

dir/file.[ o | i |]

Builds only the specified file.

dir/file.ko

Builds all of the needed files and links them together to form the specified module.

tags

Builds all of the needed tags that most common text editors can use while editing the source code.

TAGS

Builds all of the needed tags that most common text editors can use while editing the source code.

cscope

Builds a cscope image, useful in source tree searches, of the source tree for the architecture specified by the configuration file (not all of the kernel source files).

You can also pass a number of environment variables to make that will change the build. These can be specified for almost any target.

Table 11.5. Environment variables

 

Variable

Value

Description

V

0

This tells the build system to run in a quiet manner, showing only the file that is currently being built, and not the entire command that is running in order to build that file. This is the default option for the build system.

V

1

This tells the build system to operate in a verbose way, showing the full command that is being used to generate each of the specific files.

O

dir

This tells the build system to locate all output files in the dir directory, including the kernel configuration files. This allows the kernel to be built from a read-only filesystem and have the output placed in another location.

C

1

This checks all C files that are about to be built with the sparse tool, which detects common programming errors in the kernel source files. sparse can be downloaded using git from git://git.kernel.org/pub/scm/devel/sparse/sparse.git. Nightly snapshots can be found at http://www.codemonkey.org.uk/projects/git-snapshots/sparse/. More information on how to use sparse can be found in the Documentation/sparse.txt file in the kernel source tree.

C

2

This forces all C files to be checked with the sparse tool, even if they did not need to be built.

#################

export CC=/your/path/to/gcc
export CXX=/your/path/to/g++

 

###################

http://www.gentoo.org/doc/en/gcc-optimization.xml

Compilation Optimization Guide

Content: 1. Introduction 2. Optimizing 3. Optimization FAQs 4. Resources

1.  Introduction

What are CFLAGS and CXXFLAGS?

CFLAGS and CXXFLAGS are environment variables that are used to tell the GNU Compiler Collection, gcc, what kinds of switches to use when compiling source code. CFLAGS are for code written in C, while CXXFLAGS are for code written in C++.

They can be used to decrease the amount of debug messages for a program, increase error warning levels, and, of course, to optimize the code produced. The GNU gcc handbook maintains a complete list of available options and their purposes.

How are they used?

CFLAGS and CXXFLAGS can be used in two ways. First, they can be used per-program with Makefiles generated by automake.

However, this should not be done when installing packages found in the Portage tree. Instead, set your CFLAGS and CXXFLAGS in /etc/make.conf. This way all packages will be compiled using the options you specify.

 

Code Listing 1.1: CFLAGS in /etc/make.conf

CFLAGS="-march=athlon64 -O2 -pipe"
CXXFLAGS="${CFLAGS}"

As you can see, CXXFLAGS is set to use all the options present in CFLAGS. This is what you'll want almost without fail. You shouldn't ever need to specify additional options in CXXFLAGS.

Misconceptions

While CFLAGS and CXXFLAGS can be very effective means of getting source code to produce smaller and/or faster binaries, they can also impair the function of your code, bloat its size, slow down its execution time, or even cause compilation failures!

CFLAGS are not a magic bullet; they will not automatically make your system run any faster or your binaries to take up less space on disk. Adding more and more flags in an attempt to optimize (or "rice") your system is a sure recipe for failure. There is a point at which you will reach diminishing returns.

Despite the bragging you'll find on the internet, aggressive CFLAGS and CXXFLAGS are far more likely to harm your programs than do them any good. Keep in mind that the reason the flags exist in the first place is because they are designed to be used at specific places for specific purposes. Just because one particular CFLAG is good for one bit of code doesn't mean that it is suited to compiling everything you will ever install on your machine!

Ready?

Now that you're aware of some of the risks involved, let's take a look at some sane, safe optimizations for your computer. These will hold you in good stead and will endear you to developers the next time you report a problem on Bugzilla. (Developers will usually request that you recompile a package with minimal CFLAGS to see if the problem persists. Remember, aggressive flags can ruin code.)

2.  Optimizing

The basics

The goal behind using CFLAGS and CXXFLAGS is to create code tailor-made to your system; it should function perfectly while being lean and fast, if possible. Sometimes these conditions are mutually exclusive, so we'll stick with combinations known to work well. Ideally, they are the best available for any CPU architecture. We'll mention the aggressive flags later so you know what to look out for. We won't discuss every option listed on the gcc manual (there are hundreds), but we'll cover the basic, most common flags.

 

Note: Whenever you're not sure what a flag actually does, refer to the relevant chapter of the gcc manual. If you're still stumped, try Google, or check out the gcc mailing lists.

-march

The first and most important option is -march. This tells the compiler what code it should produce for your processor architecture (or arch); it says that it should produce code for a certain kind of CPU. Different CPUs have different capabilities, support different instruction sets, and have different ways of executing code. The -march flag will instruct the compiler to produce code specifically for your CPU, with all its capabilities, features, instruction sets, quirks, and so on.

Even though the CHOST variable in /etc/make.conf specifies the general architecture used, -march should still be used so that programs can be optimized for your specific processor. x86 and x86-64 CPUs (among others) should make use of the -march flag.

What kind of CPU do you have? To find out, run the following command:

 

Code Listing 2.1: Examining CPU information

$ cat /proc/cpuinfo

Now let's see -march in action. This example is for an older Pentium III chip:

 

Code Listing 2.2: /etc/make.conf: Pentium III

CFLAGS="-march=pentium3"
CXXFLAGS="${CFLAGS}"

Here's another one for a 64-bit AMD CPU:

 

Code Listing 2.3: /etc/make.conf: AMD64

CFLAGS="-march=athlon64"
CXXFLAGS="${CFLAGS}"

If you still aren't sure what kind of CPU you have, you may just want to use -march=native. When this flag is used, GCC will detect your processor and automatically set appropriate flags for it.However, this should not be used if you intend to compile packages for a different CPU!

So if you're compiling packages on one computer, but intend to run them on a different computer (such as when using a fast computer to build for an older, slower machine), then do not use -march=native. "Native" means that the code produced will run only on that type of CPU. The applications built with -march=native on an AMD Athlon 64 CPU will not be able to run on an old VIA C3 CPU.

Also available are the -mtune and -mcpu flags. These flags are normally only used when there is no available -march option; certain processor architectures may require -mtune or even -mcpu. Unfortunately, gcc's behavior isn't very consistent with how each flag behaves from one architecture to the next.

On x86 and x86-64 CPUs, -march will generate code specifically for that CPU using all its available instruction sets and the correct ABI; it will have no backwards compatibility for older/different CPUs. If you don't need to execute code on anything other than the system you're running Gentoo on, continue to use -march. You should only consider using -mtune when you need to generate code for older CPUs such as i386 and i486. -mtune produces more generic code than -march; though it will tune code for a certain CPU, it doesn't take into account available instruction sets and ABI. Don't use -mcpu on x86 or x86-64 systems, as it is deprecated for those arches.

Only non-x86/x86-64 CPUs (such as Sparc, Alpha, and PowerPC) may require -mtune or -mcpu instead of -march. On these architectures, -mtune/-mcpu will sometimes behave just like -march (on x86/x86-64) . . . but with a different flag name. Again, gcc's behavior and flag naming just isn't consistent across architectures, so be sure to check the gcc manual to determine which one you should use for your system.

 

Note: For more suggested -march/-mtune/-mcpu settings, please read chapter 5 of the appropriate Gentoo Installation Handbook for your arch. Also, read the gcc manual's list of architecture-specific options, as well as more detailed explanations about the differences between -march-mcpu, and -mtune.

-O

Next up is the -O variable. This controls the overall level of optimization. This makes the code compilation take somewhat more time, and can take up much more memory, especially as you increase the level of optimization.

There are five -O settings: -O0-O1-O2-O3, and -Os. You should use only one of them in /etc/make.conf.

With the exception of -O0, the -O settings each activate several additional flags, so be sure to read the gcc manual's chapter on optimization options to learn which flags are activated at each -Olevel, as well as some explanations as to what they do.

Let's examine each optimization level:

  • -O0: This level (that's the letter "O" followed by a zero) turns off optimization entirely and is the default if no -O level is specified in CFLAGS or CXXFLAGS. Your code will not be optimized; it's not normally desired.
  • -O1: This is the most basic optimization level. The compiler will try to produce faster, smaller code without taking much compilation time. It's pretty basic, but it should get the job done all the time.
  • -O2: A step up from -O1. This is the recommended level of optimization unless you have special needs. -O2 will activate a few more flags in addition to the ones activated by -O1. With -O2, the compiler will attempt to increase code performance without compromising on size, and without taking too much compilation time.
  • -O3: This is the highest level of optimization possible, and also the riskiest. It will take a longer time to compile your code with this option, and in fact it should not be used system-wide withgcc 4.x. The behavior of gcc has changed significantly since version 3.x. In 3.x, -O3 has been shown to lead to marginally faster execution times over -O2, but this is no longer the case with gcc4.x. Compiling all your packages with -O3 will result in larger binaries that require more memory, and will significantly increase the odds of compilation failure or unexpected program behavior (including errors). The downsides outweigh the benefits; remember the principle of diminishing returns. Using -O3 is not recommended for gcc 4.x.
  • -Os: This level will optimize your code for size. It activates all -O2 options that don't increase the size of the generated code. It can be useful for machines that have extremely limited disk storage space and/or have CPUs with small cache sizes. However, it can cause quite a few problems, which is why it is filtered out by many of the ebuilds in the tree. Using -Os is not recommended.

As previously mentioned, -O2 is the recommended optimization level. If package compilations error out, check to make sure that you aren't using -O3. As a fallback option, try setting your CFLAGS and CXXFLAGS to a lower optimization level, such as -O1 or even -O0 -g2 -ggdb (for error reporting and checking for possible problems) and recompile the package.

-pipe

A common flag is -pipe. This flag actually has no effect on the generated code, but it makes the compilation process faster. It tells the compiler to use pipes instead of temporary files during the different stages of compilation, which uses more memory. On systems with low memory, gcc might get killed. In that case, do not use this flag.

-fomit-frame-pointer

This is a very common flag designed to reduce generated code size. It is turned on at all levels of -O (except -O0) on architectures where doing so does not interfere with debugging (such as x86-64), but you may need to activate it yourself by adding it to your flags. Though the GNU gcc manual does not specify all architectures it is turned on by using -O, you will need to explicitly activate it on x86. However, using this flag will make debugging hard to impossible.

In particular, it makes troubleshooting applications written in Java much harder, though Java is not the only code affected by using this flag. So while the flag can help, it also makes debugging harder; backtraces in particular will be useless. However, if you don't plan to do much software debugging and haven't added any other debugging-related CFLAGS such as -ggdb, then you can try using -fomit-frame-pointer.

 

Important: Do not combine -fomit-frame-pointer with the similar flag -momit-leaf-frame-pointer. Using the latter flag is discouraged, as -fomit-frame-pointer already does the job properly. Furthermore, -momit-leaf-frame-pointer has been shown to negatively impact code performance.

-msse, -msse2, -msse3, -mmmx, -m3dnow

These flags enable the SSESSE2SSE3MMX, and 3DNow! instruction sets for x86 and x86-64 architectures. These are useful primarily in multimedia, gaming, and other floating point-intensive computing tasks, though they also contain several other mathematical enhancements. These instruction sets are found in more modern CPUs.

 

Important: Be sure to check if your CPU supports these by running cat /proc/cpuinfo. The output will include any supported additional instruction sets. Note that pni is just a different name for SSE3.

You normally don't need to add any of these flags to /etc/make.conf as long as you are using the correct -march (for example, -march=nocona implies -msse3). Some notable exceptions are newer VIA and AMD64 CPUs that support instructions not implied by -march (such as SSE3). For CPUs like these you'll need to enable additional flags where appropriate after checking the output of cat /proc/cpuinfo.

 

Note: You should check the list of x86 and x86-64-specific flags to see which of these instruction sets are activated by the proper CPU type flag. If an instruction is listed, then you don't need to specify it; it will be turned on by using the proper -march setting.

3.  Optimization FAQs

But I get better performance with -funroll-loops -fomg-optimize!

No, you only think you do because someone has convinced you that more flags are better. Aggressive flags will only hurt your applications when used system-wide. Even the gcc manual says that using -funroll-loops and -funroll-all-loops makes code larger and run more slowly. Yet for some reason, these two flags, along with -ffast-math-fforce-mem-fforce-addr, and similar flags, continue to be very popular among ricers who want the biggest bragging rights.

The truth of the matter is that they are dangerously aggressive flags. Take a good look around the Gentoo Forums and Bugzilla to see what those flags do: nothing good!

You don't need to use those flags globally in CFLAGS or CXXFLAGS. They will only hurt performance. They may make you sound like you have a high-performance system running on the bleeding edge, but they don't do anything but bloat your code and get your bugs marked INVALID or WONTFIX.

You don't need dangerous flags like these. Don't use them. Stick to the basics: -march-O, and -pipe.

What about -O levels higher than 3?

Some users boast about even better performance obtained by using -O4-O9, and so on, but the reality is that -O levels higher than 3 have no effect. The compiler may accept CFLAGS like -O4, but it actually doesn't do anything with them. It only performs the optimizations for -O3, nothing more.

Need more proof? Examine the gcc source code:

 

Code Listing 3.1: -O source code

if (optimize >= 3)
    {
      flag_inline_functions = 1;
      flag_unswitch_loops = 1;
      flag_gcse_after_reload = 1;
      /* Allow even more virtual operators.  */
      set_param_value ("max-aliased-vops", 1000);
      set_param_value ("avg-aliased-vops", 3);
    }

As you can see, any value higher than 3 is treated as just -O3.

What about redundant flags?

Oftentimes CFLAGS and CXXFLAGS that are turned on at various -O levels are specified redundantly in /etc/make.conf. Sometimes this is done out of ignorance, but it is also done to avoid flag filtering or flag replacing.

Flag filtering/replacing is done in many of the ebuilds in the Portage tree. It is usually done because packages fail to compile at certain -O levels, or when the source code is too sensitive for any additional flags to be used. The ebuild will either filter out some or all CFLAGS and CXXFLAGS, or it may replace -O with a different level.

The Gentoo Developer Manual outlines where and how flag filtering/replacing works.

It's possible to circumvent -O filtering by redundantly listing the flags for a certain level, such as -O3, by doing things like:

 

Code Listing 3.2: Specifying redundant CFLAGS

CFLAGS="-O3 -finline-functions -funswitch-loops"

However, this is not a smart thing to do. CFLAGS are filtered for a reason! When flags are filtered, it means that it is unsafe to build a package with those flags. Clearly, it is not safe to compile your whole system with -O3 if some of the flags turned on by that level will cause problems with certain packages. Therefore, you shouldn't try to "outsmart" the developers who maintain those packages. Trust the developers. Flag filtering and replacing is done for your benefit! If an ebuild specifies alternative flags, then don't try to get around it.

You will most likely continue to run into problems when you build a package with unacceptable flags. When you report your troubles on Bugzilla, the flags you use in /etc/make.conf will be readily visible and you will be told to recompile without those flags. Save yourself the trouble of recompiling by not using redundant flags in the first place! Don't just automatically assume that you know better than the developers.

What about LDFLAGS?

The Gentoo developers have already set basic, safe LDFLAGS in the base profiles, so you don't need to change them.

Can I use per-package flags?

There is no supported method for using CFLAGS or other variables on a per-package basis, though there are a few rather abusive ways of trying force Portage to do so.

 

Warning: You should not try to force Portage to use per-package flags, as it is not in any way supported and will greatly complicate bug reports. Just set your flags in /etc/make.conf to be used on a system-wide basis.

4.  Resources

The following resources are of some help in further understanding optimization:

  • The GNU gcc manual
  • Chapter 5 of the Gentoo Installation Handbooks
  • man make.conf
  • Wikipedia
  • Acovea, a benchmarking and test suite that can be useful for determining how different compiler flags interact and affect generated code, though its code suggestions are not appropriate for system-wide use. It is available in Portage: emerge acovea.
  • The Gentoo Forums

 

#########################轉

http://www.yolinux.com/TUTORIALS/LinuxTutorialOptimization.html

 

Linux System Enhancements, Optimization and Compiling the Kernel

Optimize hard drive access performance:

Hdparm:

The following optimizations techniques can be applied to (E

相關文章
相關標籤/搜索