Total Pageviews

Monday 30 June 2014

在linux vps上搭建基于lein/clojure的静态博客程序-incise

git clone https://github.com/RyanMcG/ryanmcg.github.io ryanmcg.github.io-site
cd ryanmcg.github.io-site

root@as3:~/ryanmcg.github.io-site# ls
project.clj  README.md  resources  src 
root@as3:~/ryanmcg.github.io-site# cd resources
root@as3:~/ryanmcg.github.io-site/resources# ls
assets  content  incise.edn  public
root@as3:~/ryanmcg.github.io-site/resources# cd assets
root@as3:~/ryanmcg.github.io-site/resources/assets# ls
stylesheets  vm
root@as3:~/ryanmcg.github.io-site/resources/assets# git clone https://github.com/RyanMcG/vm-assets vm
root@as3:~/ryanmcg.github.io-site/resources/assets# cd ../..
root@as3:~/ryanmcg.github.io-site# nohup lein incise > /dev/null &
访问http://as3.brite.biz:5000/即可看到网站效果。

发贴方法:
root@as3:~/ryanmcg.github.io-site#
root@as3:~/ryanmcg.github.io-site# cd resources
root@as3:~/ryanmcg.github.io-site/resources# ls
assets  content  incise.edn 
root@as3:~/ryanmcg.github.io-site/resources# cd content
root@as3:~/ryanmcg.github.io-site/resources/content# ls
assets  attributions.md  bio.md  CNAME  index.clj  posts  reading.md
root@as3:~/ryanmcg.github.io-site/resources/content# cd posts
root@as3:~/ryanmcg.github.io-site/resources/content/posts# ls
2013  2014
root@as3:~/ryanmcg.github.io-site/resources/content/posts# cd 2014
root@as3:~/ryanmcg.github.io-site/resources/content/posts/2014# ls
incise.md  manners.md   
root@as3:~/ryanmcg.github.io-site/resources/content/posts/2014# nano test1.md
格式为:
{:title "test1"
 :date "2014-7-1"
 :category :misc
 :publish true
 :tags [:code :clojure :incise :projects]}

## 测试1

这是测试1.

(不要用中文标题,否则易出问题)

root@as3:~/ryanmcg.github.io-site/resources/content/posts/2014# cd ~/ryanmcg.github.io-site
root@as3:~/ryanmcg.github.io-site# lein incise -m once (这个就是生成/更新静态网站的命令)
root@as3:~/ryanmcg.github.io-site# cd resources
root@as3:~/ryanmcg.github.io-site/resources# ls
assets  content  incise.edn  public
(新出现了public目录)
root@as3:~/ryanmcg.github.io-site/resources# cd public
root@as3:~/ryanmcg.github.io-site/resources/public# ls
2013  assets        bio    index.html     reading
2014  attributions  CNAME  manifest.json
root@as3:~/ryanmcg.github.io-site/resources/public#
(可见~/ryanmcg.github.io-site/resources/public/就是静态网站的根目录)
root@as3:~/ryanmcg.github.io-site/resources/public# nohup Rwebserver 25410 > /dev/null &
访问http://as3.brite.biz:25410/即可看到网站效果。

在访问http://as3.brite.biz:25410/2014/1/13/static-website-generation-with-incise/和
http://as3.brite.biz:25410/2013/12/13/swap-numbers-plugin-for-vim/时,可能显示not found.那么访问http://as3.brite.biz:25410/2014/1/13/static-website-generation-with-incise/index.html 和http://as3.brite.biz:25410/2013/12/13/swap-numbers-plugin-for-vim/index.html即可打开之。以后再访问它们时,就不用再加上index.html即可打开。

演示站点:http://as3.brite.biz:25410/,http://as3.brite.biz:5000/,http://incise.brite.biz.st
http://www.ryanmcg.com/ (程序作者用此程序搭建的网站)
项目地址:https://github.com/RyanMcG/ryanmcg.github.io
https://github.com/RyanMcG/vm-assets
https://github.com/RyanMcG/incise
官方教程:http://www.ryanmcg.com/incise/

相关帖子:http://briteming.blogspot.co.uk/2014/06/linux-vpsstasisblog-genaugustl.html
http://briteming.blogspot.co.uk/2014/06/linux-vpsleinmadness.html

填补信用体系空缺是地方政府该干的正事


一家实体企业的倒掉,往往会对其所在地区的税收、金融、经济带来一系列连锁反应。在中国,忙于眼前坏账风险的银行分行、支行一般无暇顾及这一点,而企业本身的声音又往往太过微弱,于是关注这一风险的使命不由得落到了银行和企业的最大“利益攸关方”——地方政府的身上。
杭州市萧山区地方政府便是上述现状的最佳例子:这一杭州经济强区的地方政府为了防止银行对当地诸多骨干民企“一刀切”式地抽贷,曾以自己在银行的存款、养 老保险资金等相“威胁”,警告银行“谁抽贷我们就要通报谁”。“若还是继续抽贷,我们萧山不要你了”。安邦(ANBOUND)研究团队曾以此为例,警告中 国银行业不应忘记自己也是市场共生体系中的一员,“釜底抽薪”可能会引火烧身。
近日,这一涉及政、银、企三方的危机似乎逐渐平息了下来,而主导因素恰恰就是地方政府的积极“协调”。由于萧山、富阳等周边市县区出险企业的授信银行多在 杭州市区,杭州近日在市级层面出台了一个联动的《杭州市企业资金链风险防范与化解工作方案》(下称《方案》),提出要灵活采用盘活土地等存量资产、税费减 免缓交、项目资助补助、推动企业脱保还贷转向其他融资手段、注入企业主个人资产、国有担保公司或平台有条件介入、切断互保链风险、协调债权银行平移担保负 债、积极引入战略投资者或资产管理公司参与、充实并发挥市、区(县、市)两级企业应急周转资金等手段。简单来说,即是利用地方政府自己手中的工具和资源, 来为地方企业缓解资金压力。不过企业的情况不同,地方政府的侧重点也不同:自身各方面状况良好却因互保、被抽贷导致暂时资金周转困难的,地方政府只需做好 银行的协调工作即可;对于确有不小风险但本身有市场有品牌的大企业,地方政府会“及早介入,采取行政协调、司法集中管辖、企业瘦身、市场重组等手段,加大 帮扶力度”;至于产能过剩、无救助价值的企业,政府则着重为其进入司法程序处置创造条件。
虽然在该事件的解决上,“政府之手”再次占据主导,不过此事要具体分析。安邦研究团队认为,在当前的地方金融环境下,这不失为最有效的解决方案,值得有类 似问题的其他地方政府借鉴。中国发生银行“抽贷”潮的本质原因,一是银行和企业之间没有互信,企业抱怨银行不关注企业具体情况,而银行则惧怕企业隐瞒其真 实财务状况,二是银行之间亦缺乏信任和合作,一家银行抽贷往往源于担忧其他银行会抢先抽贷,“后下手遭殃”。杭州地方政府在这一冲突中,充当了信用的通道 和担保者,一边利用自身资源为企业增信,另一边又靠自身信用与银行谈判,弥补了地方信用体系的缺失,目前看来效果明显:据杭州地方化解办人士说,通过各项 措施,现在杭州民企互保链、资金链开始趋于稳定,出险的企业也越来越少。
比起利用融资平台等工具直接参与、影响地方经济,地方政府动用自身资源和影响力来为企业解决问题,无疑是一种更可持续的“有限度的干预”。杭州的案例为此 提供了一个可操作、可复制的基础框架。不过,弥补地方信用体系的空缺,这一使命虽然短期内只有地方政府可以承担,长期来看地方政府则需要逐渐让位于民间资 本和市场的力量,推动非政府力量来完善地方信用体系,而非强化自身在其中的地位。值得注意的是,央行从4月起已开始接受民间资本申请个人征信牌照,中国由 央行征信中心一家独大的征信格局可能发生里程碑式的改变,地方经济终于有机会获得真正“接地气”的信用调查机构的参与,这是从根本上改变企业与银行缺乏互 信的最佳途径,也是快速准确拆解互保联保问题的基础。
另外还需要强调的是,地方政府作为信用“中介”和“通道”的作用要想让位于市场,银行业自身的自律合作也必不可少。在西方商业银行解决某一企业或地区的严 重借贷危机时,相关银行往往最先会碰头协商,试图自行分配责任和损失,而中国的银行却首先想到抢先拆台,这种短视的行为最终引发了政府信用的介入。在地方 政府的协调下,5月萧山区43家银行签署“银行业服务实体经济同业协定”,公开承诺不压贷不抽贷,这才给该事件提供了被妥善解决的时间.

Sunday 29 June 2014

“新话”的面目

