まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

タグ:centos

自分は(慣れの要素が大きいのですが)CentOS は未だに 6.x をメインに使っています。「別に不便じゃないし~」程度にしか考えていなかったのですが、その姿勢を改めた方がいいかなあ、と思うことがあったので、その時の様子と対処がいかに大変だったかをまとめました。

Linux で比較的新しめのアプリケーションを使おうとすると、たまにこんなエラーメッセージが出ることがあります:
./xxxxx: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by ./xxxxx)
./xxxxx: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by ./xxxxx)
./xxxxx: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.5' not found (required by ./xxxxx)
./xxxxx: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /opt/Xxxxx/libnode.so)

これはシステムにインストールされている libstdc++(GLIBC) ライブラリが古く、動かそうとしているアプリケーションが要求するバージョン(上の例では 3.4.14 や 3.4.15)と合わないためのエラーが発生していることを意味しています。


※実はこのエラーはこのブログエントリの最後に「Rodeo は CentOS/RHEL 7.x 上で動かすのが無難」と書いた時の話です。CentOS 6.8 で普通に Rodeo をインストールして動かすと、ここで紹介しているようなエラーに遭遇するのでした:
CentOS に Rodeo(Python IDE)をインストールする


実際にシステムに組み込まれている libstdc++ のバージョンを確認するには以下のコマンドを実行します(青字は出力結果):
# strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX

GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_FORCE_NEW
GLIBCXX_DEBUG_MESSAGE_LENGTH

この例の場合、3.4.1 から 3.4.13 までは組み込まれているシステムであることが分かります。このシステムで上記アプリケーションを動かそうとすると 3.4.14 や 3.4.15 は組み込まれていないため、上述のようなエラーが発生してしまう、ということになるのでした。エラーの原因はこれで特定できました。


この状況を回避するには libstdc++ を必要なバージョンが組み込まれた新しいものと入れ替える必要があります。そして libstdc++ は gcc に含まれるモジュールなので、(まず gcc ビルドの前提となる glibc を更新して、)gcc をビルドして、そこから libstdc++ を取り出して既存のものと入れ替える、というちと面倒な手順を実行する必要があるのでした。要するに libstdc++ を新しくするためには gcc をビルドする必要があるのです。。

更に、ここまでは全ての Linux ディストリビューションに言える内容なのですが、実際にこの手順を行う場合、CentOS/RHEL 6.x だとものすごく面倒な手順が待ち構えているのでした。実際に行った長い道のりを以下に紹介します。



まず、gcc のビルドに必要なヘッダーファイルをインストールします。具体的には gmp-devel, mpfr-devel, libmpc-devel が必要で、かつ 64bit 環境では glibc-devel.i686 までも必要になります。このうち libmpc-devel 以外は標準の yum リポジトリからインストールできますが、libmpc-devel は EPEL から入手する必要があります。

というわけで、まずは EPEL リポジトリをダウンロード:
# yum install epel-release

続けて上記3つのヘッダファイルと 32bit 版 glibc ヘッダをダウンロードします:
# yum install gmp-devel mpfr-devel libmpc-devel
# yum install glibc-devel.i686

ヘッダファイルの準備ができた所で最初に前提となる glibc をダウンロードしてビルドします。以下の例では /usr/local/src 以下にソースコードを展開しています:
# cd /usr/local/src
# wget http://ftp.gnome.org/pub/gnome/sources/glib/2.32/glib-2.32.4.tar.xz
# tar Jxvf glib-2.32.4.tar.xz
# rm glib-2.32.4.tar.xz
# cd glib-2.32.4
# ./configure
# make
# make install

