Linux日記

CentOS 6.9 (64bit) に　xampp linux x64 5.6.31 をインストール

By
3 Mins read

久しぶりに環境設定で少しハマったので書き込み

CentOS 6.9 (64bit) にxampp linux x64 5.6.31 をインストールしたら以下のエラーで起動できない。

# ./lampp start
egrep: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
egrep: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
/bin/bash: error while loading shared libraries: libdl.so.2: cannot open shared object file: No such file or directory
egrep: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
/opt/lampp/bin/gettext: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
　
id: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
/opt/lampp/share/xampp/xampplib: line 11: test: -ne: unary operator expected
/opt/lampp/bin/gettext: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
XAMPP: egrep: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
netstat: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
egrep: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
netstat: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
/opt/lampp/bin/gettext: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
/opt/lampp/bin/httpd: error while loading shared libraries: librt.so.1: cannot open shared object file: No such file or directory
/opt/lampp/bin/gettext: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
XAMPP: hostname: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
egrep: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
netstat: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
/opt/lampp/bin/gettext: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
/bin/sh: error while loading shared libraries: libdl.so.2: cannot open shared object file: No such file or directory
/opt/lampp/bin/gettext: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
XAMPP: egrep: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
netstat: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
/opt/lampp/bin/gettext: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
/opt/lampp/bin/gettext: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory

「libc.so.6」ライブラリが無いか？環境変数のPathがおかしいんだろうと決め込んで確認コマンド投げる

yumで確認
#yum provides */libc.so.6
　
読み込んだプラグイン:fastestmirror, security
Loading mirror speeds from cached hostfile
* base: ftp.iij.ad.jp
* extras: ftp.iij.ad.jp
* updates: ftp.iij.ad.jp
base/filelists_db | 6.4 MB 00:00
extras/filelists_db | 25 kB 00:00
updates/filelists_db | 2.9 MB 00:00
glibc-2.12-1.209.el6.x86_64 : The GNU libc libraries
リポジトリー : base
一致 :
ファイル名 : /lib64/libc.so.6
　
glibc-2.12-1.209.el6.i686 : The GNU libc libraries
リポジトリー : base
一致 :
ファイル名 : /lib/i686/nosegneg/libc.so.6
ファイル名 : /lib/libc.so.6
　
glibc-2.12-1.209.el6_9.1.i686 : The GNU libc libraries
リポジトリー : updates
一致 :
ファイル名 : /lib/i686/nosegneg/libc.so.6
ファイル名 : /lib/libc.so.6
　
glibc-2.12-1.209.el6_9.2.i686 : The GNU libc libraries
リポジトリー : updates
一致 :
ファイル名 : /lib/i686/nosegneg/libc.so.6
ファイル名 : /lib/libc.so.6
　
glibc-2.12-1.209.el6_9.2.x86_64 : The GNU libc libraries
リポジトリー : updates
一致 :
ファイル名 : /lib64/libc.so.6
　
glibc-2.12-1.209.el6_9.1.x86_64 : The GNU libc libraries
リポジトリー : updates
一致 :
ファイル名 : /lib64/libc.so.6
　
glibc-2.12-1.209.el6_9.2.x86_64 : The GNU libc libraries
リポジトリー : installed
一致 :
ファイル名 : /lib64/libc.so.6
　
glibc-2.12-1.209.el6_9.2.i686 : The GNU libc libraries
リポジトリー : installed
一致 :
ファイル名 : /lib/i686/nosegneg/libc.so.6
ファイル名 : /lib/libc.so.6

いるね～

なんじゃ？リンク切れか？。。。リンクあるし？？？
はて？

起動時にエラー？

起動ファイルlampp＝xamppファイルなのでviでオープンし中身確認

どうやら起動時のOSバージョンチェックで読み込み先共通ライブラリが違っていることが原因見たいだけど、このエラーメッセージからはそんなこと読み取れん！Cのデバッグと同じで落ちている箇所やエラーメッセージに騙されてはいかんやつやな（笑）本質の問題を見分ける所は。。。人生と同じか（苦笑）

CentOSのバージョン確認「2.6.32」部分がキーとなっておりこれを超えているか？のチェックっぽい
#more /proc/version
Linux version 2.6.32-696.13.2.el6.x86_64 (mockbuild@c1bl.rdu2.centos.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-18) (GCC) ) #1 SMP Thu O
ct 5 21:22:16 UTC 2017

viでxamppを開き436行目の
「export LD_ASSUME_KERNEL=2.2.5」
を
「export LD_ASSUME_KERNEL=2.8.0」
へ変更してあげる

こんな感じ
# do we have that new red hat linux 9 with posix native threads?
if test $(osguess) = "rh9"
then
# for now disable PNTL. if PNTL gets more popular we will support it. - oswald [8apr3]
export LD_ASSUME_KERNEL=2.8.0
#echo "XAMPP: DISABLE PNTL..."
fi