"新话”是乔治•奥威尔影响深远的着作《一九八四》中,虚构的“大洋国”使用的正式语言。它存在的唯一目的,是满足英社(英格兰社会主义)的需要,“不仅提 供一种表达世界观和思想习惯的合适手段,而且也是为了使所有其他思想方式不可能再存在”。奥威尔没有预知未来的能力;《一九八四》这部1949年出版的作 品,所描写的大洋国生活图景却如同谶语,成为正在发生的现实。
1949年建政以来,众多的词语被赋予了新的政治含义。例如,人民、革命、万寿无疆等用以表达官方意识形态的伟大、光荣和正确;敌人、反革命、自绝于人民 等用以批判对手的荒谬、错误和原罪;辩证、一分为二、偏激等被用来教育民众要理性、中立、客观。在“新话”体系中,这些无辜的词语被专制侵染,被改头换 面,承载着不同的任务。
“新话”语法体系的核心是专制合法性。建政以来,当局利用教育、文化、媒体、社会活动等多种途径,投入大量的人力、物力、财力资源来推广它的合法性。在 “新话”的语境里,革命、优越、先进构成了合法性的正面,反动、腐朽、落后构成了合法性的反面,既有的各种思想、行为、价值、文化,都要在专制合法性方面 接受检验,然后或者被抛弃,或者被改造,最终统一为专制不容质疑的合法性背书。
历经“反右”、“破四旧”、“文化大革命”、“改革开放”等运动,“新话”的语法体系成为当局统治技术和统治工具的重要组成部分。它的建立过程,也就是专 制的合法性向民间灌输的过程;它向民间灌输的过程,也就是极权治理体系铺成网络、深入人心的过程。这些“新话”,来得潜移默化,去得恋恋不舍,不仅在当 前,而且会在此后很多年,都成为头脑中挥之不去的阴霾,持续影响几代人的思维模式。
极权塑造思维的野心,不仅是宏伟远大的,而且是持之以恒的。 “新话”的一个重要特征,是它的伪经验和反常识。极权垄断的宣传机器和政治实践,把批量的意识形态和思维模式,以及成系统、成规模的伪经验和反常识灌输给 大众,实现经验和常识的剥夺。经验思维是内向的直觉判断和选择,常识思维是外向的理性认识和评价。历史的虚无、隐藏、扭曲,以及在压迫下被逼作出的利益选 择,使民众的伪经验被固定下来,深入到生活的方方面面,成为不由自主的日常规范;理论的欺骗式宣传和虚伪的道德表演,使民众的常识退化、匮乏,失去信仰, 在大一统的集体主义、饱含民族狂热的爱国主义、实用庸俗的唯物主义陶冶中,成为庞大的体制机器中一颗颗毫无自我表征的螺丝钉。“新话”所代表的不同政治含 义和它们在日常生活中扭曲的应用体验,就是每一个螺丝钉在体制机器中被赋予的各种型号和用途。
“新话”的另一个重要特征,是它具备强大的自我教育能力。在专制当局长期的经营之下,伪经验的根深蒂固和常识的退化匮乏,使人们一边选择与体制同流合污, 一边站在道德高地无所顾忌地指责他人,在充盈的矛盾中自我扭曲。这既是“洗脑”的必然结果,也使民众通过一次次的体验自觉不自觉地巩固着这个成果。专制的 经济,本身就是洗脑的经济;专制的政治,也就是洗脑的政治。它为了维护专制合法性所推行的意识形态,为了持续获取专制利益所建立的经济模式,就是要让个体 在被迫选择中自我割裂,成为扭曲的双面人。在这个意义上说,“新话”的理解和接受程度,也就是民众思想和利益的认知水平。
专制使人在变坏的同时变得愚昧。人们对罪恶熟视无睹,在挣扎中苟延残喘,对抗争者不屑一顾。民主社会的建立和自由权利的拥有,固然不需要素质作为前提;但 在专制背景下,思想和利益的认知水平直接影响着抗争的动力和质量。消解专制之毒,从摆脱专制对思维和语言的控制和侵染开始,从打破专制对思想文化解释权的 垄断开始。“新话”的语法体系、灌输渠道有强大的专制机器作为后盾,对它实施解构和“反编译”,需要民间付出长期的和专门的努力.
---------------------------
“消解专制之毒,从摆脱专制对思维和语言的控制和侵染开始,从打破专制对思想文化解释权的垄断开始”!

相关帖子:
洗脑帝国-前苏联和中华共匪国

 

在linux vps上搭建基于ruby的静态网站程序-stasis

gem install stasis
git clone https://github.com/winton/stasis stasis-site

root@as3:~# cd stasis-site
root@as3:~/stasis-site# ls
bin  Gemfile  lib  LICENSE  Rakefile  README.md  site  spec  stasis.gemspec
root@as3:~/stasis-site# cd site
root@as3:~/stasis-site/site# ls
arrow.png      github.png       jquery-1.6.2.js  stasis.js.coffee
controller.rb  index.html.haml  stasis.css.scss  stasis.png
root@as3:~/stasis-site/site# gem install nokogiri -- --use-system-libraries
root@as3:~/stasis-site/site# bundle install
root@as3:~/stasis-site/site# stasis
root@as3:~/stasis-site/site# ls
arrow.png      github.png       jquery-1.6.2.js  stasis.css.scss   stasis.png
controller.rb  index.html.haml  public           stasis.js.coffee
(生成了public目录)
root@as3:~/stasis-site/site# cd public
root@as3:~/stasis-site/site/public# ls
arrow.png   index.html       stasis.css  stasis.png
github.png  jquery-1.6.2.js  stasis.js
(可见~/stasis-site/site/public/就是静态网站的根目录)
root@as3:~/stasis-site/site/public# nohup Rwebserver 3103 > /dev/null &
访问http://as3.brite.biz:3103/即可看到网站效果。

发贴方法:
root@as3:~/stasis-site/site/public# cd ..
root@as3:~/stasis-site/site# nano test1.html.haml


项目地址:https://github.com/winton/stasis

注意:此stasis不是这个stasis: https://github.com/magnars/stasis

一些jquery和css技巧

http://demo.marcofolio.net/

linux上面的sz,rz命令与ssh的配合

问题的提出:
    一般来说,linux服务器大多是通过ssh客户端来进行远程的登陆和管理的,使用ssh登陆linux主机以后,如何能够快速的和本地机器进行文件的交互呢,也就是上传和下载文件到服务器和本地;
   与ssh有关的两个命令可以提供很方便的操作:
      sz:将选定的文件发送(send)到本地机器
      rz:运行该命令会弹出一个文件选择窗口,从本地选择文件上传到服务器(receive)
当然,还可以设置一下目录了:
设置一下上传和下载的默认目录
options–>session options–>file transfer 下可以设置上传和下载的目录
剩下的你只要在用SecureCRT登陆linux终端的时候:
发送文件到客户端:sz filename
zmodem接收可以自行启动.
从客户端上传文件到linux服务端:
只要服务端执行 : rz
然后在 SecureCRT 里选文件发送,协议 zmodem
简单吧,如果你以前一直使用ssh,而又没有对外开放ftp服务,你就直接使用这种方式来传输你的文件。

pkg-config,PKG_CONFIG_PATH,LD_LIBRARY_PATH和ldconfig之间 的关系

1.什么是configure
      configure会根据传入的配置项目检查程序编译时所依赖的环境以及对程序编译安装进行配置,最终生成编译所需的Makefile文件供程序Make 读入使用进而调用相关编译程式(通常调用编译程序都是gcc)来编译最终的二进制程序。而configure脚本在检查相应依赖环境时(例:所依赖软件的 版本、相应库版本等),通常会通过pkg-config的工具来检测相应依赖环境。
      2.什么是pkg-config
      pkg-config用来检索系统中安装库文件的信息,典型的是用作库的编译和连接。一般来说,如果库的头文件不在/usr/include目录中,那么 在编译的时候需要用-I参数指定其路径。由于同一个库在不同系统上可能位于不同的目录下,用户安装库的时候也可以将库安装在不同的目录下,所以即使使用同 一个库,由于库的路径的不同,造成了用-I参数指定的头文件的路径和在连接时使用-L参数指定lib库的路径都可能不同,其结果就是造成了编译命令界面的 不统一。可能由于编译,连接的不一致,造成同一份程序从一台机器copy到另一台机器时就可能会出现问题。
      pkg-config 就是用来解决编译连接界面不统一问题的一个工具。基本思想:pkg-config是通过库提供的一个.pc文件获得库的各种必要信息的,包括版本信息、编 译和连接需要的参数等。需要的时候可以通过pkg-config提供的参数(–cflags, –libs),将所需信息提取出来供编译和连接使用。这样,不管库文件安装在哪,通过库对应的.pc文件就可以准确定位,可以使用相同的编译和连接命令, 使得编译和连接界面统一。它提供的主要功能有:
<1> 检查库的版本号。如果所需库的版本不满足要求,打印出错误信息,避免连接错误版本的库文件。
<2> 获得编译预处理参数,如宏定义,头文件的路径。
<3> 获得编译参数,如库及其依赖的其他库的位置,文件名及其他一些连接参数。
<4> 自动加入所依赖的其他库的设置。
      在默认情况下,每个支持 pkg-config 的库对应的.pc文件在安装后都位于安装目录中的lib/pkgconfig目录下.新软件一般都会安装.pc文件,没有可以自己创建,并且设置环境变量 PKG_CONFIG_PATH寻找.pc文件路径,否则怎么找得到呢。使用pkg-config工具提取库的编译和连接参数有两个基本的前提:
<1> 库本身在安装的时候必须提供一个相应的.pc文件。不这样做的库说明不支持pkg-config工具的使用。
<2> pkg-config必须知道要到哪里去寻找此.pc 文件。
      3.PKG_CONFIG_PATH.
      上边的第二个基本条件就是设置这个环境变量了。环境变量PKG_CONFIG_PATH是用来设置.pc文件的搜索路径的,pkg-config按照设置 路径的先后顺序进行搜索,直到找到指定的.pc 文件为止。这样,库的头文件的搜索路径的设置实际上就变成了对.pc文件搜索路径的设置。在安装完一个需要使用的库后,比如Glib,一是将相应的.pc 文件,如glib-2.0.pc拷贝到/usr/lib/pkgconfig目录下,二是通过设置环境变量PKG_CONFIG_PATH添加glib- 2.0.pc文件的搜索路径。
      这样设置之后,使用Glib库的其它程序或库在编译的时候pkg-config就知道首先要到/opt/gtk/lib/pkgconfig这个目录中去 寻找glib-2.0.pc了(GTK+和其它的依赖库的.pc文件也将拷贝到这里,也会首先到这里搜索它们对应的.pc文件)。之后,通过pkg- config就可以把其中库的编译和连接参数提取出来供程序在编译和连接时使用。另外还需要注意的是:环境变量的这种设置方式只对当前的终端窗口有效。如 果到了没有进行上述设置的终端窗口中,pkg-config将找不到新安装的glib-2.0.pc文件、从而可能使后面进行的安装(如Glib之后的 Atk的安装)无法进行。
  在我们采用的安装方案中,由于是使用环境变量对GTK+及其依赖库进行的设置,所以当系统重新启动、或者新开一个终端窗口之后,如果想使用新安装的GTK+库,需要如上面那样重新设置PKG_CONFIG_PATH和LD_LIBRARY_PATH环境变量。
  这种使用GTK+的方法,在使用之前多了一个对库进行设置的过程。虽然显得稍微繁琐了一些,但却是一种最安全的使用GTK+库的方式,不会对系统上已经存在的使用了GTK+库的程序(比如GNOME桌面)带来任何冲击。
