Oh!Super164 取り留めのない日記のような

もうすっかり元は取れただろうぐらいに遊ばせてもらった
ファームv1.11ではkernelも上がっていたのでソースCDをまたまた注文しておいた。￥1,050で改造できるなら安いものだｗ
これまで自分でmake installしたものをRPM化しているのだが、これがなかなか先に進まない。RPMを作るのにビルドが必要なのでSPEC書き、実行、放置、失敗、SPEC修正、実行、放置、失敗、、、を繰り返してしまう…orz 当然、LS-GL用のSRPMなど存在しないのでVineやFedoraから拝借してSPECファイルを書き換え作成するのだが、これがなかなか一発で決まらない。rpmbuildは一旦、ガチでコンパイルを行い仮インストして、そのファイルをRPMとして採用するので毎回フルにコンパイルが発生してしまう。
kernelのソースが届いたらiptablesでも入れて本格的に鯖化してやろうかとも思っているが、途中で飽きるかもしれないｗ

懐かしいのでビルドして入れてみた
かつてのDOS時代、FDやFLMTNはCUI上でのグラフィカルなｗシェルであった。そんなFDのクローンは随分前から存在していたのだが、LS-GLにも入るんだろうか？と試しにやってみると動作した。サイトにspecファイルも公開さえていたのでRPM化もしてみた。sambaで公開されているファイルもUTF-8指定すれば日本語表示もされ、なかなかのもんだｗ

ここんとこ暇だったのでLinkStationで遊んでいた
LS-GLは海外ではLS Proとして売られているらしく、既に独自でkernel開発とかも行われているというのを最近知ったｗ 当方は基本は純正で足りない機能をビルドして追加するというスタンスなのでさすがにkernelまで乗せ換える根気はない（ってか、普段は普通にNASとして使っているので壊すと面倒）。巷ではdebianに乗せ換えたりといろいろハッキングされているようだが、この値段で一粒で二度美味しいのは確かだ。
一応本体のfsには直接入れていないが、それでもmake installを繰り返すとわけがわからなくなるのでRPMを導入しようかとビルドしてみる。しかし、ここで問題が･･･というかおバカな疑問がｗ RPMそのものも当然複数の外部ライブラリを参照しているわけで、この中には自分でビルドして入れているものでRPMで管理したいと思っているものもある。そう、卵が先かニワトリが先かという状況だ。RPMが動かないと、これらをRPMパッケージにしても入れられない。最初からmake install状態にしとけばいいのだろうが、それではRPMによる管理という野望が･･･
これって、どうすればイイんすかね？いや、マジで・・・orz

前々からベータテストを行っていたVine 4.0の正式版が配布されていた
一番よく使っているVine、日本語に強く、初心者にも簡単という勝手なイメージで使っているだけであるが、2.6 kernelとなった4.0のisoイメージを落として寝ようと思いたつ。最近はLinkStationにいろいろダウンしたファイルを置いているので、isoもここに入れることに。しかし、ふとつまらない事を思いつく。何もわざわざパソコンからダウンして転送しなくても、LinkStation本体で直接ダウンすればイイじゃないか・・・
早速、シリアルでログインしwgetで落とそうと思ったら、wgetは標準では入っていない・・・orz ここで素直にPCからダウンすればイイのだが、妙に悔しいのでwgetのソースを拾ってきてネイティブコンパイルｗ なんか怪しいバイナリが出来上がったので実行してみると、動いてるっぽい。config時にSSLが無いとか言っていたのでhttpsでは無理なのかもしれないが、一般的なhttpならこれで落とせそう。深夜に自己満足に浸る・・・（小さいな＞オレ）
たまにはこういう無駄な手間を掛けてもイイじゃまいかｗ

ちと仕事が忙しく（正確には手間取ってｗ）ゆっくり触っていられないｗ
せめて本来のNASとして使えばよさそうなものを、電源すら入れていないｗ まぁ、Web用の鯖が常に起動しているので、ついそちらを利用してしまう。思いきってDebian化してしまえば後はパッケージでアプリを入れるだけで済むので楽なのだろうが、どうしても純正kernelで動作させたいのと、当方Debianに不慣れなので今更覚える気力もインストする技量もありませんｗ
折角、コンパイラらしきものを整備したのでソースからビルドしてみたいとは思うが、ちとオーバースキル過ぎる悪寒・・・

Apacheとperlは入ってはいるものの、mod_perlやperlのlibがまともに入っていない・・・
まぁ、NASなんだから必要最小限構成となっているのはあたりまえかｗ しかし、この辺りはクロスコンパイルが難しいってか、やり方が分かりません；； prelのライブラリはconfigureではなくperlで行なうようでホスト側でやるとホストのperl環境が反映されてしまう（当然ですね）。実機でコンパイル出来るようネイティブ用binutil、gcc、makeやらを作ってみる。怪しいながらコンパイル環境は整ったが、どうにもmod_perlがコンパイル出来ない。
うーむ、これは痛いｗ

まだ解析が進んでいないのか、所有者人口が少ないのか、当方の機種用のクロスコンパイラの情報をネットで見かけない。
丁度、先日ソースCDも届いたことだし、試しに作ってみるかと作業開始。binutilsはあっさり作れたが、gccがどうにもコンパイル出来ず途方に暮れる。glibcはソースが入っていないので、ソースCDのバイナリをそのまま使用したのだが、微妙に本体のと違う気が・・・。幸いな事に本体にも*.aファイルと入っているので、これをごっそり取り出す。configureの設定やら環境変数やらいじりながら試行錯誤しているうちにgccもコンパイルに成功したようなので、試しにkernelとかビルド。最後のインストのスクリプトでこけたが、コンパイル自体は成功したようだ。ってか、Makeを直接いじってるな、これ・・・。まぁ、世にまっとうなのが登場するまではしばらくこれで様子見するか・・・。
LS-GLにはsshが標準で入っているようなのだが、suコマンドが無い。rootでssh入るのも何だし、入ってrootに成れないのも不便なのでsuコマンドを早速ビルドすることに。しかしLS-GLはbusyboxを採用しているので、suだけを入れ替えることが出来ない。いきなりbusyboxで失敗すると大半のコマンドが全滅するので、従来のcoreutilsに入っているsuを使うことにした。coreutilsを拾ってきてクロスコンパイルしてみると、無事コンパイル出来た。suだけをLinkStationに持っていき実行してみると、ちゃんと動作するようだ。
これで、ビルドの環境は整った（かな？ｗ）