|▽￣)ノ なページ再帰

permanent link

dll から def を生成しライブラリー アーカイブ( a )を作成します。

ここで使用した pexports は Ubuntu の MinGW 関連パッケージに収録されてないようです。 MinGW 公式サイトに pexports 単体でソースとともに置かれています。昔は mingw-utils にまとめられてました。

今は gendef を使うほうが楽なのかな？ gendef は mingw-w64 では標準で付いてきます。 gendef target.dll で def ファイルが作成されます。

例。

pexports msvcrt-ruby18.dll | sed "s/^_//" > msvcrt-ruby18.def
dlltool -d msvcrt-ruby18.def -l libmsvcrt-ruby18.a

lib を作るには、このようにします。 link /lib は lib コマンドと同じです。 link コマンドは vc のコマンドです。

 link /lib /def:msvcrt-ruby18.def /OUT:msvcrt-ruby18.lib /MACHINE:x86 /NOLOGO

MinGW - Minimalist GNU for Windows - Browse /MinGW/pexports at SourceForge.net
http://sourceforge.net/projects/mingw/files/MinGW/...

MinGW - Minimalist GNU for Windows - Browse /MinGW/Utilities/mingw-utils at SourceForge.net
http://sourceforge.net/projects/mingw/files/MinGW/...

MinGW - Minimalist GNU for Windows - Browse /MinGW/gendef/gendef-1.0.1346 at SourceForge.net
http://sourceforge.net/projects/mingw/files/MinGW/...

VMware Player のバージョンによっては %TEMP%\VMwareDnD の下に、ディレクトリーとファイルが削除されずに残ります。このディレクトリーはゲストからホストへ Drag and Drop する際に下位ディレクトリーが作られ、ファイルが保存されます。

configure が mingw nm を見つけてくれない場合に発生する。 NM の値も "link -dump -symbols" のようになっている。 babl, gegl ではそうだった。

configure が nm コマンドを探す際に --target の値と組み合わせて検索する。たとえば i686-w64-mingw32 であれば、 i686-w64-mingw32-nm を探す。 --target の値と配置された*-nm の名前が異なる場合、このトラブルが発生する。

libtool の config を書き換えても( allow_undefined_flag を supported に、 always_export_symbols を yes にする) shared でリンクされず、次のような警告が表示される。 gegl をビルドしていたときの make ログ。

 *** Warning: linker path does not have real file for library -lgegl-0.1.
 *** I have the capability to make that library automatically link in when
 *** you link to this library.  But I can only do this if you have a
 *** shared version of the library, which you do not appear to have
 *** because I did check the linker path looking for a file starting
 *** with libgegl-0.1 but no candidates were found. (...for file magic test)
 
 *** Warning: libtool could not satisfy all declared inter-library
 *** dependencies of module affine.  Therefore, libtool will create
 *** a static module, that should work as long as the dlopening
 *** application is linked with the -dlopen flag.

libtool に -lgegl-0.1 を渡しているが -L${PWD}/gegl/.libs ( libgegl-0.1.dll.a へのパス)を渡していない場合に発生した。 -L${PWD}/gegl/.libs -lgegl-0.1 で期待通り shared でリンクした。

mingw ld に渡すオブジェクト引数に順序が決められていました。現在はこの制約はなくなっているように見えます（未確認）。いっぽう mingw ld 固有ではない c++ に一般的に見られる問題があります。 c++ から c 関数を呼び出す場合に問題になります。

c++ から c 関数を呼び出すには、その関数が c で定義されていることを示すために extern "c" {} で宣言を囲む必要があります。 extern "c" {} で囲まれていない extern された c 関数は c++ から見えません。リンカーはこのことを考慮したメッセージを出力しません。一見すると問題のないリンクであっても undefined reference to '...' のように関数が未定義のエラーと表示されます。

gettext 0.18.1.1 のビルドで遭遇し、手間取りました。 gettext はビルド プロセスにおいて c++ で定義された POD クラスを c 関数宣言に拡張するプリプロセッサを使用しています。この moopp ( Minimal Object-Oriented style PreProcessor ) に問題があり、 c で実装さた関数が c++ から見えなくなっていました。

gcc(g++) に -static-libgcc を付けた場合に次のようなエラーが返ることがある。 libgcc_eh.a と libgcc_s.a のあいだにエクスポート関数の衝突が起きている。