操作实例:
 $pkg-config --modversion gtk+    (查看1.2.x版本)
 $pkg-config --modversion gtk+-2.0  (查看 2.x 版本)
$pkg-config --version (查看pkg-config的版本)
 $pkg-config --list-all |grep gtk (查看是否安装了gtk)
    我输入pkg-config --modversion gtk+-2.0,提示找不到xproto.pc文件,需要把包含该文件的目录放到PKG_CONFIG_PATH里,搜索了一下,该文件在/usr /share/pkgconfig下,于是更改环境变量成:
     export PKG_CONFIG=/usr/local/bin/pkg-config
     export PKG_CONFIG_PATH=/usr/share/pkgconfig:/usr/lib/pkgconfig
     记住:两个路径之间用 ':' 隔开,不是 ',', 或者 ';'。不让会出大问题。

实例2:linux 编译开源项目源码时,需要openssl的库,./configure提示说找不到openssl库包等,明明已经安装了openssl,:
解决方法:
 export PKG_CONFIG_PATH=/usr/local/ssl/lib/pkgconfig
ldconfig
 继续configure,则OK解决了。

from  http://blog.csdn.net/earbao/article/details/17502581
------------------------------------

linux下链接动态库路径相关的/etc/ld.so.conf,ldconfig, PKG_CONFIG_PATH


首先说下/etc/ld.so.conf:
这个文件记录了编译时使用的动态链接库的路径。
默认情况下,编译器只会使用/lib和/usr/lib这两个目录下的库文件
如果你安装了某些库,比如在安装gtk+-2.4.13时它会需要glib-2.0 >= 2.4.0,辛苦的安装好glib后
没有指定 --prefix=/usr 这样glib库就装到了/usr/local下,而又没有在/etc/ld.so.conf中添加/usr/local/lib
这个搜索路径,所以编译gtk+-2.4.13就会出错了
对于这种情况有两种方法解决:
一:在编译glib-2.4.x时,指定安装到/usr下,这样库文件就会放在/usr/lib中,gtk就不会找不到需要的库文件了
对于安装库文件来说,这是个好办法,这样也不用设置PKG_CONFIG_PATH了 (稍后说明)
二:将/usr/local/lib加入到/etc/ld.so.conf中,这样安装gtk时就会去搜索/usr/local/lib,同样可以找到需要的库
将/usr/local/lib加入到/etc/ld.so.conf也是必须的,这样以后安装东东到local下,就不会出现这样的问题了。
将自己可能存放库文件的路径都加入到/etc/ld.so.conf中是明智的选择 ^_^
添加方法也极其简单,将库文件的绝对路径直接写进去就OK了,一行一个。例如:
/usr/X11R6/lib
/usr/local/lib
/opt/lib
再来看看ldconfig是个什么东东吧 :
它是一个程序,通常它位于/sbin下,是root用户使用的东东。具体作用及用法可以man ldconfig查到
简单的说,它的作用就是将/etc/ld.so.conf列出的路径下的库文件 缓存到/etc/ld.so.cache 以供使用
因此当安装完一些库文件,(例如刚安装好glib),或者修改ld.so.conf增加新的库路径后,需要运行一下/sbin/ldconfig
使所有的库文件都被缓存到ld.so.cache中,如果没做,即使库文件明明就在/usr/lib下的,也是不会被使用的,结果
编译过程中抱错,缺少xxx库,去查看发现明明就在那放着,搞的想大骂computer蠢猪一个。 ^_^
我曾经编译KDE时就犯过这个错误,(它需要每编译好一个东东,都要运行一遍),所以
切记改动库文件后一定要运行一下ldconfig,在任何目录下运行都可以。

