カテゴリー: Uncategorized

modelsimがubuntuで起動しなくて困っていた。
以下長々と書く内容をまとめるとライブラリが足らなくて起動できなかったようだ。
vsimというのがmodelsimの実体なのだが、実行しても”No such file or directory”と出てきて起動しなかった。
fileコマンドを使って見てみると
./vsim: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.4, BuildID[sha1]=be0130f25d5768e095133f4ed1d9d69902768269, stripped
と出てくるのでやはりELFでi386の実行ファイルだ。/lib/ld-linux.so.2はさすがにあるだろうと思っていたのだが、探して見たら無かった。どうやらこのマシンには/lib64/ld-linux-x86-64.so.2しか無いようだった。”ldが無い”というのはちょっと最初は信じられなかったがどうやら調べてみるとi386用のlibcが無いらしい。
今までアプリケーションはapt経由かソースを持ってきてコンパイルするかだったのでこの様なことになったのだろう。
ということで
sudo apt install libc6:i386
をした後に./vsimを実行すると
./vish: error while loading shared libraries: libX11.so.6: cannot open shared object file: No such file or directory
というメッセージに変わるのでここからはエラーで出てきたライブラリのi386版をインストールするだけで済むので楽になる。
以下のコマンドで必要だったライブラリを一括インストールできる。
sudo apt install libc6:i386 libx11-6:i386 libxext6:i386 libxft2:i386 libncurses5:i386

#x86のライブラリが全然無いなんて思ってなかった

元々Windowsがインストールされている環境からUbuntuをインストールすれば簡単にデュアルブートさせることができた。

しかしCentOSをここに入れたら詰まったのでメモ

元々OSがインストールされているということと、パーティションは自分で設定したかったので手動で設定することにした。

しかし「partition で ext4 ファイルシステム を 使用する場合、grub2によって組込まれる core.img用領域 が sda には不足している可能性があります。」というエラーがどうしても解決できなかった。

どうやらgrubが問題ということでブートローダのインストールをしないことで解決することができる。

おそらく新しいパーティーションだとここまでで済むはずだが、自分は元々ubuntuが2個入っているうちの1つを潰してCentOSをインストールした関係で間違えてgrubを潰してしまった。そのせいでlive cdから修復させざるを得なかった。この方法は以下を参考にしてほしい。

https://askubuntu.com/questions/145241/how-do-i-run-update-grub-from-a-livecd

研究をしていて壁に行き詰まった。
自分の先行はコンピュータアーキテクチャなのだが、コンピュータアーキテクチャを変えようとすると大体今の汎用プロセッサよりプログラミング、コンパイルが難しくなる。
プログラミング、コンパイルの容易さを表す指標がプログラマビリティなのだが、論文を読んでいてもプログラマビリティが定量的に評価されていない。

定量的に評価されていないものが良くなった、悪くなった、あれより良い、これより良いと言われたところでそれを証明することが出来ない。定性的な評価はされていてもどの程度信頼性を置いて良いものか分からない(これは定量的評価が可能であっても)。

自分としてはプログラマビリティの高いアーキテクチャが作れたつもりなのだが、そのアーキテクチャのプログラマビリティがどうなのか人に説明することが難しい。

こんなんでは新しいISAの形を考える分野が縮小してしまうのではないか。

gem5を使ってみたら”kernel too old”というエラーが出てしまい使えなかった。
ぐぐってみると多くの人がここの部分で躓いていてそれらの回答はいつもソースコードを変えなければならないものだった。

どうにかならないのかなと思いつつメモ。

ターゲットがARMの場合
src/arch/arm/linux/process.cc
の
unameFunc32の中の
strcpy(name->release,”ここにバージョン名”);
という部分のバージョン名を今のカーネルのバージョン名に合わせることで解決した。
ちなみに今のカーネルのバージョン名はuname -rで取得できる。

ターゲットがX86の場合は
src/arch/x86/linux/process.cc
のようだ

アーキテクチャのシミュレータにはgem5を使うと良いと聞き使ってみようとしたが、
以下のようなビルドエラーが発生しコンパイルできなかった。
これが解決出来たのでメモ。

tomoya@tomoya-DESK:~/gem5$ scons -c
scons: Reading SConscript files ...
AttributeError: 'NoneType' object has no attribute 'group':
  File "/home/tomoya/gem5/SConstruct", line 764:
    if not as_version or compareVersions(as_version, "2.23") < 0:
  File "/home/tomoya/gem5/src/python/m5/util/__init__.py", line 131:
    v1 = make_version_list(v1)
  File "/home/tomoya/gem5/src/python/m5/util/__init__.py", line 127:
    return map(lambda x: int(re.match('\d+', x).group()), v.split('.'))
  File "/home/tomoya/gem5/src/python/m5/util/__init__.py", line 127:
    return map(lambda x: int(re.match('\d+', x).group()), v.split('.'))

解決するにはexport LANG=Cを実行してからコンパイルすれば良い。

検索しても見つからず最終的にエラーが起きている部分をPrintfデバッグで突き止めることとなった。トホホ

プログラマーという職は100年後も残っているだろうか。

情報工学を扱っている人間としては残って欲しい気持ちが半分、残ってほしくない気持ちが半分だ。

なぜかって、当然プログラミングを機械が行う時代が来ると思っているからだ。

PEZYは本気でシンギュラリティを目指している。計算量的に十分なハードウェアが出来るのは時間とお金の問題だろう。(もしかしたら政治的な問題にも発展するかもしれないが)

そしてソフト的な面で言えば、Googleがやってくれると信じている。
googleがどの程度中を作れているかは分からないが、きっとやってくれるだろう。

僕はこの2社がコンビネーションすることでシンギュラリティに達成出来ると思っている。つまりプログラミングの行為そのものが人間が機械に頼むという行為に取って代わられる時代になると思っている。

一方で計算機科学自体が取って代わられることも機械学習の理論が廃れることも無いだろう。消されるかもしれないのは人間と機械の間のインターフェイスを埋めるというあまり本質的ではない部分だ。

基礎を大事にして勉強していきたいと今一度思う。

この記事は前の記事を誤って消してしまったので思い出して書いています。間違いがあったらご指摘頂けると嬉しいです。

Androidでstd::to_stringが使えないという事態に遭遇しました。

これはcocos2d-xと言うopenGL系のライブラリを使ってゲームを作っていた時のことなのですが、std::to_stringがundefinedになってしまってリンクできないということがありました。

どうやらこれはgccのARMEABIという ABI(スマホでよく利用されているARMアーキテクチャのCPUで使われているABI)向けの標準ライブラリのバグのようです。

私はgccではなく、clangを代わりに使うことでこのバグは回避しました。