GCC 5.1 と C++ライブラリのリンク

日記

昨日 Audacious の ebuild ファイルの更新をして、 gtk+:2 か gtk+:3 かの選択を可能にした


さて、 GCC が 5.1 にバージョンアップをし、高速・高性能になり、近年の規格への準拠も進んだ。 LLVM/ClangがApple等に支えられて激しく追ってきているので、 フリーソフトウェアの牙城である GCC の向上も著しい。 (GCC 5 の最初のバージョンは 5.1 で、 5.0 は無い)

GCC 5.1 は C++11 で ABI compatible で無くなった。そのため、リンクで失敗することが有る

cxxflags に -D_GLIBCXX_USE_CXX11_ABI=0 を入れると、とりあえず回避可能

だがいずれにせよ、 GCC 5 に移行をせねばならない。 ライブラリと、それとリンクするソフトウェアをリビルドせねばならない


Gentoo で、cmake と jsoncpp で填ったが、 cmake は USE="internal-jsoncpp" で再インストールを行い、 そして jsoncpp をその cmake で再インストール。 その jsoncpp でまた cmake を再インストールして解決した。

cmake のビルドには jsoncpp が必要だが、jsoncpp は cmake でビルドする。 そのため、最初には cmake は 添付の jsoncpp でビルドを行い、 それでインストールをした cmake で jsoncpp をビルドするわけである

今回は jsoncpp が旧いので更新をしたいのだが、 ビルドしようとすると cmake がエラーを出すので、 cmake のビルドからやり直したのである

このように、自ら考えないと、 Gentoo や フリーソフトウェアは動かない。 学習(俗には「勉強」というキモい表現が流行り、親からも学校でも教えられる。キモい)ではなく、 研究をせねば使えない。

(対して Windows や macintosh は、学習・習得するためのOSであり、到達度を試す資格試験まである偏狭世界だ。 ちなみに LPIC 等は、フリーソフトウェアではなくオープンソース世界なので、あんな資格試験が在る。 だが、LPIC なんかやっても潰しは利かない。UbuntuをやってUbuntuに詳しくなって apt を使いこなそうが GNU は使えないのと同じである)


こうしてできた cmake で、 freshplayerplugin をビルドして試してみた。 Google Chrome の Flash プラグインが Firefox でも動く https://github.com/i-rinat/freshplayerplugin

Gnash も手元にはあるのだけれども、Gnash は互換性でどこかおかしいこともある。 あと、VA-API 対応でビルドしようとしたら失敗したので、無しにしているから遅い

ただ、 freshplayerplugin は、プロプライエタリのプラグインを動かすわけであり、 Gnash が良ければそれに越したことはないのだが。

まあ そもそも Macromedia Flash なんて、「酷いインタフェイス」 って奴だが

インタフェイスで思い出した。もはや同人誌といっても過言ではない『I/O』で、インターフェイスをテーマにした特集が載っていて、 QWERTY キーボードは非効率的だが云々と書いてあったが、QWERTY は健康を害するし、所謂「人権侵害」であり、所謂「バリアフリー」(ユニヴァーサルデザイン)の対極であり、規格的には滅びなければならない。 効率だけの問題ではない、問題の所在を取り違えている

同様に、 Flash も「人権侵害」であり、表示や操作性が特異で「バリアフリー」で無いわけだが。 見えない人や、ポインティングデヴァイスの動かせない人のことを想おう

翻ってフリーソフトウェアを観ると。 俗に「学習障害」「学力低下」と謂われ混同されがちだがつまり衆愚・奴隷型の「思考停止」の「勉強」と「頑張る」の人達には、フリーソフトウェアは使えない。 脳神経と生活習慣のリハビリと、時間感覚を緩めて正常なヒトに戻るためには、 フリーソフトウェアも良いリハビリプログラムだ。脳神経も働かなければ劣る(「廃用性の原則」)。 とはいえ、本当にどうしようもない、診断書が出ない自覚の無い、真性の「要介護者」「認知症」は数えきれない程(数千万か1億か居る)が、彼らにはフリーソフトウェアは死んでも解らないだろう(幼児期以前からやり直して洗脳解くのが最初か?)から、 Ubuntu かなんかで適当に「御茶を濁す」くらいしかないのだろう。

その辺に、カノニカルとシャトルワースの活躍の場が有り申す。良かったね!

MATE Tweak の ebuild ファイル

MATE Tweak というのが Ubuntu 方面で創られているらしい。 https://launchpad.net/ubuntu/+source/mate-tweak GNOME Shell 用からの fork であるようだ。

そこで、 ebuild ファイルを造って wjn-overlay に入れた。 http://repo.asis.li/

もうひとつ、 lightdm-gtk-greeter-settings というのが在るらしい。 https://launchpad.net/lightdm-gtk-greeter-settings

そこで (以下同文)

この2つは、 Ubuntu の JP 方面でお馴染みの、 Software Design 辺りでお馴染みの、 あわしろいくや 氏の記事を見て知った。 http://gihyo.jp/admin/serial/01/ubuntu-recipe/0373


それでまた、そういや kkc という変換エンジンがあったな、と思い出した。 試してみたいが、性能は Mozc より劣るのだろう

Mozc (Google 日本語入力)の懸念点は、俗に謂う「クラウド変換サービス」である点である。 この点は、近頃の 名簿屋から購入して迷惑DM送ったことでよく知られる徳島のATOKにしろ、 あの百度としめじ辺りにしても、同様だ