再来说说 PKG_CONFIG_PATH这个变量吧:
经常在论坛上看到有人问"为什么我已经安装了glib-2.4.x,但是编译gtk+-2.4.x 还是提示glib版本太低阿?
为什么我安装了glib-2.4.x,还是提示找不到阿?。。。。。。"都是这个变量搞的鬼。
先来看一个编译过程中出现的错误 (编译gtk+-2.4.13):
checking for pkg-config... /usr/bin/pkg-config
checking for glib-2.0 >= 2.4.0 atk >= 1.0.1 pango >= 1.4.0... Package glib-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `glib-2.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'glib-2.0' found
configure: error: Library requirements (glib-2.0 >= 2.4.0 atk >= 1.0.1 pango >= 1.4.0) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them.
[root@NEWLFS gtk+-2.4.13]#
很明显,上面这段说明,没有找到glib-2.4.x,并且提示应该将glib-2.0.pc加入到PKG_CONFIG_PATH下。
究竟这个pkg-config PKG_CONFIG_PATH glib-2.0.pc 是做什么的呢? let me tell you ^_^
先说说它是哪冒出来的,当安装了pkgconfig-x.x.x这个包后,就多出了pkg-config,它就是需要PKG_CONFIG_PATH的东东
pkgconfig-x.x.x又是做什么的? 来看一段说明:
The pkgconfig package contains tools for passing the include path and/or library paths to build tools during the make file execution.
pkg-config is a function that returns meta information for the specified library.
The default setting for PKG_CONFIG_PATH is /usr/lib/pkgconfig because of the prefix we use to install pkgconfig. You may add to PKG_CONFIG_PATH by exporting additional paths on your system where pkgconfig files are installed. Note that PKG_CONFIG_PATH is only needed when compiling packages, not during run-time.
我想看过这段说明后,你已经大概了解了它是做什么的吧。
其实pkg-config就是向configure程序提供系统信息的程序,比如软件的版本啦,库的版本啦,库的路径啦,等等
这些信息只是在编译其间使用。你可以 ls /usr/lib/pkgconfig 下,会看到许多的*.pc,用文本编辑器打开
会发现类似下面的信息:
prefix=/usr
exec_prefix=$
libdir=$/lib
includedir=$/include
glib_genmarshal=glib-genmarshal
gobject_query=gobject-query
glib_mkenums=glib-mkenums
Name: GLib
Description: C Utility Library
Version: 2.4.7
Libs: -L$ -lglib-2.0
Cflags: -I$/glib-2.0 -I$/glib-2.0/include
明白了吧,configure就是靠这些信息判断你的软件版本是否符合要求。并且得到这些东东所在的位置,要不去哪里找呀。
不用我说你也知道为什么会出现上面那些问题了吧。
解决的办法很简单,设定正确的PKG_CONFIG_PATH,假如将glib-2.x.x装到了/usr/local/下,那么glib-2.0.pc就会在
/usr/local/lib/pkgconfig下,将这个路径添加到PKG_CONFIG_PATH下就可以啦。并且确保configure找到的是正确的
glib-2.0.pc,就是将其他的lib/pkgconfig目录glib-2.0.pc干掉就是啦。(如果有的话 ^-^)
设定好后可以加入到~/.bashrc中,例如:
PKG_CONFIG_PATH=/opt/kde-3.3.0/lib/pkgconfig:/usr/lib/pkgconfig:/usr/local/pkgconfig:
/usr/X11R6/lib/pkgconfig
[root@NEWLFS ~]#echo $PKG_CONFIG_PATH
/opt/kde-3.3.0/lib/pkgconfig:/usr/lib/pkgconfig:/usr/local/pkgconfig:/usr/X11R6/lib/pkgconfig
从上面可以看出,安装库文件时,指定安装到/usr,是很有好处的,无论是/etc/ld.so.conf还是PKG_CONFIG_PATH
默认都会去搜索/usr/lib的,可以省下许多麻烦,不过从源码包管理上来说,都装在/usr下
管理是个问题,不如装在/usr/local下方便管理
其实只要设置好ld.so.conf,PKG_CONFIG_PATH路径后,就OK啦.
--------------------------------------

pkg-config与LD_LIBRARY_PATH


最近遇到的几个问题, 都和LD_LIBRARY_PATH有关, 想整理一篇心得, 但发现一片比较好的介绍文章, 就不再赘笔了。

一、编译和连接

一般来说,如果库的头文件不在 /usr/include 目录中,那么在编译的时候需要用 -I 参数指定其路径。由于同一个库在不同系统上可能位于不同的目录下,用户安装库的时候也可以将库安装在不同的目录下,所以即使使用同一个库,由于库的路径的 不同,造成了用 -I 参数指定的头文件的路径也可能不同,其结果就是造成了编译命令界面的不统一。如果使用 -L 参数,也会造成连接界面的不统一。编译和连接界面不统一会为库的使用带来麻烦。
为了解决编译和连接界面不统一的问题,人们找到了一些解决办法。其基本思想就是:事先把库的位置信息等保存起来,需要的时候再通过特定的工具将其中有用的 信息提取出来供编译和连接使用。这样,就可以做到编译和连接界面的一致性。其中,目前最为常用的库信息提取工具就是下面介绍的 pkg-config。
pkg-config 是通过库提供的一个 .pc 文件获得库的各种必要信息的,包括版本信息、编译和连接需要的参数等。这些信息可以通过 pkg-config 提供的参数单独提取出来直接供编译器和连接器使用。
  1.   The pkgconfig package contains tools for passing the include path and/or library
  2. paths to build tools during the make file execution.
  3.  
  4.   pkg-config is a function that returns meta information for the specified library.
  5.  
  6.   The default setting for PKG_CONFIG_PATH is /usr/lib/pkgconfig because of the prefix
  7. we use to install pkgconfig. You may add to PKG_CONFIG_PATH by exporting additional
  8. paths on your system where pkgconfig files are installed. Note that PKG_CONFIG_PATH is
  9. only needed when compiling packages, not during run-time.
在默认情况下,每个支持 pkg-config 的库对应的 .pc 文件在安装后都位于安装目录中的 lib/pkgconfig 目录下。例如,我们在上面已经将 Glib 安装在 /opt/gtk 目录下了,那么这个 Glib 库对应的 .pc 文件是 /opt/gtk/lib/pkgconfig 目录下一个叫 glib-2.0.pc 的文件:
  1. prefix=/opt/gtk/
  2. exec_prefix=${prefix}
  3. libdir=${exec_prefix}/lib
  4. includedir=${prefix}/include
  5.  
  6. glib_genmarshal=glib-genmarshal
  7. gobject_query=gobject-query
  8. glib_mkenums=glib-mkenums
  9.  
  10. Name: GLib
  11. Description: C Utility Library
  12. Version: 2.12.13
  13. Libs: -L${libdir} -lglib-2.0
  14. Cflags: -I${includedir}/glib-2.0 -I${libdir}/glib-2.0/include
使用 pkg-config 的 –cflags 参数可以给出在编译时所需要的选项,而 –libs 参数可以给出连接时的选项。例如,假设一个 sample.c 的程序用到了 Glib 库,就可以这样编译:
  1. $ gcc -c `pkg-config --cflags glib-2.0` sample.c
然后这样连接:
  1. $ gcc sample.o -o sample `pkg-config --libs glib-2.0`
或者上面两步也可以合并为以下一步:
  1. $ gcc sample.c -o sample `pkg-config --cflags --libs glib-2.0`
可以看到:由于使用了 pkg-config 工具来获得库的选项,所以不论库安装在什么目录下,都可以使用相同的编译和连接命令,带来了编译和连接界面的统一。
使用 pkg-config 工具提取库的编译和连接参数有两个基本的前提:
库本身在安装的时候必须提供一个相应的 .pc 文件。不这样做的库说明不支持 pkg-config 工具的使用。
pkg-config 必须知道要到哪里去寻找此 .pc 文件。
GTK+ 及其依赖库支持使用 pkg-config 工具,所以剩下的问题就是如何告诉 pkg-config 到哪里去寻找库对应的 .pc 文件,这也是通过设置搜索路径来解决的。
对于支持 pkg-config 工具的 GTK+ 及其依赖库来说,库的头文件的搜索路径的设置变成了对 .pc 文件搜索路径的设置。.pc 文件的搜索路径是通过环境变量 PKG_CONFIG_PATH 来设置的,pkg-config 将按照设置路径的先后顺序进行搜索,直到找到指定的 .pc 文件为止。
安装完 Glib 后,在 bash 中应该进行如下设置:
  1. $ export PKG_CONFIG_PATH=/opt/gtk/lib/pkgconfig:$PKG_CONFIG_PATH
可以执行下面的命令检查是否 /opt/gtk/lib/pkgconfig 路径已经设置在 PKG_CONFIG_PATH 环境变量中:
  1. $ echo $PKG_CONFIG_PATH
这样设置之后,使用 Glib 库的其它程序或库在编译的时候 pkg-config 就知道首先要到 /opt/gtk/lib/pkgconfig 这个目录中去寻找 glib-2.0.pc 了(GTK+ 和其它的依赖库的 .pc 文件也将拷贝到这里,也会首先到这里搜索它们对应的 .pc 文件)。之后,通过 pkg-config 就可以把其中库的编译和连接参数提取出来供程序在编译和连接时使用。
另外还需要注意的是:环境变量的设置只对当前的终端窗口有效。如果到了没有进行上述设置的终端窗口中,pkg-config 将找不到新安装的 glib-2.0.pc 文件、从而可能使后面进行的安装(如 Glib 之后的 Atk 的安装)无法进行。
在我们采用的安装方案中,由于是使用环境变量对 GTK+ 及其依赖库进行的设置,所以当系统重新启动、或者新开一个终端窗口之后,如果想使用新安装的 GTK+ 库,需要如上面那样重新设置 PKG_CONFIG_PATH 和 LD_LIBRARY_PATH 环境变量。
这种使用 GTK+ 的方法,在使用之前多了一个对库进行设置的过程。虽然显得稍微繁琐了一些,但却是一种最安全的使用 GTK+ 库的方式,不会对系统上已经存在的使用了 GTK+ 库的程序(比如 GNOME 桌面)带来任何冲击。
为了使库的设置变得简单一些,可以把下面的这两句设置保存到一个文件中(比如 set_gtk-2.10 文件):
  1. export PKG_CONFIG_PATH=/opt/gtk/lib/pkgconfig:$PKG_CONFIG_PATH
  2. export LD_LIBRARY_PATH=/opt/gtk/lib:$LD_LIBRARY_PATH
之后,就可以用下面的方法进行库的设置了(其中的 source 命令也可以用 . 代替):
  1. $ source set_gtk-2.10
只有在用新版的 GTK+ 库开发应用程序、或者运行使用了新版 GTK+ 库的程序的时候,才有必要进行上述设置。
如果想避免使用 GTK+ 库之前上述设置的麻烦,可以把上面两个环境变量的设置在系统的配置文件中(如 /etc/profile)或者自己的用户配置文件中(如 ~/.bash_profile) ;库的搜索路径也可以设置在 /etc/ld.so.conf 文件中,等等。这种设置在系统启动时会生效,从而会导致使用 GTK+ 的程序使用新版的 GTK+ 运行库,这有可能会带来一些问题。当然,如果你发现用新版的 GTK+ 代替旧版没有什么问题的话,使用这种设置方式是比较方便的。加入到~/.bashrc中,例如:
  1. PKG_CONFIG_PATH=/opt/gtk/lib/pkgconfig
重启之后:
  1. [root@localhost ~]# echo $PKG_CONFIG_PATH
  2. /opt/gtk/lib/pkgconfig

二、运行时

库文件在连接(静态库和共享库)和运行(仅限于使用共享库的程序)时被使用,其搜索路径是在系统中进行设置的。一般 Linux 系统把 /lib 和 /usr/lib 两个目录作为默认的库搜索路径,所以使用这两个目录中的库时不需要进行设置搜索路径即可直接使用。对于处于默认库搜索路径之外的库,需要将库的位置添加到 库的搜索路径之中。设置库文件的搜索路径有下列两种方式,可任选其一使用:
  1. 在环境变量 LD_LIBRARY_PATH 中指明库的搜索路径。
  2. 在 /etc/ld.so.conf 文件中添加库的搜索路径。
将自己可能存放库文件的路径都加入到/etc/ld.so.conf中是明智的选择 ^_^
添加方法也极其简单,将库文件的绝对路径直接写进去就OK了,一行一个。例如:
  1. /usr/X11R6/lib
  2. /usr/local/lib
  3. /opt/lib
需要注意的是:第二种搜索路径的设置方式对于程序连接时的库(包括共享库和静态库)的定位已经足够了,但是对于使用了共享库的程序的执行还是不够的。这是 因为为了加快程序执行时对共享库的定位速度,避免使用搜索路径查找共享库的低效率,所以是直接读取库列表文件 /etc/ld.so.cache 从中进行搜索的。/etc/ld.so.cache 是一个非文本的数据文件,不能直接编辑,它是根据 /etc/ld.so.conf 中设置的搜索路径由 /sbin/ldconfig 命令将这些搜索路径下的共享库文件集中在一起而生成的(ldconfig 命令要以 root 权限执行)。因此,为了保证程序执行时对库的定位,在 /etc/ld.so.conf 中进行了库搜索路径的设置之后,还必须要运行 /sbin/ldconfig 命令更新 /etc/ld.so.cache 文件之后才可以。ldconfig ,简单的说,它的作用就是将/etc/ld.so.conf列出的路径下的库文件 缓存到/etc/ld.so.cache 以供使用。因此当安装完一些库文件,(例如刚安装好glib),或者修改ld.so.conf增加新的库路径后,需要运行一下 /sbin/ldco .cache中,如果没做,即使库文件明明就在/usr/lib下的,也是不会被使用 的,结果编译 现明明就在那放着,搞的想大骂computer蠢猪一个。 ^_^
在程序连接时,对于库文件(静态库和共享库)的搜索路径,除了上面的设置方式 。因为用 -L 设置的路径将被优先搜索,所以在连接的时候通常都会以这种方式直接指定
前面已经说明过了,库搜索路径的设置有两种方式:在环境变量 LD_LIBRARY_PA 文件中设置。其中,第二种设置方式需要 root 权限,以改变 /etc/ld.so.conf 文件并执 系统重新启动后,所有的基于 GTK2 的程序在运行时都将使用新安装的 GTK+ 库。不幸的 会给应用程序带来兼容性的问题,造成某些程序运行不正常。为了避免出现上面的这些情 中对于库的搜索路径的设置将采用第一种方式进行。这种设置方式不需要 root 权限,设
  1. $ export LD_LIBRARY_PATH=/opt/gtk/lib:$LD_LIBRARY_PATH
可以用下面的命令查看 LD_LIBRAY_PATH 的设置内容:
  1. $ echo $LD_LIBRARY_PATH
至此,库的两种设置就完成了.

from http://blog.csdn.net/stormbjm/article/details/11086215
-----------------------------

pkg-config的安装配置及其作用


最近在安装OpenCV1.0的时候需要用到pkg-config。
(一)、     首先到网上下载pkgconfig,地址:http://download.chinaunix.net/download/0009000/8174.shtml,我下的版本是pkgconfig-0.17.2.tar.bz2 ,在linux系统下解压以后,cd进入解压文件夹,使用命令gedit INSTALL,打开安装说明文件,从中可以看到安装的5个步骤:
1、运行配置文件进行系统配置 : ./configure
2、编译pkgconfig : make
3、安装包自检测 : make check
4、安装 :make install
5、卸载的方法
其中我们只需要执行前4步。至此,pkgconfig安装完成。

(二)、pkgconfig的作用以及配置
(转自:http://www.chenjunlu.com/2011/03/understanding-pkg-config-tool/
pkg-config提供了下面几个功能:
  1. 检查库的版本号。如果所需要的库的版本不满足要求,它会打印出错误信息,避免链接错误版本的库文件。
  2. 获得编译预处理参数,如宏定义,头文件的位置。
  3. 获得链接参数,如库及依赖的其它库的位置,文件名及其它一些连接参数。
  4. 自动加入所依赖的其它库的设置。
事实上,为了让pkg-config可以得到这些信息,要求库的提供者,提供一个.pc文件。比如gtk+-2.0的pc文件内容如下:
prefix=/usr
exec_prefix=/usr
libdir=/usr/lib
includedir=/usr/include
target=x11
gtk_binary_version=2.4.0
gtk_host=i386-redhat-linux-gnu
Name: GTK+
Description: GIMP Tool Kit (${target} target)
Version: 2.6.7
Requires: gdk-${target}-2.0 atk
Libs: -L${libdir} -lgtk-${target}-2.0
Cflags: -I${includedir}/gtk-2.0
这个文件一般放在 /usr/lib/pkgconfig/ 或者 /usr/local/lib/pkgconfig/ 里,当然也可以放在其它任何地方,如像 X11 相关的pc文件是放在 /usr/X11R6/lib/pkgconfig 下的。为了让pkgconfig可以找到你的pc文件,你要把pc文件所在的路径,设置在环境变量 PKG_CONFIG_PATH 里。
使用 pkg-config 的 –cflags 参数可以给出在编译时所需要的选项,而 –libs 参数可以给出连接时的选项。例如,假设一个 sample.c 的程序用到了 Glib 库,就可以这样编译:
$ gcc -c `pkg-config –cflags glib-2.0` sample.c
然后这样连接:
$ gcc sample.o -o sample `pkg-config –libs glib-2.0`
或者上面两步也可以合并为以下一步:
$ gcc sample.c -o sample `pkg-config –cflags –libs glib-2.0`
可以看到:由于使用了 pkg-config 工具来获得库的选项,所以不论库安装在什么目录下,都可以使用相同的编译和连接命令,带来了编译和连接界面的统一。
使用 pkg-config 工具提取库的编译和连接参数有两个基本的前提:
  • 库本身在安装的时候必须提供一个相应的 .pc 文件(不这样做的库说明不支持 pkg-config 工具的使用)。
  • pkg-config 必须知道要到哪里去寻找此 .pc 文件。
GTK+ 及其依赖库支持使用 pkg-config 工具,所以剩下的问题就是如何告诉 pkg-config 到哪里去寻找库对应的 .pc 文件,这也是通过设置搜索路径来解决的。
对于支持 pkg-config 工具的 GTK+ 及其依赖库来说,库的头文件的搜索路径的设置变成了对 .pc 文件搜索路径的设置。.pc 文件的搜索路径是通过环境变量 PKG_CONFIG_PATH 来设置的,pkg-config 将按照设置路径的先后顺序进行搜索,直到找到指定的 .pc 文件为止。
安装完 Glib 后,在 bash 中应该进行如下设置:
$ export PKG_CONFIG_PATH=/opt/gtk/lib/pkgconfig:$PKG_CONFIG_PATH
可以执行下面的命令检查是否 /opt/gtk/lib/pkgconfig 路径已经设置在 PKG_CONFIG_PATH 环境变量中:
$ echo $PKG_CONFIG_PATH
这样设置之后,使用 glib 库的其它程序或库在编译的时候 pkg-config 就知道首先要到 /opt/gtk/lib/pkgconfig 这个目录中去寻找 glib-2.0.pc 了(GTK+ 和其它的依赖库的 .pc 文件也将拷贝到这里,也会首先到这里搜索它们对应的 .pc 文件)。之后,通过 pkg-config 就可以把其中库的编译和连接参数提取出来供程序在编译和连接时使用。
另外还需要注意的是:环境变量的设置只对当前的终端窗口有效。如果到了没有进行上述设置的终端窗口中,pkg-config 将找不到新安装的 glib-2.0.pc 文件、从而可能使后面进行的安装(如 glib 之后的 Atk 的安装)无法进行。
在我们采用的安装方案中,由于是使用环境变量对 GTK+ 及其依赖库进行的设置,所以当系统重新启动、或者新开一个终端窗口之后,如果想使用新安装的 GTK+ 库,需要如上面那样重新设置 PKG_CONFIG_PATH 和 LD_LIBRARY_PATH 环境变量。
这种使用 GTK+ 的方法,在使用之前多了一个对库进行设置的过程。虽然显得稍微繁琐了一些,但却是一种最安全的使用 GTK+ 库的方式,不会对系统上已经存在的使用了 GTK+ 库的程序(比如 GNOME 桌面)带来任何冲击。
为了使库的设置变得简单一些,可以把下面的这两句设置保存到一个文件中(比如 set_gtk-2.10 文件):
export PKG_CONFIG_PATH=/opt/gtk/lib/pkgconfig:$PKG_CONFIG_PATH
export LD_LIBRARY_PATH=/opt/gtk/lib:$LD_LIBRARY_PATH
之后,就可以用下面的方法进行库的设置了(其中的 source 命令也可以用 . 代替):
$ source set_gtk-2.10
只有在用新版的 GTK+ 库开发应用程序、或者运行使用了新版 GTK+ 库的程序的时候,才有必要进行上述设置。
如果想避免使用 GTK+ 库之前上述设置的麻烦,可以把上面两个环境变量的设置在系统的配置文件中(如 /etc/profile)或者自己的用户配置文件中(如 ~/.bash_profile) ;库的搜索路径也可以设置在 /etc/ld.so.conf 文件中,等等。这种设置在系统启动时会生效,从而会导致使用 GTK+ 的程序使用新版的 GTK+ 运行库,这有可能会带来一些问题。当然,如果你发现用新版的 GTK+ 代替旧版没有什么问题的话,使用这种设置方式是比较方便的。
库文件在连接(静态库和共享库)和运行(仅限于使用共享库的程序)时被使用,其搜索路径是在系统中进行设置的。一般 Linux 系统 把 /lib 和 /usr/lib 两个目录作为默认的库搜索路径,所以使用这两个目录中的库时不需要进行设置搜索路径即可直接使用。对于处于默认库搜 索路径之外的库,需要将库的位置添加到库的搜索路径之中。设置库文件的搜索路径有下列两种方式,可任选其一使用:
  1. 在环境变量 LD_LIBRARY_PATH 中指明库的搜索路径。
  2. 在  /etc/ld.so.conf  文件中添加库的搜索路径。
将自己可能存放库文件的路径都加入到 /etc/ld.so.conf 中是明智的选择。( ^_^)
添加方法也极其简单,将库文件的绝对路径直接写进去就OK了,一行一个。例如:
/usr/X11R6/lib
/usr/local/lib
/opt/lib
需要注意的是:第二种搜索路径的设置方式对于程序连接时的库(包括共享库和静态库)的定位已经足够了,但是对于使用了共享库的程序的执行还是不够 的。这是 因为为了加快程序执行时对共享库的定位速度,避免使用搜索路径查找共享库的低效率,所以是直接读取库列表文件 /etc /ld.so.cache 从中进行搜索的。/etc/ld.so.cache 是一个非文本的数据文件,不能直接编辑,它是根据 /etc /ld.so.conf 中设置的搜索路径由 /sbin/ldconfig 命令将这些搜索路径下的共享库文件集中在一起而生成的 (ldconfig 命令要以 root 权限执行)。因此,为了保证程序执行时对库的定位,在 /etc/ld.so.conf 中进行了库搜索路径的 设置之后,还必须要运行 /sbin/ldconfig 命令更新 /etc/ld.so.cache 文件之后才可以。ldconfig ,简单的说,它的作用就是将 /etc/ld.so.conf 列出的路径下的库文件缓存到/etc/ld.so.cache以供使用。因此当安装完一些库文件(例如刚安装好 glib 或者修改 ld.so.conf 增加新的库路径)后,需要运行一下 /sbin/ldconfig 使所有的库文件都被缓存到 ld.so.cache 中,如果没做,即使库文件明明就在 /usr/lib 下的,也是不会被使用的,结果编译过程中抱错,缺少xxx库,去查看发现明明就在那放着,搞的想大骂 computer 蠢猪一个。 (^_^)
在程序连接时,对于库文件(静态库和共享库)的搜索路径,除了上面的设置方式之外,还可以通过 -L 参数显式指定。因为用 -L 设置的路径将被优先搜索,所以在连接的时候通常都会以这种方式直接指定要连接的库的路径。
前面已经说明过了,库搜索路径的设置有两种方式:在环境变量 LD_LIBRARY_PATH 中设置以及在 /etc/ld.so.conf 文 件中设置。其中,第二种设置方式需要 root 权限,以改变 /etc/ld.so.conf 文件并执行 /sbin/ldconfig 命令。而且,当系统重新启动后,所有的基 于 GTK2 的程序在运行时都将使用新安装的 GTK+ 库。不幸的是,由于 GTK+ 版本的改变,这有时会给应用程序带来兼容性的问题,造成某些程 序运行不正常。为了避免出现上面的这些情况,在 GTK+ 及其依赖库的安装过程中对于库的搜索路径的设置将采用第一种方式进行。这种设置方式不需 要 root 权限,设置也简单:
$ export LD_LIBRARY_PATH=/opt/gtk/lib:$LD_LIBRARY_PATH
可以用下面的命令查看 LD_LIBRAY_PATH 的设置内容:
$ echo $LD_LIBRARY_PATH
最后,我来总结一下,PKG_CONFIG_PATH 主要指明.pc文件的所在路径,这样 pkg-config 工具就可以根据.pc文件的内容动态生成编译和连接选项,比如 Cflags (编译用)和 Libs (连接用),如果使用的是动态链接库,那么程序在连接和运行时,一般 Linux 系统把 /lib 和 /usr/lib 两个目录作为默认的库搜索路 径,对于处于默认库搜索路径之外的库,系统管理员可以设置 LD_LIBRARY_PATH 环境变量或在 /etc/ld.so.conf 文件中添加库的搜索路径。值得说明的是,使用 gcc 连接时的选项,如果不用 pkg-config 工具,需要显示的声明连接的动态链接库名。使用 gcc 的同学可以查看下面的注意事项。
Linux 系统中,为了让动态链接库能被系统中其它程序共享,其名字应符合 lib*.so.* 这种格式。如果某个动态链接库不符合此格式,则 Linux 的动态链接库自动装入程序(ld)将搜索不到此链接库,其它程序也无法共享之。格式中,第一 个*通常表示为简写的库名,第二个*通常表示为该库的版本号。如在我的系统中,基本C动态链接库的名字为 libc.so.6,线程 pthread 动态链接库的名字为 libpthread.so.0 等等。如果没有指定版本号,比如 libmy.so ,这也是符合要求的格式。
gcc 命令几个重要选项:
  • -shared 该选项指定生成动态连接库(让连接器生成T类型的导出符号表,有时候也生成弱连接W类型的导出符号,不用该标志外部程序无法连接。相当于一个可执行文件)。
  • -fPIC:表示编译为位置独立的代码,不用此选项的话编译后的代码是位置相关的所以动态载入时是通过代码拷贝的方式来满足不同进程的需要,而不能达到真正代码段共享的目的。
  • -L.:表示要连接的库在当前目录中。
  • -lmy:编译器查找动态连接库时有隐含的命名规则,即在给出的名字前面加上lib,后面加上.so来确定库的名称(libmy.so)。
当然如果有 root 权限的话,可以修改 /etc/ld.so.conf 文件,然后调用 /sbin/ldconfig 来达到同样的目的,不过如果没有 root 权限,那么只能采用输出 LD_LIBRARY_PATH 的方法了.
-----------------------------
http://blog.csdn.net/lgzdlmu/article/category/938203

Saturday 28 June 2014

LINUX下的C++编译器-GCC


Linux系统下的gcc(GNU C Compiler)是GNU推出的功能强大、性能优越的多平台编译器,是GNU的代表作品之一。gcc是可以在多种硬体平台上编译出可执行程序的超级编译器,其执行效率与一般的编译器相比平均效率要高20%~30%。
gcc 编译器能将C、C++语言源程序、汇程式化序和目标程序编译、连接成可执行文 件,如果没有给出可执行文件的名字,gcc将生成一个名为a.out的文件。 在Linux系统中,可执行文件没有统一的后缀,系统从文件的属性来区分可执行文件和不可执行文件。而gcc则通过后缀来区别输入文件的类别,下面我们来 介绍gcc所遵循的部分约定规则。
.c为后缀的文件:  C语言源代码文件;
.a为后缀的文件:  是由目标文件构成的档案库文件;
.C,.cc或.cxx 为后缀的文件:    是C++源代码文件;
.h为后缀的文件:  是程序所包含的头文件;
.i 为后缀的文件: 是已经预处理过的C源代码文件;
.ii为后缀的文件: 是已经预处理过的C++源代码文件;
.m为后缀的文件:  是Objective-C源代码文件;
.o为后缀的文件:  是编译后的目标文件;
.s为后缀的文件:  是汇编语言源代码文件;
.S为后缀的文件:  是经过预编译的汇编语言源代码文件。
gcc的执行过程
虽 然我们称gcc是C语言的编译器,但使用gcc由C语言源代码文件生成可执行文件的过程不仅仅是编译的过程,而是要经历四个相互关联的步骤∶预处理(也称 预编译,Preprocessing)、编译(Compilation)、汇编(Assembly)和连接(Linking)。
命 令 gcc首先调用cpp进行预处理,在预处理过程中,对源代码文件中的文件包含(include)、预编译语句(如宏定义define等)进行分析。接着调 用cc1进行编译,这个阶段根据输入文件生成以.o为后缀的目标文件。汇编过程是针对汇编语言的步骤,调用as进行工作,一般来讲,.S为后缀的汇编语言 源代码文件和汇编、.s为后缀的汇编语言文件经过预编译和汇编之后都生成以.o为后缀的目标文件。当所有的目标文件都生成之后,gcc就调用ld来完成最 后的关键性工作,这个阶段就是连接。在连接阶段,所有的目标文件被安排在可执行程序中的恰当的位置,同时,该程序所调用到的库函数也从各自所在的档案库中 连到合适的地方。
gcc的基本用法和选项
在使用gcc编译器的时候,我们必须给出一系列必要的调用参数和文件名称。gcc编译器的调用参数大约有100多个,其中多数参数我们可能根本就用不到,这里只介绍其中最基本、最常用的参数。
gcc最基本的用法是∶gcc [options] [filenames]
其中options就是编译器所需要的参数,filenames给出相关的文件名称。其中[options]的值可以为下列值:
-c,只编译,不连接成为可执行文件,编译器只是由输入的.c等源代码文件生成.o为后缀的目标文件,通常用于编译不包含主程序的子程序文件。
-o output_filename,确定输出文件的名称为output_filename,同时这个名称不能和源文件同名。如果不给出这个选项,gcc就给出预设的可执行文件a.out。
-g,产生符号调试工具(GNU的gdb)所必要的符号资讯,要想对源代码进行调试,我们就必须加入这个选项。
-O,对程序进行优化编译、连接,采用这个选项,整个源代码会在编译、连接过程中进行优化处理,这样产生的可执行文件的执行效率可以提高,但是,编译、连接的速度就相应地要慢一些。
-O2,比-O更好的优化编译、连接,当然整个编译、连接过程会更慢。
-Idirname,将dirname所指出的目录加入到程序头文件目录列表中,是在预编译过程中使用的参数。C程序中的头文件包含两种情况∶
A)#include
B)#include “myinc.h”
其 中,A类使用尖括号(< >),B类使用双引号(“ ”)。对于A类,预处理程序cpp在系统预设包含文件目录(如/usr/include)中搜寻相应的文件,而对于B类,cpp在当前目录中搜寻头文件, 这个选项的作用是告诉cpp,如果在当前目录中没有找到需要的文件,就到指定的dirname目录中去寻找。在程序设计中,如果我们需要的这种包含文件分 别分布在不同的目录中,就需要逐个使用-I选项给出搜索路径。
-Ldirname, 将dirname所指出的目录加入到程序函数档案 库文件的目录列表中,是在连接过程中使用的参数。在预设状态下,连接程序ld在系统的预设路径中(如/usr/lib)寻找所需要的档案库文件,这个选项 告诉连接程序,首先到-L指定的目录中去寻找,然后到系统预设路径中寻找,如果函数库存放在多个目录下,就需要依次使用这个选项,给出相应的存放目录。
-lname,在连接时,装载名字为“libname.a”的函数库,该函数库位于系统预设的目录或者由-L选项确定的目录下。例如,-lm表示连接名为“libm.a”的数学函数库。
上面我们简要介绍了gcc编译器最常用的功能和主要参数选项,更为详尽的资料可以参看Linux系统的联机帮助。
为了更加详细的说明GCC参数极其相关的使用方法,我们再换一种方式来说明,以下为自问自答的十个问题:
1、gcc包含的c/c++编译器
gcc、cc、c++、g++;gcc和cc是一样的,c++和g++是一样的,一般c程序就用gcc编译,c++程序就用g++编译
2、gcc的基本用法
gcc test.c这样将编译出一个名为a.out的程序,gcc test.c -o test这样将编译出一个名为test的程序,-o参数用来指定生成程序的名字。
3、为什么会出现undefined reference to 'xxxxx'错误?
首 先这是链接错误,不是编译错误,也就是说如果只有这个错误,说明你的程序源码本身没有问题,是你用编译器编译时参数用得不对,你没有指定链接程序 要用到得库,比如你的程序里用到了一些数学函数,那么你就要在编译参数里指定程序要链接数学库,方法是在编译命令行里加入-lm
4、-l参数和-L参数
-l参数就是用来指定程序要链接的库,-l参数紧接着就是库名,那么库名跟真正的库文件名有什么关系呢?就拿数学库来说,他的库名是m,他的库文件名是libm.so,很容易看出,把库文件名的头lib和尾.so去掉就是库名了。
好 了现在我们知道怎么得到库名,当我们自已要用到一个第三方提供的库名字libtest.so,那么我们只要把libtest.so拷贝到 /usr/lib里,编译时加上-ltest参数,我们就能用上libtest.so库了(当然要用libtest.so库里的函数,我们还需要与 libtest.so配套的头文件)。
放 在/lib和/usr/lib和/usr/local/lib里的库直接用-l参数就能链接了,但如果库文件没放在这三个目录里,而是放在其他目录里,这 时我们只用-l参数的话,链接还是会出错,出错信息大概是:“/usr/bin/ld: cannot find -lxxx”,也就是链接程序ld在那3个目录里找不到libxxx.so,这时另外一个参数-L就派上用场了,比如常用的X11的库,它在 /usr/X11R6/lib目录下,我们编译时就要用-L/usr/X11R6/lib -lX11参数,-L参数跟着的是库文件所在的目录名。再比如我们把libtest.so放在/aaa/bbb/ccc目录下,那链接参数就是- L/aaa/bbb/ccc –ltest。
另 外,大部分libxxxx.so只是一个链接,以RH9为例,比如libm.so它链接到/lib/libm.so.x,/lib/libm.so.6又 链接到/lib/libm-2.3.2.so,如果没有这样的链接,还是会出错,因为ld只会找libxxxx.so,所以如果你要用到xxxx
库,而只有libxxxx.so.x或者libxxxx-x.x.x.so,做一个链接就可以了
ln -s libxxxx-x.x.x.so libxxxx.so
手 工来写链接参数总是很麻烦的,还好很多库开发包提供了生成链接参数的程序,名字一般叫xxxx-config,一般放在/usr/bin目录下,比如 gtk1.2的链接参数生成程序是gtk-config,执行gtk-config --libs就能得到以下输出"-L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic
-lgmodule -lglib -ldl -lXi -lXext -lX11 -lm",这就是编译一个gtk1.2程序所需的gtk链接参数,xxx-config除了--libs参数外还有一个参数是--cflags用来生成头文件包含目录的,也就是-I参数,在下面我们将会讲到。你可以试试执行gtk-config --libs --cflags,看看输出结果。
现 在的问题就是怎样用这些输出结果了,最笨的方法就是复制粘贴或者照抄,聪明的办法是在编译命令行里加入这个`xxxx-config --libs --cflags`,比如编译一个gtk程序:gcc gtktest.c `gtk-config --libs --cflags`这样
就差不多了。注意`不是单引号,而是1键左边那个键。
除 了xxx-config以外,现在新的开发包一般都用pkg-config来生成链接参数,使用方法跟xxx-config类似,但xxx-config 是针对特定的开发包,但pkg-config包含很多开发包的链接参数的生成,用pkg-config --list-all命令可以列出所支持的所有开发包,pkg-config的用法就是pkg -config pagName --libs --cflags,其中pagName是包名,是pkg-config--list-all里列出名单中的一个,比如gtk1.2的名字就是gtk+, pkg-config gtk+ --libs --cflags的作用跟gtk-config --libs --cflags是一样的。比如:
gcc gtktest.c `pkg-config gtk+ --libs --cflags`
5、-include和-I参数
-include用 来包含头文件,但一般情况下包含头文件都在源码里用#include xxxxxx实现,-include参数很少用。-I参数是用来指定头文件目录,/usr/include目录一般是不用指定的,gcc知道去那里找,但 是如果头文件不在/usr/include里我们就要用-I参数指定了,比如头文件放在/myinclude目录里,那编译命令行就要加上- I/myinclude参数了,如果不加你会得到一个"xxxx.h: No such file or directory"的错误。-I参数可以用相对路径,比如头文件在当前目录,可以用-I.来指定。上面我们提到的--cflags参数就是用来生成-I 参数的
6、-O参数
这是一个程序优化参数,一般用-O2就是,用来优化程序用的,比如gcc test.c -O2,优化得到的程序比没优化的要小,执行速度可能也有所提高
7、-shared参数
编译动态库时要用到,比如gcc -shared test.c -o libtest.so
8、几个相关的环境变量
PKG_CONFIG_PATH:用来指定pkg-config用到的pc文件的路径,默认是/usr/lib/pkgconfig,pc文件是文本文件,扩展名是.pc,里面定义开发包的安装路径,Libs参数和Cflags参数等等。
CC:用来指定c编译器
CXX:用来指定cxx编译器
LIBS:跟上面的--libs作用差不多
CFLAGS:跟上面的--cflags作用差不多
CC,CXX,LIBS,CFLAGS手动编译时一般用不上,在做configure时有时用到,一般情况下不用管。
环境变量设定方法:export ENV_NAME=xxxxxxxxxxxxxxxxx
9、关于交叉编译
交 叉编译通俗地讲就是在一种平台上编译出能运行在体系结构不同的另一种平台上,比如在我们地PC平台(X86 CPU)上编译出能运行在sparc CPU平台上的程序,编译得到的程序在X86 CPU平台上是不能运行的,必须放到sparc CPU平台上才能运行。当然两个平台用的都是linux,这种方法在异平台移植和嵌入式开发时用得非常普遍。相对与交叉编译,我们平常做的编译就叫本地编 译,也就是在当前平台编译,编译得到的程序也是在本地执行。用来编译这种程序的编译器就叫交叉编译器,相对来说,用来做本地编译的就叫本地编译器,一般用 的都是gcc,但这种gcc跟本地的gcc编译器是不一样的,需要在编译gcc时用特定的configure参数才能得到支持交叉编译的gcc。为了不跟 本地编译器混淆,交叉编译器的名字一般都有前缀,比如sparc-xxxx-linux-gnu-gcc,sparc-xxxx-linux-gnu- g++ 等等。
10、交叉编译器的使用方法
使用方法跟本地的gcc差不多,但有一点特殊的是:必须用-L和-I参数指定编译器用spar c系统的库和头文件,不能用本地(X86)的库(头文件有时可以用本地的)
例子:
sparc-xxxx-linux-gnu-gcc test.c -L/path/to/sparcLib
-I/path/to/sparcInclude