これで無事起動♪
#./lampp start

Read more
JavaScript

javascript UI 開発時の心得 'Sencha Ext JS' 'Webix' 'OpenUI5' 'AngularJS'

By
1 Mins read

お久しぶりです。

ブログ更新が2014年から止まっていますが、筆者は変わらずに開発者もやっています。

ここ数年javascript(以下、js)のライブラリーを使用しAjaxとjsonを合わせたシステム開発で楽しんでおります。サーバーサイドはjson出力できれば何でもよいかなぁ（笑）

Sencha Ext JS Webix OpenUI5 AngularJSなど使用し、一番使い込んでいるのはExt Jsです。

20年近くこの業界におり、要件定義など紙を書く仕事より手を動かすほうが相変らず好きなので、オープン系を中心に色々な言語を経験習得してきています。

どの言語でも初めに勉強する際には日英(英の方が圧倒的に多い)関わらずサンプルを見ながら皆さん勉強し、コピペしながら使い方を覚えていくと思います。他の言語ならサンプルソースを元にしサクサクと勉強、習得、本番システム作成と思い通りの速度で構築していくことが出来るのですが、jsと言う言語については同じような要領で進めてみても開発時に四苦八苦している方やお手上げ状態で涙目になっている方を多く見受けています。

そこで要点について解説したいと思います。

まずキーとなる部分はhtmlで使用され各タグに設定もできる「id」となります。これはcssをリンクする際にも使用できますが、表示されているhtml上で必ずユニークにする必要があり、その特性を生かしjsではもっぱらdomオブジェクトの指定やdomと紐づくjsコンポーネント名として使用され外部クラスからサーチする時など、操作する際に使用されております。

タイトルで上げたjsを含め各種サンプル等では、このidが固定(リテラル)なことが多くサンプルソースを参考にし、サクッと組み合わせても、思うように動かないことが多々あるのですが、その理由の大半がid名を固定のまま使用した結果、重複してしまい動かないというパターンが圧倒的に多い気がします。

ここが心得部分となりますが、jsコンポーネントクラスのインスタンスを作成する際、親クラスで動的にユニークなidを生成しそのidを埋め込む形で子クラスを生成する。(子クラスで生成し親クラスへ送るという逆パターンも状況によりあり)また、そのidを親クラスや上位コンポーネントで記憶しておき子クラスを操作する。それにより名前の衝突を回避でき正常に操作することが可能となります。サンプルのクラスは子クラスを複数持っていることが多く、その全部のidを動的生成へ変更することと、親側で操作する部分も動的生成されたidを使用するように修正する必要があります。よってサンプルのクラスはid＝固定(リテラル)で作成されていることが多いので簡単に移植できない状況となっています。

各ライブラリには動的にidを生成するお手軽メソッドが存在することが多いので、そのメソッドを使用することをお勧めします。(例:Ext.id())

当たり前ですが世の中、何かを識別するには必ずユニーク名が最後に必要となります。マイナンバーが何処まで使用できているのかわかりませんが日本では人の区別を姓名や生年月日、市区町村などで見分けているようですが、その曖昧さのせいで間違って他人の年金を管理するなどエンジニアとしては考えられない状況が昔からあるようです。コンピュータの世界では近年macadressを使用して生成するキー、uuidを使うことが多いですかね。しかし、uuidですら天文学的にはユニークを保証できないのですが（笑）

話をjsに戻して、最近の言語、C#、VB.Net、Java、PHP、Rubyなどではあまり使用しないスレッド処理（非同期）の概念がAjaxとjsonでは求められ考えながら作りこむのが大変面白いです。昔、C言語でWindows API Messageを使用しフックされてから動作させるアプリを思い出します。

あと、jsは動的にクラス継承、メソッド、プロパティ、メンバ変数を増やしていけるスクリプト言語なので、他の言語のようにコンパイルエラーで問題点を簡単に炙り出せない。エンジニアがjsの特性を理解し、より明確なドキュメント化やカプセル化をしないとチーム単位で開発スピードを上げるのが大変そうです。

この動的に色々やれる部分は、昔、C#、Javaではシリアライズとデシリアライズとしていくつか作ったことあります。動的にクラスをテキスト化しサーバー間を通して送り先サーバーでテキストからメモリ上のインスタンスとしてクラス化し送り先のJavaでそのまま動作させるということももちろんできますし、データベースからモデルを読み込み動的にJavaクラスをインスタンス化することもできます。これはSOAPという技術でも使用されたり、同じ原理でJavaのStrutsも動いており、Strutsに関しては、この部分の脆弱性を危惧する声が大きいのも話題となっていますね。

少し話が脱線しました（笑）

js楽しいのでイチ押し言語です。

心得「id」は動的に生成する！でした。

Read more