だから、kkc は気になる。 https://github.com/ueno/libkkc

ちなみに、 Fcitx で kkc を利用するには併せて https://github.com/fcitx/fcitx-kkc

SKK だの kkc だの、紛らわしい名称なのがなんとも困るが


近頃の Gentoo コミュニティを観ていると、何時まで経っても ebuild の更新をしないとか、 "whitespace"としかコミットメッセジに書かない意味不明の奴とか居て、なんだか阿呆なものである。

Audacious の ebuild が何時まで経っても version bump しないので気になって bug リポ見たら、 GTK+:2 か GTK+:3 かで喧嘩寸前になって放置されて、皆逃げている。 (最近に Audacious (upstream) は、原則を GTK+ 2 に戻し、 GTK+ 3 をオプションにした。 まあ、「軽い」プレイヤとしては GTK+ 2 が妥当であるのだが、 GTK+ 3 派としては「退化」に見えて気に入らないらしい。)

このサイトは今 Nikola で生成している。 upstream のバージョンアップに早く追随をするために、ebuild は自作をしている。 Nikola の最新版は 7.4.1 だが、必要な Python モジュールのいくつかは特定のバージョンでなければならない。 そうしないと動かない。 さっきも、nikola が動かなくて、doit の ebuild を用意してアップグレードをして解決した。

思うにどうも、物事は臨機応変で価値観に絶対はないのに(だからこそGentooはchoiceなのに)、近頃の Gentoo のコミュニティは、エゴイスティックな価値観で自己防衛に必死になる弱々しい人々が何人も居て、 いちいち喧嘩をして、ユーザのことや衆目を気にしていない。 退潮である


ところで、 BitBucket が CNAME 機能の廃止をする予定らしい。 「もっと重要な機能に注力したい」そうだ。 そのため http://repo.asis.li/ の URL も、 CNAME ではなく、リダイレクトに換えた。

GnuTLS を 3.4.0 にアップグレードすると、リビルドが必要

今更の話題だが、GnuTLS http://www.gnutls.org/ が西暦4月8日に 3.4.0 にバージョンアップした。 ちなみに、 GnuTLS の前提となる libnettle (Nettle) http://www.lysator.liu.se/~nisse/nettle/ も同時期にアップグレードをした。

GnuTLSにしても、 Nettle にしても、ライブラリであり、アプリケーション・ソフトウェアではない。

GnuTLS 3.4.x シリーズは、 3.3.x シリーズとは ABI compatible ではない 。 そのため、 GnuTLS に dependent なソフトウェアもリビルドをしなければならない

さらに、 3.4.0 では、 一部の API が変えられた 。 そのため、dependent なソフトウェアの一部は、 code を書き換えねばビルド不能。


Gentoo では、gnutls-3.4.0 を gentoo リポジトリに入れた後に気づき、あわてて hard mask を掛けるという間抜けな事態 になった。 要は、安易に gnutls-3.4.0 をインストールすると、他のリビルドもしなければならず大変なのみならず、 GnuTLS 3.4.x 未対応のソフトウェアはリビルドに失敗するという凄惨な事態に陥る わけである。 順って、対応をさせるためのパッチを作成するか、 upstream がバージョンアップするのを待たねばならない。

この件については、 ウェブサイトなどでの広報は不十分 であるように思われる。 「hard mask かけたからいいだろう」、と思っているのだろう。

しかし考えるに、どのパッケージを改修せねばならないか、パッチを書いたりするには、相当の労力が要る。 広報して、より多くの人にバグリポートを投稿してもらったほうが早いだろう。 そういう力の入れ方をしたがらないところが、閉鎖的、あるいは拒絶的なのだ。 また、 English だけで、バグリポやせいぜいフォーラムでガタガタやっているだけだから、人が集まるのにも限りがある。

中国人や韓国人や日本人や、その他大勢を無視しているわけである。

言い換えれば、「英語を いつも 読む人でなければ管理をしえない」ということだ。

ちなみに私は、GnuTLSをアップグレードしたが、 API 変更に対応させるためのパッチを書くのが面倒なので、不要なソフトウェアをアンインストールして解決をした。


Gentoo でなくとも、自分でビルドをしていれば、嵌る。

例えば Arch の AUR がそうだ。

Arch は早くにアップグレードをしてくれるのが、利点でもあり欠点でもある。 sudo pacman -Syu なんてやっているだけで、ガンガンとアップグレードをしてくれ、 驚異的な新鮮さのディストリビューションだ。

Arch でも、 AUR を用いなければ引っかからない。 GnuTLS にしてもそうだが、 dependent のパッケージもリビルドしてバイナリで撒いてくれているから。

私のところでは、 Libav を AUR を用いて code からビルドしていたので、それが引っかかった。 (Arch では通常は ffmpeg であるから、 Libav はビルドする。)

Arch に関しても、 GnuTLS の件はアナウンスが足りない。 尤もArchについては、「自分でビルドしたんだから自分でなんとかしろ」という論理はある。 Arch のシンプリシティ(簡単さ=単純さ)という理念からすれば、そもそも AUR を用いることは良くはない。

しかし そもそも Arch の "Latest News" の最新記事は、 "xorg-server 1.17.1 is now available "(2015-02-15) である(2015-04-30 現在) 。 やる気あるのか?

比較すれば、Gentoo なんて、4月馬鹿に、(笑えない)うるさいウェブサイトを一日以上晒していたくらいだ。 Gentooは、やる気のもち方を根本的に間違えている

wjn's repos' info.

  Japenese , English