gcc的错误类型及对策

gcc 编译器如果发现源程序中有错误,就无法继续进行,也无法生成最终的可执行文 件。为了便于修改,gcc给出错误资讯,我们必须对这些错误资讯逐个进行分析、 处理,并修改相应的语言,才能保证源代码的正确编译连接。gcc给出的错误资讯一般可以分为四大类,下面我们分别讨论其产生的原因和对策。
第一类∶C语法错误
错 误资讯∶文件source.c中第n行有语法错误(syntex errror)。这种类型的错误,一般都是C语言的语法错误,应该仔细检查源代码文件中第n行及该行之前的程序,有时也需要对该文件所包含的头文件进行检 查。有些情况下,一个很简单的语法错误,gcc会给出一大堆错误,我们最主要的是要保持清醒的头脑,不要被其吓倒,必要的时候再参考一下C语言的基本教 材。
第二类∶头文件错误
错误资讯∶找不到头文件head.h(Can not find include file head.h)。这类错误是源代码文件中的包含头文件有问题,可能的原因有头文件名错误、指定的头文件所在目录名错误等,也可能是错误地使用了双引号和尖括号。
第三类∶档案库错误
错误资讯∶连接程序找不到所需的函数库,例如∶
ld: -lm: No such file or directory
这类错误是与目标文件相连接的函数库有错误,可能的原因是函数库名错误、指定的函数库所在目录名称错误等,检查的方法是使用find命令在可能的目录中寻找相应的函数库名,确定档案库及目录的名称并修改程序中及编译选项中的名称。
第四类∶未定义符号
错 误资讯∶有未定义的符号(Undefined symbol)。这类错误是在连接过程中出现的,可能有两种原因∶一是使用者自己定义的函数或者全局变量所在源代码文件,没有被编译、连接,或者干脆还没 有定义,这需要使用者根据实际情况修改源程序,给出全局变量或者函数的定义体;二是未定义的符号是一个标准的库函数,在源程序中使用了该库函数,而连接过 程中还没有给定相应的函数库的名称,或者是该档案库的目录名称有问题,这时需要使用档案库维护命令ar检查我们需要的库函数到底位于哪一个函数库中,确定 之后,修改gcc连接选项中的-l和-L项。
排 除编译、连接过程中的错误,应该说这只是程序设计中最简单、最基本的一个步骤,可以说 只是开了个头。这个过程中的错误,只是我们在使用C语言描述一个算法中所产生的错误,是比较容易排除的。我们写一个程序,到编译、连接通过为止,应该说刚 刚开始,程序在运行过程中所出现的问题,是算法设计有问题,说得更玄点是对问题的认识和理解不够,还需要更加深入地测试、调试和修改。一个程序,稍为复杂 的程序,往往要经过多次的编译、连接和测试、修改。

