「 linux 」一覧

クロスコンパイラgccのビルドがうまくいかない


ARMターゲットのプログラムをコンパイルするための、クロスコンパイラを自前でmakeしようと試行錯誤していますがうまくいきません。色々と調べてみて、1つ解決したかと思えば次また止まり、最終的にできあがったコンパイラでは正常に実行できるelfが出来上がらずといったところです。
折角なので、やってみたことを記録として残しておこうと思います。これでも誰かの参考になったら幸いです。

その1

gmp
mpfr
mpc
gcc
binutils
newlib

これらを用意してmakeしていきます。
gmp,mpfr,mpcらがgccで必要とするらしく・・・。またこれら出来上がった場所を LD_LOAD_LIBRARY に追加して soを参照できるようにしてみました。
というのも、gccのmake過程で GCC_NO_EXECUTABLES エラーがでてしまい・・・解決するかと思ったのですが。so解決しても結局解消することは不可能でした。また –disable-dlopenも試してみたのですがこれもまたNG

その2

export TARGET=arm-eabi
export PREFIX=/usr/local/gnu
configure –prefix=$PREFIX –target=$TARGET –enable-interwork –enable-multilib –enable-languages=c –with-newlib –disable-shared –disable-thread –without-headers –disable-libssp

これでgccを makeしてみるとうまくいった.ただし期待したシロモノができない。
理由は arm-eabi だったから。今ほしいのは eabihf の ABI
arm-linux-gnueabihf をターゲットとしてmakeさせると、エラーが発生。GCC_NO_EXECUTABLES 問題解決できず終了。

その3

どうやら gccのコンパイル過程で makeinfo が問題となっているよう。
apt-get install texinfo で makeinfo も片付くが、バージョンが問題になっている模様。新しいバージョンだとgccのmake過程でエラーが発生してしまう。
そこで、 makeinfo のバージョンを 5.0未満にすべく、古い物をソースからインストールしてみた。4.13あたりでチャレンジした。
これでgccのmakeはうまくいくようになるが、別の問題が発生。

arm-linux-gnueabihf のABIでパッチ当てたりしてmakeしてみるものの 失敗。armアセンブラが解釈できない何かでglibcの生成で失敗。
なお、 http://keropo.hatenadiary.com/entry/2013/04/14/232244 を参考にして eabi ならばうまくgccが生成できるところまではこぎ着けた。すごく参考になりました。

まとめ

クロスコンパイラgccを準備するのは非常に大変。
外部から提供される or 同梱されているならばそれを使うのが吉です。自力で用意してやろうとか欲を出すと、これに相当時間を取られそうです。
とはいえ、あまりにあまりな結果だったので他の方法もまだ探してみたいと思います。


NVIDIAドライバのインストール(Ubuntuにて)


Ubuntuで NVIDIA からドライバダウンロードしてきて最新版を追いかける人向けの内容です。今回は NVIDIA-Linux-x86_64-331.49 ドライバを用いての内容です。作業開始前にドライバはダウンロードしておきましょう。

まず Xサーバー関係の開発用パッケージのインストールをしておきます
sudo apt-get install xserver-xorg-dev

/etc/default/grub を開いて、GRUB_CMDLINE_LINUX_DEFAULT の行を編集

sudo grub-mkconfig -o /boot/grub/grub.cfg を実行

Xサーバーの停止
sudo /etc/init.d/lightdm stop

ここから ssh でつないでコンソールで作業.

このような結果になったらパッケージを削除していきます。

sudo apt-get --purge remove xserver-xorg-video-nouveau
sudo apt-get --purge remove nvidia-319 nvidia-common nvidia-settings-319

システムを再起動します。
再起動後再び Xサーバーを停止します。
sudo /etc/init.d/lightdm stop

再びコンソールでの作業をしたいので ssh 経由で作業します。
ここの段階までにNVIDIAからドライバをダウンロードしておいてください。

ダウンロードしたファイルの場所で、下記コマンドを実行します.

sudo sh NVIDIA-Linux-x86_64-331.49.run

Verifying archive integrity... OK
Uncompressing NVIDIA Accelerated Graphics Driver for Linux-x86_64 331.49..........................................

インストールを手順に沿って進めた後、再起動します。

インストール後うまくXが起動したら、NVIDIA X Server Settings を開いてみます。
(これは検索してみつけます)
いわゆるNVIDIAコントロールパネルですが、これでインストールしたドライバになっているかどうか確認して下さい。


LinuxをクライアントでOpenVPN


結局OpenVPNに戻ってきました。
L2TPより遙かに自分には扱いやすいです・・・。また以前はWindowsをクライアントとしてLinuxサーバーにOpenVPNを入れていたのですが、今回はLinuxをクライアントとして設定する方法にチャレンジしてみました。

続きを読む


LinuxクライアントでL2TP


L2TPについてLinuxをクライアントとして用いて接続を行ってみました。Windowsをクライアントとする場合、OS標準でサポートしているため単なる設定を行えばつながるようなので。

なお、サーバーは手軽にSoftEtherのオープンソース版で実験してみました。

続きを読む


久しぶりにVPN


ずいぶんと久しぶりにVPNの勉強(補強)をしています。以前はIPSecサーバーを立てて、自分で拠点間接続をしたところで満足して、その先に進むことをしませんでした。

