$ gcc -lfreeglut -lglu32 -lopengl32 main.c
main.o:main.c:(.text+0x1c): undefined reference to `_imp____glutInitWithExit@12'
main.o:main.c:(.text+0x3e): undefined reference to `_imp____glutCreateWindowWithExit@8'
main.o:main.c:(.text+0x60): undefined reference to `_imp____glutCreateMenuWithExit@8'
main.o:main.c:(.text+0xa0): undefined reference to `_imp__glutInitDisplayMode@4'
main.o:main.c:(.text+0xb9): undefined reference to `_imp__glutInitWindowSize@8'
main.o:main.c:(.text+0xd2): undefined reference to `_imp__glutInitWindowPosition@8'
main.o:main.c:(.text+0xf8): undefined reference to `_imp__glutDisplayFunc@4'
main.o:main.c:(.text+0x109): undefined reference to `_imp__glutReshapeFunc@4'
main.o:main.c:(.text+0x113): undefined reference to `_imp__glutMainLoop@0'
main.o:main.c:(.text+0x13e): undefined reference to `glClear@4'
（以下略）

大量のリンクエラーが出て(・3・)あるぇ～？となる。

解決方法・・・というか正しくは↓のように、コンパイル対象のソースを-lオプションより前に持ってくるである。

$ gcc main.c -lfreeglut -lglu32 -lopengl32

どういうわけか、この罠だけは毎度ハマっては、ライブラリを入れ替えてみたり小手先のマクロを定義してみたりして時間を無駄にしてしまうorz

前のエントリで発生していた音飛び問題が解決。

原因はインタリーブのデータを非インタリーブに変換する処理が間に合ってなかった模様。

この処理はNSFの再生でも行われてるし、その程度で処理落ちするか？って気もするが、全てインタリーブで処理するようにしたら奇麗サッパリ解決した。

疑ってごめんね、ExtAudioFileたん。

本腰を入れてMac用のオーディオプレーヤーを作成中。足掛け3年位作り続けてるけど、今回は本気。もりもり機能実装中・・・と行きたいところだが、ExtAduioFileを使った各種オーディオファイルの再生で、たまにノイズが出るバグが取れなくて苦悩中。

Core Audioのレンダーコールバックで要求してくるサンプル数を多めにとってみたが、若干の改善が見られるも解決には至らず。それならばと、デコード部分を別スレッド化して非同期でバックバッファを埋めるようにしても、これまた有意な改善は見られず。バッファのロックが足かせになってるかも？と思い、急ごしらえでバッファ2枚を使ったスワップ式にしてみても駄目駄目。

開発機は4年前のMacBook Proだけど仮にもCore 2 Duo 2.4GHzのマシンだから、例えデバッグビルドだとしても、たかがAAC程度のデコードで処理落ちするとは考えられない。そもそも、ExtAudioFile自体は最適化の有無の影響は受けないだろうし、処理中もまだまだCPUの余裕はある。

NSF（NES Sound Format:ファミコンのサウンド形式）の再生は問題なく出来てるから、ネックになってるのはExtAudioFileとしか考えられないんだよなぁ…。

むーん・・・分からん。

次はCore Audioに渡すフォーマットを32bit Floatの正準フォーマットにしてみるとしよう。

会社でこんなソースを見かけた。

class Hoge
{
public:
    static Hoge *Instance;
    static Hoge *getInstance() { return Instance; }
 
    Hoge() {
        Instance = this;
    };
 
    void initialize() {
        if (Instance == 0) Instance = new Hoge;
    }
    （略）
};
 
// シングルトン
static Hoge hogeInstance;
 
void doSomething()
{
    hogeInstance::Instance->func();
}

見かけたというか、同じ仕組みのクラスがあっちこっちに散らばってた。念のために言っておく、コードはこれで間違いない。何度も見直したからね。

色々と突っ込みどころはあるけど、まず、シングルトンを想定してるのにコンストラクタをpublicで書いちゃう男の人って……。せめて多重生成検知のassertくらい入れようず。

いやいやいや、グループ会社内で（自称）一番技術力が高いと公言してるところの、仮にも俺より高給取りで優秀なプログラマが書いたコードだ。きっと俺なんぞには考えもつかない、深遠なる理由があるに違いない。

でも、色々と考えてみたけど、やっぱり何がしたいのか解らなかった。しかし、メンバ変数を触らないメンバ関数は、クラスの実体が無くても正常に呼べるって事は解った（実験済み）。つまり、上のクラスのinitialize()は期待通りの動作をする。これがC++の仕様の範疇かどうかは知らない。

静的メンバ関数がヌルポで呼び出せる（static_cast<Hoge*>(0)→staticFunc();）のは知ってたけど、メンバ関数も大丈夫だとはねぇ…。よーく考えてみれば、確かにメンバ関数はそのクラスで共用だから、関数の実体は静的に存在してるだろうから呼べてもおかしくないはない。でもやっぱり気持ち悪い。

Mac mini鯖に繋いでるデータ置き用HDDがぶっ壊れた。ディスクユーティリティで修復を試みるも「Bツリーが壊れてて直せない」的なエラーで修復不能だった。

「それでもTimeMachineなら・・・TimeMachineなら何とかしてくれる・・・!!」と思ってバックアップを除いてみたら、最新のバックアップは2009年7月2日とか言ってるの。え？何それ？バカなの？死ぬの？

fsckを直接叩いてみると、BAD SUPER BLOCK: MAGIC NUMBER WRONGだとかLOOK FOR ALTERNATE SUPERBLOCKS? [yn]とか言われ、代替ブロックを探すも見つからず、newfsを使った方法でもダメで、もはやお手上げ状態。

壊れたHDDにはそれほど重要なデータは入ってないから、もし本当にデータが飛んだとしてもそんなに痛くはない（夜のお供（自重汁）が減る程度で済むwある意味一大事ではある）が、諦めるのも何なのでDiskWarrior 4をポチった。

結果、いとも簡単に修復完了。1分も掛かってないんじゃなかろうか。

そんなわけでDiskWarriorは神。それに引き換えDrive Geniusは………買ってはみたものの、どうすんのよこれ………。