补丁的制作和使用:diff和patch

原理
现在有一个文件file1,通过修改file1得到了文件file2,然后用diff工具比较file1和file2的差异,得到一个补丁文件file.patch,它记录了两个文件的不同之处,patch工具就可以根据这个补丁文件修改file1,从而得到file2。

相关工具
diff
diff [options] 源文件 目标文件
diff用于列出两个文件的不同之处,指示如何由源文件变为目标文件,可以用重定向生成补丁文件,注意:diff只能用于比较文本文件。常用选项:
-c,输出一个基于上下文的diff,即提供每处修改的前后机会内容,这样patch命令可以在打补丁前验证上下文是否匹配,而补丁文件也更容易阅读。
-b,忽略空格引起的变化
-B,忽略插入/删除空行引起的变化
-i,忽略大小写
-N,在比较目录时,如果一个文件只在其中一个目录中找到,那它被视为在第二个目录中是一个空文件
-r,在比较目录时,递归比较所有子目录
-u,使用统一的输出格式
patch
patch [options]  源文件 补丁文件
patch用于根据补丁文件修改源文件,它会直接改动源文件,打补丁前请注意备份。常用选项:
-R,反向补丁,将已经打了补丁的文件恢复到原来的样子
-p[num],忽略前几层目录,目录的层数由num指定
例1:比较两个文件
file1:
this is line1  
this is line2   
this is line3  
this is line4 