あれからずいぶんと経って、今はL2TPやSSTPといったものが出現しています。これらについて、ちょっと勉強をしてみようと思っています。ひとまずは L2TP が良さそうな感じです。何より現時点においてはAndroidやiPhoneでも使用することができるようになっていると聞きます。


KVMでデバイスパススルー その4


PT2で実験中

PX-W3PEで仮想マシン内録画でさんざんな結果でしたが、
PT2ではどうなんだろうとおもってテストしてみました。
今までの環境構築テストで、録画自体はスクランブル解除なしでうまくいっていたというところまで確認は出来ていました。

結果

PT2の場合は、CPU使用率は低く抑えられた。
ピークで20%も使わないくらい。
W録画時にもこのような状況で、パケットのドロップは発生しなかった。

こういう状況なので、この仮想マシンにBCASカードリーダーを接続させ、
スクランブル解除までやらせてみた。
その結果もまた優秀でW録画時かつデコードありで、
CPU使用率は相変わらず低いままであった。

まとめるとPT2のほうが機器として良くできているということじゃないかと思う。
仮想マシンで録画ということを考えると、PT2は使える!ということになると思う。


KVMでデバイスパススルー その3


途中報告

確かにFedora14の環境下でKVM(0.13)を使うと、
デバイスパススルーの機能を用いて仮想マシン内で録画を行うことが出来た。

  • PT2
  • PX-W3PE

上記の2ボードで試してみたが、どちらでもひとまず録画が出来ることが確認できた。
すばらしい・・・。

ただ現時点では安定動作出来るかどうかは確認できていない

実験中1 (PX-W3PE)

PX-W3PEのほうが情報が少ないので、ネットに晒してみます。
どうも仮想マシン内で録画の際にCPU使用率が高い。
シングル録画時で30~50%ほど。W録画中では75~80%ほど。

しかもこれはスクランブルのデコードをしない状態でである。

スクランブルのデコードをした場合にはまず確実にドロップが発生する。

一応PX-W3PEのドライバ設定で、レジストリを変更しています。
・自動ゲインコントロール(ブースタ)
・内部ブースターの値は適当に0x0aあたり

このような状況のため、このボードの仮想マシン内録画は
デコードなし、シングル録画限定、
という制限を設けて使うのが精一杯かもしれない。

BonCasLink

別環境に用意したBCasLinkServiceに接続して、デコード処理をやらせる感じにしたらブルースクリーンが出たり、ドロップ多発したり色々発生した。

現時点の状態では、使用しない方が賢明。

W録画

どうにも安定して長時間録画できない。
シングル録画のみの使用に限定した方がいいかも。


KVMでデバイスパススルー その2


どうもネットを検索すると、KVMでデバイスパススルーを設定し、
仮想環境(ゲストOS)で録画出来ている、なんていう記事を見かけます。手元の環境では、録画できているけど常用できない、という状態なので、
他の人のうまくいっている環境は常用できるという点に着目して、
真偽を確かめてみたいなと思います。

うまくいく環境とは?

うまくいっている人の多くは、Fedoraを使用している。
CentOSでの報告もあるけど、Fedoraが多い傾向にある。

また、GUIでの設定で終わりという記載はあまりみない。
できた~という人はGUIで設定して終わっているようだが、きちんと記事にしている人は、コマンドラインでKVMのゲストを起動しているようにみえる。

デバイスはPT2を使用している。
他のPT1やPX-W3PEでうまくいっているという話を見ない・・・。
入手性の問題なのだろうか。あるいは、うまく動作するのがこれだけなのか。

調査方針

うまく行く率が高いFedoraをインストールしてみる。
KVMはOSインストール時には入れずに、後から導入する感じで。

デバイスパススルーできるKVMにもうまくいくバージョンがありそうなので。


Fedora15出た(しかし実験失敗)


Fedora14の環境をインストールしているうちに、Fedora15が出てしまいました。
やりたいことであるSPICEの部分も、仮想マシンマネージャから設定できるようになったとのことで、Fedora15のほうをインストールすることに変更してみました。

・・・

しかしながら、インストールして仮想マシンマネージャから仮想マシンを作ろうとしたら、エラーが発生。
どうもハードディスクか設定ファイルか書き込みに失敗するのか、仮想マシンそのものを作れず。
今のところGUIからはダメそうな感じでした。

ちなみにFedora14の初期状態では仮想マシン作成後、WinXPのインストール時のハードディスクフォーマット時で強制終了してしまう感じに。
ただ、qemu-kvmのアップデートを適用したらこれは無事に正常に進行するようになりました。

ただ、Fedoraの安定性の悪さは気になりますね・・・
仮想マシンを束ねる環境としては不安。

そんな中、見つけてきたのがこれ。
“Scientific Linux”

どうやらCentOSと同様のものらしいです。研究所向き。
調べてみるとRedhatLinux6相当にはなっているみたいだし、
CentOS6が未だに出ていない状況から考えると、こちらのほうも視野に入れて実験してみるのが良さそうです。
少なくとも、Fedoraよりは安心して使えそう(メンテ期間はながそうだし)


Fedora14のインストールで足止め(2)


1TBのディスクだったので1日半ほどかけて、

のコマンドを実行。
その結果、ようやくインストール時にハードディスクを見つけてくれました。
『BIOS RAIDメタデータ』の呪縛から逃れられた感じです。

これでやってみたいことのためにFedora14のインストールを続行できる♪