そして、ここからやっと gcc のソースコードをダウンロードしてビルドします。ちなみにここから先の手順を行うためには 5GB 弱の空きディスク容量が必要になります。また make の実行を開始してから完了するまでに数時間かかります。スペックにもよりますが、昼寝ではなく一度マジ寝して起きる頃に終わっている、というくらいの時間を見ておく必要があります (^^;:
# cd /usr/local/src
# curl -LO http://ftp.tsukuba.wide.ad.jp/software/gcc/releases/gcc-4.8.4/gcc-4.8.4.tar.gz
# tar fxz gcc-4.8.4.tar.gz
# rm gcc-4.8.4.tar.gz
# cd gcc-4.8.4
# ./configure
# make (僕の仮想環境ではここで4~5時間かかりました・・)
# make install

・・・で、gcc のビルドが無事に完了したら libstdc++ の入れ替えを行います。まずは現在の状況を確認します:
# ls -l /usr/lib64/libstdc*

lrwxrwxrwx 1 root root     19  1月 23 12:35 2017 /usr/lib64/libstdc++.so.6 -> libstdc++.so.6.0.13
-rwxr-xr-x 1 root root 989840  5月 10 18:38 2016 /usr/lib64/libstdc++.so.6.0.13

ビルドした結果から、目的のライブラリをコピーして、シンボリックリンクを作り直します:
# cp /usr/local/src/gcc-4.8.4/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.19 /usr/lib64
# cd /usr/lib64
# mv libstdc++.so.6 libstdc++.so.6.bak
# ln -s libstdc++.so.6.0.19 libstdc++.so.6
# ls -l /usr/lib64/libstdc*

lrwxrwxrwx 1 root root      19  2月 14 12:07 2017 /usr/lib64/libstdc++.so.6 -> libstdc++.so.6.0.19
-rwxr-xr-x 1 root root  989840  5月 10 18:38 2016 /usr/lib64/libstdc++.so.6.0.13
-rwxr-xr-x 1 root root 6468627  2月 14 12:06 2017 /usr/lib64/libstdc++.so.6.0.19
lrwxrwxrwx 1 root root      19  5月 26 11:23 2016 /usr/lib64/libstdc++.so.6.bak -> libstdc++.so.6.0.13

最後に目的のバージョン(今回であれば 3.4.14 や 3.4.15)が有効になっているかどうかを確認します:
# strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX

GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_FORCE_NEW
GLIBCXX_DEBUG_MESSAGE_LENGTH

期待通りのライブラリに更新できました。これで CentOS 6.x でも Rodeo が動くようになりました。いやあ、長かった。めでたし、めでたし:
rodeo_centos6
↑今回のブログエントリは、この「CentOS 6.x 上で動く Rodeo」のスクリーンショットを撮るまでがいかに大変であったかを分かっていただきたいがために書きました。 (^^;


ここまで確認できれば glibc や gcc のソースコード一式は不要なので、消してしまっても構いません(何しろこの環境のために 5GB 前後のディスクを専有しているので・・・)
# cd /usr/local/src
# rf -rf glib-2.32.4 # rm -rf gcc-4.8.4




(参考)
http://qiita.com/dozo/items/de393588d5c267794ced

https://www.saintsouth.net/blog/update-libstdcpp-on-centos6/



 

マルチプラットフォーム対応の Python IDE である Rodeo を CentOS/RHEL にインストールする手順を紹介します:
https://www.yhat.com/products/rodeo

2017021300


といっても手順として特別なことはなく、リポジトリを追加して yum でインストールするだけです:
$ sudo wget http://rodeo-rpm.yhat.com/rodeo-rpm.repo -P /etc/yum.repos.d/
$ sudo yum install rodeo

インストール後、アプリケーションメニューの「その他」から起動できます:
2017021301


はい起動しました。簡単ですね~(※CentOS/RHEL 7 の場合)
rodeo_centos6


機械学習や数値解析に便利なライブラリが充実している Python をより便利に使うための Python IDE も充実してきてるんですね。。


なお、上でわざと(※CentOS/RHEL 7 の場合)と強調しているのには意味があります。ご覧のように上記のスクリーンショットは CentOS 6 上で動いている Rodeo の画像なのですが、この環境を作るのは一筋縄ではいかなかった、という背景があります(このスクリーンショットを撮るまでの作業が、まあ大変でした・・・)。別の機会に詳しく書くかもしれませんが、とりあえず Rodeo は CentOS/RHEL 7.x 上で動かすのが無難、と付け加えておきます。


IBM Bluemix からも提供しているビジュアルフローエディタ Node-RED の最新バージョン v0.16 がリリースされました(2017/Jan/17 時点での最新版は v0.16.1):
https://libraries.io/npm/node-red/


新機能などの情報についてはこちらの公式ブログエントリや、
http://nodered.org/blog/2017/01/11/version-0-16-released

こちらのリリースノートを参照ください:
https://github.com/node-red/node-red/releases/tag/0.16.0


さて、上記ブログエントリにも書かれているのですが、この v0.16 より Node.js の v0.10 および v0.12 がサポート外になりました。Node.js も v4 以上のものを用意する必要があります。

これで問題になるのが CentOS/RHEL 6.x を使っている場合です。現在、CentOS/RHEL 6.x で(epel リポジトリなどを使って)普通に Node.js を導入すると v0.10.48 が導入されます:
# node -v
v0.10.48

IBM からも IBM SDK for Node.js として IBM 版の Node.js がリリースされていますが、こちらも CentOS/RHEL 6.x は v0.12 までしか用意されておらず、Node.js v4 以上を使おうとすると CentOS/RHEL であれば 7.x を使う必要があります:
https://developer.ibm.com/node/sdk/

2017011702


ちなみに Node.js v0.10.x が導入された状況下で深く考えずに npm を使って Node-RED を導入すると、最新バージョン(今であれば v0.16.1)が導入されてしまいます。その結果起動時にエラーが発生し、ユーザー画面にもエラーメッセージが表示されてしまいます:
# npm install node-red -g  (このコマンドは成功する)

# node-red
  :
  :
Welcome to Node-RED
===================

17 Jan 10:10:33 - [info] Node-RED version: v0.16.1
17 Jan 10:10:33 - [info] Node.js  version: v0.10.48
17 Jan 10:10:33 - [error] *****************************************************************
17 Jan 10:10:33 - [error] * Unsupported version of Node.js. Requires: >=4 Found: v0.10.48 *
17 Jan 10:10:33 - [error] *****************************************************************
17 Jan 10:10:33 - [info] Linux 2.6.32-642.11.1.el6.x86_64 x64 LE
17 Jan 10:10:33 - [info] Loading palette nodes

/usr/lib/node_modules/node-red/node_modules/mqtt/lib/connect/index.js:100
    const isSecure = ['mqtts', 'wss'].indexOf(opts.protocol) !== -1
    ^^^^^
17 Jan 10:10:35 - [warn] ------------------------------------------------------
17 Jan 10:10:35 - [warn] [rpi-gpio] Info : Ignoring Raspberry Pi specific node
17 Jan 10:10:35 - [warn] [mqtt] SyntaxError: Use of const in strict mode.
17 Jan 10:10:35 - [warn] ------------------------------------------------------
17 Jan 10:10:35 - [info] Settings file  : /root/.node-red/settings.js
17 Jan 10:10:35 - [info] User directory : /root/.node-red
17 Jan 10:10:35 - [info] Flows file     : /root/.node-red/flows_xxxxxxxx.xxxxx.xxx.json
17 Jan 10:10:35 - [info] Creating new flow file
17 Jan 10:10:35 - [info] Server now running at http://127.0.0.1:1880/
17 Jan 10:10:35 - [info] Starting flows
17 Jan 10:10:35 - [info] Started flows

↑起動が成功したように見えるが、バージョン非互換のエラーが発生している

2017011701


では改めて CentOS/RHEL 6.x のバージョンアップをせずにどうやって Node-RED を導入すればよいでしょうか? Node-RED の最新版を動かすために工夫する、というのも1つの方法ですが、Node-RED が最新版でなくてもよい場合であれば Node-RED v0.14.x を使う、という方法もあります。このバージョンであれば CentOS/RHEL 6.x でも動作します。

その場合の手順を紹介します。まず上記のコマンドを実行してしまって Node-RED v0.16.x を導入してしまった場合はアンインストールします:
# npm uninstall node-red -g

リリースサイトを見ると、v0.14.x の最新バージョンは v0.14.6 のようです(2017/Jan/17 時点)。というわけで、改めてこのバージョンを指定して npm でインストールします:
# npm install node-red@0.14.6 -g

こうしてインストールした Node-RED を起動すればエラーは発生しません:
# node-red
  :
  :
Welcome to Node-RED
===================

17 Jan 10:15:55 - [info] Node-RED version: v0.14.6
17 Jan 10:15:55 - [info] Node.js  version: v0.10.48
17 Jan 10:15:55 - [info] Linux 2.6.32-642.11.1.el6.x86_64 x64 LE
17 Jan 10:15:55 - [info] Loading palette nodes
17 Jan 10:15:58 - [warn] ------------------------------------------------------
17 Jan 10:15:58 - [warn] [rpi-gpio] Info : Ignoring Raspberry Pi specific node
17 Jan 10:15:58 - [warn] ------------------------------------------------------
17 Jan 10:15:58 - [warn] Missing node modules:
17 Jan 10:15:58 - [warn]  - node-red: yaml
17 Jan 10:15:58 - [info] Removing modules from config
17 Jan 10:15:58 - [info] Settings file  : /root/.node-red/settings.js
17 Jan 10:15:58 - [info] User directory : /root/.node-red
17 Jan 10:15:58 - [info] Flows file     : /root/.node-red/flows_xxxxxxxx.xxxxx.xxx.json
17 Jan 10:15:58 - [info] Creating new flow file
17 Jan 10:15:58 - [info] Starting flows
17 Jan 10:15:58 - [info] Started flows
17 Jan 10:15:58 - [info] Server now running at http://127.0.0.1:1880/

↑起動成功

というわけで、現時点で比較的簡単に CentOS/RHEL 6.x で Node-RED を動かす場合はこの方法になるのかな、と思ってます:
2017011703


なお、CentOS/RHEL 6.x に Node.js v4.x を導入してから Node-RED v0.16.x を入れる、という方法もあります。CentOS/RHEL 6.x に Node.js v4.x を入れる方法についてはこちらに詳しく書かれていました:
CentOS 6.xにLTS(4.3.0)のnode.jsをインストールする

CentOS や RHEL で便利に利用されているパッケージ管理コマンドの "yum" 。このコマンドの便利な使い方の1つが groupinstall と呼ばれる機能です。ある環境を用意しようとした際に複数のパッケージを導入しないといけない場合、その複数のパッケージを1つの「グループパッケージ」のまとまりとみなし、グループパッケージ1つを指定して導入することで環境構築が可能になります。

個人的によく使う例で紹介すると、GUI のデスクトップ環境であれば "Desktop"、日本語サポート環境であれば "Japanese Support" などです。それぞれ以下のコマンドで導入できます:
(デスクトップ環境)
# yum groupinstall "Desktop"
(日本語サポート環境) # yum groupinstall "Japanese Support"

上記のようにグループパッケージを指定するだけでまとまったパッケージを導入できるのは便利なのですが、ではこれらのコマンドで実際にどのようなパッケージが導入されるのかを調べる方法はあるでしょうか? その答が yum の groupinfo コマンドです。例えば "Desktop" で何が導入されるのかを確認するには以下のようなコマンドを実行します(黒字が入力、青字が出力結果です):
# yum groupinfo "Desktop"
  :
  :
グループ: デスクトップ
 説明: シンクライアントとして使用できる最低限のデスクトップ
 強制的なパッケージ:
   NetworkManager
   NetworkManager-gnome
   alsa-plugins-pulseaudio
   at-spi
   control-center
   dbus
   gdm
   gdm-user-switch-applet
   gnome-panel
   gnome-power-manager
   gnome-screensaver
   gnome-session
   gnome-terminal
   gvfs-archive
   gvfs-fuse
   gvfs-smb
   metacity
   nautilus
   notification-daemon
   polkit-gnome
   xdg-user-dirs-gtk
   yelp
 標準パッケージ:
   control-center-extra
   eog
   gdm-plugin-fingerprint
   gnome-applets
   gnome-media
   gnome-packagekit
   gnome-vfs2-smb
   gok
   openssh-askpass
   orca
   pulseaudio-module-gconf
   pulseaudio-module-x11
   vino
 オプション パッケージ:
   sabayon-apply
   tigervnc-server
   xguest


同様に "Japanese Support" の場合は以下のようになりました:
# yum groupinfo "Japanese Support"
  :
  :
グループ: 日本語のサポート
 Language: ja
 標準パッケージ:
   ipa-gothic-fonts
   ipa-mincho-fonts
   ipa-pgothic-fonts
   ipa-pmincho-fonts
   vlgothic-fonts
   vlgothic-p-fonts
 条件付パッケージ:
   autocorr-ja
   eclipse-nls-ja
   ibus-anthy
   kde-i18n-Japanese
   kde-l10n-Japanese
   libreoffice-langpack-ja
   man-pages-ja
   poppler-data


これらの結果の中の「強制的パッケージ」と「標準パッケージ」が groupinstall コマンドによって導入されます。また「オプションパッケージ」や「条件付きパッケージ」が導入可能になります。

滅多にはないのですが、CentOS/RHEL の環境によっては "yum groupinstall" コマンドが使えないこともあります。その場合はここに記載した情報を使って "yum install" で同様の環境構築が可能になります。

※ここに記載されていないグループパッケージを導入する場合は、"yum groupinfo" の使える環境でパッケージを確認し、そこにリストされたパッケージを "yum install" する、という形になります。


Microsoft が .Net アプリケーションを動かすためのフレームワークとしてオープンソース化を進めていた ".Net Core" の正式バージョン 1.0 がリリースされました:
https://www.microsoft.com/net/core

この .Net Core が .Net アプリケーションを動かすための基盤であり、同時に公開された ASP.Net Core は Web アプリケーションの開発基盤となる部分になります。従って .Net Framework のうちの GUI を除いた開発環境のオープンソース化が実現され、Linux や MacOS 上で動かすことができるようになった、ということになります。

というわけで、早速自分の CentOS 環境に導入して使ってみました。なお、.Net Core は CentOS 7 以降に対応しているので、CentOS 7.x 環境を用意した上で以下を説明します。

まずは .Net Core 1.0 をインストールします。CentOS 7 環境で(SSH などで)ターミナルログインし、以下のコマンドを実行します(この例では実体を /opt/dotnet/ 以下にインストールし、/usr/local/bin へシンボリックリンクしています):
$ sudo yum install libunwind libicu
$ curl -sSL -o dotnet.tar.gz https://go.microsoft.com/fwlink/?LinkID=827529
$ sudo mkdir -p /opt/dotnet
$ sudo tar zxf dotnet.tar.gz -C /opt/dotnet $ sudo ln -s /opt/dotnet/dotnet /usr/local/bin

インストールはこれで完了です。では実際にアプリを作ってみましょう。雛形として用意されているアプリがいわゆる "Hello World" なので、"helloworldapp" というフォルダを作り、その中にアプリを作ることにします:
$ mkdir helloworldapp
$ cd helloworldapp
$ dotnet new

上記の最後に入力している "dotnet new" コマンドで雛形作成を含めた初期化を行います。この初期化によって、Program.cs ファイルと project.json ファイルという2つのファイルが作成されます:
2016092901


このうちの Program.cs ファイルがソースコードに相当するファイルです。デフォルト状態では "Hello World!" という文字列をコンソールに表示(WriteLine)するだけの内容になっています:
2016092902


これを vi などのエディタで適当に書き換えてみましょう。以下の例では "ハロー .Net ワールド!!" という日本語文字列に変えてみました:
2016092903


もう1つの proejct.json ファイルは依存関係などのパッケージ情報が記述されています。こちらは今回は変更が不要です:
2016092904

ではいよいよ CentOS 上でこの .Net アプリを動かしてみましょう。"dotnet run" と入力します:
$ dotnet run

成功すると以下のようにコンパイルされ、実行されて、書き換えた文字列が表示されるはずです:
2016092906


なお実行時にコンパイルされるので、このコマンド実行後には bin と obj フォルダがそれぞれ生成されているはずです:
2016092901


今回は CentOS 7.x 上でのインストールから実行までを紹介しました。実行手順は全てで共通ですが、インストール方法はシステムによって若干異なります(Docker イメージも公開されてるんですね・・・)。詳しくは公式ドキュメントを参照ください:
https://www.microsoft.com/net/core


このページのトップヘ