file2:
this is line1  
this is line2 hello  
this is line3  
this is line4  
this is line5 

执行:
diff file1 file2 > file.patch 
生成补丁文件file.patch:
2c2  
< this is line2   
---  
> this is line2 hello  
4a5  
> this is line5 
对file1打补丁:
patch file1 file.patch 

file1的内容就变成了file2,如果想把file1变为原来的样子,执行:
patch -R file1 file.patch  
例2:比较两个目录

在工作路径下有两个目录:doc1和doc2。
执行diff命令,生成补丁文件patch:
diff -Nur doc1 doc2 > doc.patch 
用patch工具为doc1打补丁:
bash# cd doc1  
bash# patch -p1 < ../doc.patch

本篇文章来源于 Linux公社网站(www.linuxidc.com)  原文链接:http://www.linuxidc.com/Linux/2011-07/39533.htm

yaffs文件的打包解包工具

Yaffs(Yet Another Flash File System)文件系统是专门针对NAND闪存设计的嵌入式文件系统,目前有YAFFS和YAFFS2两个版本,两个版本的主要区别之一在于YAFFS2能够更好的支持大容量的NAND FLASH芯片。

下载unyaffs源码,http://code.google.com/p/unyaffs/downloads/list
执行编译命令 gcc -o unyaffs unyaffs.c
下载mkyaffs2image源码
http://code.google.com/p/fatplus/downloads/detail?name=yaffs2-source.tar&can=2&q=
解压后进入utils文件执行
make命令 即可生成mkyaffs2image文件