multiple definition of `_Unwind_SjLj_Register'

ググると、解決方法として --allow-multiple-definition を ld に渡すようにと書かれていることがある。 -static-libgcc を付けた場合の libgcc_eh.a と libgcc_s.a の関数の衝突はバグらしい。 specs を読むと、gcc が -lgcc_s -lgcc を追加している。 -static-libgcc が指定された場合は -lgcc -lgcc_eh にしなければならないようだ。

Bug 879084 -- Symbol conflicts when building a MinGW binary with exceptions and -static-libgcc
https://bugzilla.redhat.com/show_bug.cgi?id=879084

libtool を使用したリンクでは libtool に設定が埋め込まれている。これを修正する。下記は -static-libstdc++ も行っている。

sed -i -e'/^postdeps=/{s/-lstdc[+][+]//}' \
       -e'/^postdeps=/{s/-lgcc_s -lgcc /-lgcc -lgcc_eh /g}' \
       -e'/^archive_cmds=/{s/-nostdlib/-static-libgcc -static-libstdc++/}' \
       -e'/^\s\+\\$CC\s\+-shared/{s/-nostdlib/-static-libgcc -static-libstdc++/}' \
       -e's/^predep_objects=".\+"/predep_objects=""/' \
       -e's/^postdep_objects=".\+"/postdep_objects=""/' \
       libtool

configure と make と cmake のオプション引数の対応。

configure	make	cmake
--prefix=		-DCMAKE_INSTALL_PREFIX:STRING=
	CFLAGS=	-DCMAKE_C_FLAGS:STRING=
	LDFLAGS=	-DCMAKE_EXE_LINKER_FLAGS:STRING=

公式ビルドや他の野良ビルドとの衝突を避けるために portable 化を行う。

etc\fonts\fonts.conf を書き換える。3つある <cachedir> タグのうち ~/.fontconfig を残して2つを削除するかコメントアウトする。

環境変数 HOME, GEGL_SWAP を設定する。 v2.9 では GIMP2_DIRECTORY も設定する必要がある。

set HOME=%DISTROOT%\home\%USERNAME%\%COMPUTERNAME%
REM set GIMP2_DIRECTORY=%HOME%\.gimp-2.9
setGEGL_SWAP=%HOME%\.gegl-0.3\swap

環境変数 PATH は gimp をインストールしたディレクトリーの bin のみに置き換えていいのかもしれない。 PATH には2種類ある。通常設定されている PATH は process の PATH だ。親プロセスから継承される。 system ははじめに設定される PATH だ。 system の PATH を取得できるのであればそれと連結し、 process に設定する。

コンピューターに libgimp-2.0-0.dll がないため、プログラムを開始できません。この問題を解決するには、プログラムを再インストールしてみてください。

gimp のプラグインを導入しようとプラグインを直接実行すると、このようなエラーが表示される。正しくは、 gimp の plug-ins フォルダーにファイルをコピーすることでプラグインが導入される。拡張子が exe であるため、もしくはインストーラに慣らされて、インストーラーと誤解し実行してしまうようだ。 README などの説明をよく読みましょう。

このようなプラグインは、 gimp をインストールしたフォルダーの下にある plug-ins フォルダー、ユーザー データーのフォルダーの下にある plug-ins フォルダー、自分で決めたフォルダーのどれかにファイルをコピーし(再)起動すれば使えるようになるはずです。

プラグインの置き場所を決め、gimp がそこを検索できるようにする方法を説明します。プラグインの置き場所を、アドレスが半角英数字と一部の記号からなり、書き込み読み取り権限のある場所にフォルダーを作成します。 gimp のメインメニューから編集 -> 設定を選びます。左のツリーからフォルダーの下階層を開き、プラグインを選択します。右の白紙アイコンをクリックし、次にフォルダー アイコンをクリックし、プラグインの置き場所を探し選択し OK ボタンを押します。設定ダイアログの右下の OK ボタンを押してダイアログを閉じます。再起動します。

2015/2/15sun VMware Player を記述。-static-libgcc のトラブルを記述。gimp の portable 化を記述。libgimp-2.0-0.dll が見つからないを記述。 dll, def, a, lib に追記。
2011/1/23sun dll, def, a, lib を記述。
2010/12/10fri ページを分割しました。
2010/9/23thu memo に追記。
2010/9/1wed memo を記述。