将unyaffs和mkyaffs2image文件复制到/usr/bin/目录下,则就可以在其他目录下直接执行这两个命令了

解压system.img文件,直接解压system.img中的文件到当前目录,因此要想解压到system目录,必须先手动创建system目录
mkdir system
cd system
unyaffs system.img

创建system.img
mkyaffs2image system system.img

还有一个工具解压压缩功能都可以实现,而且可以指定文件被解压到的文件名
yaffs2utils 下载地址为:http://code.google.com/p/yaffs2utils/downloads/list
下载后解压,进入src目录执行 make命令即可
压缩命令为 mkyaffs2 system system.img
解压命令为 unyaffs2 system.img system(将system.img解压到system文件中)


通过此工具我们就可以对system.img等android系统升级包进行解压出来修改。

安装配置OpenGrok

OpenGrok是源代码分析利器,很多人都在使用。我经常都会到http://lxr.oss.org.cn/查找Linux内核里面的宏定义或变量定义,速度比SourceInsight快很多。不知道他们的服务器用的什么查找工具,神奇。于是就到网上找,发现很多人都在用OpenGrok,那就试一下吧,好歹离线都可以很方便搜索内核代码了。
1.下载OpenGrok:
  Can be accessed by opengrok here:

   http://src.opensolaris.org/source/xref/opengrok/trunk/
  Using web directory listing:

  http://hg.opensolaris.org/sc/src/opengrok/trunk/
  Or you can check it out using Mercurial into opengrok-dev directory:

  $hg clone ssh://anon@hg.opensolaris.org/hg/opengrok/trunk/ opengrok-dev
下载二进制包就可以了。解压到某个地方备用。
2.安装依赖工具
  sudo apt-get install ctags tomcat6
  启动tomcat:
  sudo /etc/init.d/tomcat6 start

3.$cp opengrok/lib/source.war /var/lib/tomcat6/webapps
4.$cd opengrok/
   $mkdir linux_data
   $cd linux_data
   $../bin/OpenGrok index /path/to/your/kernel/dir
   耐心等待完成,结束后访问:http://localhost:8080/source 就可以了。

在Raspberry Pi上,搭建Hadoop集群

Hadoop是由Java实现的,所以在树莓派上运行就和在其他x86平台上运行一样简单。首先, 我们需要安装支持树莓派Raspberry Pi的JVM。可以选用OpenJDK或者Oracle的JDK 8。我个人推荐JDK8,其速度稍微快些,但是OpenJDK安装更容易些。
推荐阅读:
Ubuntu 12.10下Hadoop集群免登陆配置 http://www.linuxidc.com/Linux/2013-06/85833.htm
Ubuntu 13.04上搭建Hadoop环境 http://www.linuxidc.com/Linux/2013-06/86106.htm
Raspberry Pi 树莓派搭LAMP服务器 http://www.linuxidc.com/Linux/2013-06/86687.htm
1. 安装Java
安装OpenJDK十分简单, 只要执行以下命令
pi@raspberrypi ~ $ sudo apt-get install openjdk-7-jdk
pi@raspberrypi ~ $ java -version
java version "1.7.0_07"
OpenJDK Runtime Environment (IcedTea7 2.3.2) (7u7-2.3.2a-1+rpi1)
OpenJDK Zero VM (build 22.0-b10, mixed mode)
另外, 我们可以选择安装Oracle的JDK 8.
可以从这获得: https://wiki.openjdk.java.net/display/OpenJFX/OpenJFX+on+the+Raspberry+Pi
pi@raspberrypi ~ $sudo tar zxvf jdk-8-ea-b36e-linux-arm-hflt-*.tar.gz -C /opt
pi@raspberrypi ~ $sudo update-alternatives --install "/usr/bin/java" 
"java" "/opt/jdk1.8.0/bin/java" 1 
pi@raspberrypi ~ $ java -version
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b36e)
Java HotSpot(TM) Client VM (build 25.0-b04, mixed mode)
如果你两个都装了, 用以下命令来切换即可:
sudo update-alternatives --config java
2. 新增一个hadoop系统用户
pi@raspberrypi ~ $ sudo addgroup hadoop
pi@raspberrypi ~ $ sudo adduser --ingroup hadoop hduser
pi@raspberrypi ~ $ sudo adduser hduser sudo
3. 设置SSH
pi@raspberrypi ~ $ su - hduserhduser@raspberrypi ~ $ ssh-keygen -t rsa -P ""
这会生成一个匹配空密码的RSA密钥. 在与其他节点通讯时Hadoop将不再提示输入密码
hduser@raspberrypi ~$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
现在设置SSH允许用刚生成的密钥访问
hduser@raspberrypi ~$ ssh localhost
现在我们就应该可以不使用密码也可以登录了
4. 安装Hadoop
我们可以从http://www.apache.org/dyn/closer.cgi/hadoop/core下载hadoop
hduser@raspberrypi ~$ wget http://mirror.catn.com/pub/apache/hadoop/core/hadoop-1.1.2/hadoop-1.1.2.tar.gz
hduser@raspberrypi ~$sudo tar vxzf hadoop-1.1.2.tar.gz -C /usr/local
hduser@raspberrypi ~$cd /usr/local
hduser@raspberrypi /usr/local$ sudo mv hadoop-1.1.2 hadoop
hduser@raspberrypi /usr/local$ sudo chown -R hduser:hadoop hadoop
现在hadoop就安装好了. 编译home目录下的.bashrc文件, 将以下内容添加到其中
export JAVA_HOME=/usr/lib/jvm/java-6-openjdk-armhf
export HADOOP_INSTALL=/usr/local/hadoop
export PATH=$PATH:$HADOOP_INSTALL/bin
如果你用的是oracle的JDK, 相应的修改JAVA_HOME.
重启一下树莓派来验证安装是否成功:
hduser@raspberrypi ~$ hadoop version
Hadoop 1.1.2
Subversion https://svn.apache.org/repos/asf/hadoop/common/branches/
branch-1.1 -r 1440782
Compiled by hortonfo on Thu Jan 31 02:03:24 UTC 2013
From source with checksum c720ddcf4b926991de7467d253a79b8b
5. 配置Hadoop
注意: 这里的配置是hadoop单节点模式的最低配.
配置文件位于"/usr/local/hadoop/conf/", 我们需要修改core-site.xml, hdfs-site.xml, mapred-site.xml三个文件
core-site.xml
<configuration>
  <property>
    <name>hadoop.tmp.dir</name>
    <value>/fs/hadoop/tmp</value>
  </property>
  <property>
    <name>fs.default.name</name>
    <value>hdfs://localhost:54310</value>
  </property>
</configuration>
mapred-site.xml
<configuration>
  <property>
    <name>mapred.job.tracker</name>
    <value>localhost:54311</value>
  </property>
</configuration>
hdfs-site.xml
<configuration>
  <property>
    <name>dfs.replication</name>
    <value>1</value>
  </property>
</configuration>
哦了, 即将完工, 还剩最后一步.
hduser@raspberrypi ~$ sudo mkdir -p /fs/hadoop/tmp
hduser@raspberrypi ~$ sudo chown hduser:hadoop /fs/hadoop/tmp
hduser@raspberrypi ~$ sudo chmod 750 /fs/hadoop/tmp
hduser@raspberrypi ~$hadoop namenode -format
注意:
如果选用的是JDK 8, 我们需要强制在JVM client模式下运行DataNode, 因为JDK 8还不支持server模式. 进入/usr/local/hadoop/bin目录中来编辑hadoop文件(请先备份). 使用nano进行修改的步骤如下:nano hadoop, ctrl-w输入“-server”进行查找. 我们需要删除“-server”这个参数, 然后保存退出就行了.
hadoop单节点系统就算是搭建完成了. 下面给一些有用的命令.
1. jps           // 输出本地VM标识符
2. start-all.sh  // 启动所有hadoop进程
3. stop-all.sh   // 停止所有hadoop进程
 更多Hadoop相关信息见Hadoop 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=13