私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレCygwin + MinGW + GCC 相談室 Part 6
gcc スレッド一覧へ / gcc とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
一応、言っとくけど、mingw32-windres だからね
windows版のwindresでは文字化けしないよ
windows版ので作ったものと比較したらサイズは同じで中身が微妙に違う
windows版のwindresでは文字化けしないよ
windows版ので作ったものと比較したらサイズは同じで中身が微妙に違う
windows版は落ちてたバイナリだけど、GNU windres 2.14.90 20040120
文字化けするのは、portsでコンパイルしたもので、GNU windres (GNU Binutils) 2.22
文字化けするのは、portsでコンパイルしたもので、GNU windres (GNU Binutils) 2.22
猫科研究所さんのとこにいろいろ書いてあったぞ
UTF-8じゃダメなんか
http://up-cat.net/?word=gcc%2C+windres%A4%C7%C6%FC%CB%DC%B8%EC%A4%F2%B0%B7%A4%A6%CA%FD%CB%A1&action=SEARCH
UTF-8じゃダメなんか
http://up-cat.net/?word=gcc%2C+windres%A4%C7%C6%FC%CB%DC%B8%EC%A4%F2%B0%B7%A4%A6%CA%FD%CB%A1&action=SEARCH
--language=0411とかも試したよ
ちなみにmingw32-gcc自体は化けないから、MessageBox()とかの漢字も全然問題なし
ちなみにmingw32-gcc自体は化けないから、MessageBox()とかの漢字も全然問題なし
FreeBSDと仮定するとlibiconvは/usr/localにインスコされるので
portsそのままのmingw32-binutilsだとiconvを認識してくれないんじゃないかな?
portsそのままのmingw32-binutilsだとiconvを認識してくれないんじゃないかな?
>>739の#if HAVE_ICONVの後に#error挟んでmakeしたらちゃんとエラーが出たので
認識はされているね
SJISで試したらちゃんとデコードできてるんだけど、出力するときにUTF-16の上位バイトと下位バイトが
入れ替わってるぽい。だから英語でも文字化けする
オリジナル
PUSHBUTTON "OK",0,205,162,50,14
PUSHBUTTON "キャンセル",1,259,162,50,14
Windows上のMinGW
PUSHBUTTON "OK", 0, 205, 162, 50, 14, 0x50010000
PUSHBUTTON L"\x30ad\x30e3\x30f3\x30bb\x30eb", 1, 259, 162, 50, 14, 0x50010000
FreeBSD上のmingw32-binutils
PUSHBUTTON L"\x4f00\x4b00", 0, 205, 162, 50, 14, 0x50010000
PUSHBUTTON L"\xad30\xe330\xf330\xbb30\xeb30", 1, 259, 162, 50, 14, 0x50010000
認識はされているね
SJISで試したらちゃんとデコードできてるんだけど、出力するときにUTF-16の上位バイトと下位バイトが
入れ替わってるぽい。だから英語でも文字化けする
オリジナル
PUSHBUTTON "OK",0,205,162,50,14
PUSHBUTTON "キャンセル",1,259,162,50,14
Windows上のMinGW
PUSHBUTTON "OK", 0, 205, 162, 50, 14, 0x50010000
PUSHBUTTON L"\x30ad\x30e3\x30f3\x30bb\x30eb", 1, 259, 162, 50, 14, 0x50010000
FreeBSD上のmingw32-binutils
PUSHBUTTON L"\x4f00\x4b00", 0, 205, 162, 50, 14, 0x50010000
PUSHBUTTON L"\xad30\xe330\xf330\xbb30\xeb30", 1, 259, 162, 50, 14, 0x50010000
似たような質問でごめん
Visual Studioから、mingwに寄生してるclang(3.1)に流れてきたんだけど
w32apiの、W系APIを使ってプログラムを組んで行きたいと思ってるのね。
今まではstd::wstringとか、L"文字列"、str.data()等を使い回していたから
こっちでも同じようにstd::wstringをAPIに利用したら、強制終了してしまうのよ。
これって、内部的には32bitのUnicode処理がされているからってことで合ってるの?
個人的には、極力シンプルな方法でUTF-16の文字列を使っていきたいと考えているんだけど
何か良い方法あったら教えて下さい。
ちなみに、ソースのファイルはUTF-8で書いているので、入力のほうは気にしていません。
Visual Studioから、mingwに寄生してるclang(3.1)に流れてきたんだけど
w32apiの、W系APIを使ってプログラムを組んで行きたいと思ってるのね。
今まではstd::wstringとか、L"文字列"、str.data()等を使い回していたから
こっちでも同じようにstd::wstringをAPIに利用したら、強制終了してしまうのよ。
これって、内部的には32bitのUnicode処理がされているからってことで合ってるの?
個人的には、極力シンプルな方法でUTF-16の文字列を使っていきたいと考えているんだけど
何か良い方法あったら教えて下さい。
ちなみに、ソースのファイルはUTF-8で書いているので、入力のほうは気にしていません。
>>739内の"UTF-16"のうち関数のなかにあるやつを"UTF-16LE"に書き換えたらいけた
入力ファイルがSJISの場合はオプションに"-c 932"が必要だった
入力ファイルがSJISの場合はオプションに"-c 932"が必要だった
>>762
>今まではstd::wstringとか、L"文字列"、str.data()等を使い回していたから
>こっちでも同じようにstd::wstringをAPIに利用したら、強制終了してしまうのよ。
>これって、内部的には32bitのUnicode処理がされているからってことで合ってるの?
全然思い違いをしているよ
>今まではstd::wstringとか、L"文字列"、str.data()等を使い回していたから
>こっちでも同じようにstd::wstringをAPIに利用したら、強制終了してしまうのよ。
>これって、内部的には32bitのUnicode処理がされているからってことで合ってるの?
全然思い違いをしているよ
mingwrt-3.20-2-mingw32-dev.tar.lzma
こいつ入れるとコンパイルしたバイナリがSIGSEGV
こいつ入れるとコンパイルしたバイナリがSIGSEGV
Mingwでメモリーリークを検出するために効率のいい方法ってありますか?
Linuxだとvalgrindとか、Macだとleaksコマンドみたいな奴があればベストなんですが。
Linuxだとvalgrindとか、Macだとleaksコマンドみたいな奴があればベストなんですが。
>>771
ありがとう。確かに使いやすそうですね。後でトライしてみます。
ちとあれから色々と調べたところ、
http://stackoverflow.com/questions/413477/is-there-a-good-valgrind-substitute-for-windows
こんな書き込みを見つけて、その中に
Dr.Memory(http://code.google.com/p/drmemory/)
ってのが紹介されていたんですが、こいつもいけてそう。
でも、かなり重いですね。まあ、valgrindもそうですがw
ありがとう。確かに使いやすそうですね。後でトライしてみます。
ちとあれから色々と調べたところ、
http://stackoverflow.com/questions/413477/is-there-a-good-valgrind-substitute-for-windows
こんな書き込みを見つけて、その中に
Dr.Memory(http://code.google.com/p/drmemory/)
ってのが紹介されていたんですが、こいつもいけてそう。
でも、かなり重いですね。まあ、valgrindもそうですがw
SIGSEGVしないmingwrt-3.20-2-mingw32-dev.tar.lzmaが来てた
>>782
そのくらい、自分の頭で考えて何とかしてね
そのくらい、自分の頭で考えて何とかしてね
あざっす^^
runas使ってmakeって向いてないのか。。。
一つコンパイル終わったら終了しやがった。。。
一つコンパイル終わったら終了しやがった。。。
もしかして、ユーザーが一人だけを想定しているから最初の部分が書き込み可能なら他は関係ないのでしょうか?
でもmakeをすると
AR libavcodec/libavcodec.a
C:\bin\MinGW\bin\ar.exe: libavcodec/: Permission denied
make: *** [libavcodec/libavcodec.a] Error 1
と表示されるのでどこかの所有権がおかしいと思うのですが
状態は
drwxr-xr-x 11 km Administrators …… libavcodec
-rw-r--r-- 1 km Administrators …… libavcodec/libavcodec.a
-rwxr-xr-x 1 km Administrators …… /mingw/bin/ar.exe
です
でもmakeをすると
AR libavcodec/libavcodec.a
C:\bin\MinGW\bin\ar.exe: libavcodec/: Permission denied
make: *** [libavcodec/libavcodec.a] Error 1
と表示されるのでどこかの所有権がおかしいと思うのですが
状態は
drwxr-xr-x 11 km Administrators …… libavcodec
-rw-r--r-- 1 km Administrators …… libavcodec/libavcodec.a
-rwxr-xr-x 1 km Administrators …… /mingw/bin/ar.exe
です
やってみたこと
1.makeに-nオプションをつけてコマンドを見てみたところ、544個のobjectファイルから .aライブラリを作ろうとしていた
2.oファイルにlsをしてみたら、全て存在していてpermissionも問題なかった
3.Cドライブにchkdskしたが異常なし
むむむ……
>>794 cacls c:\bin\MinGW\msys\1.0\home\km /C /E /T /G myPC\km:wしてみたが変わりませんでした
1.makeに-nオプションをつけてコマンドを見てみたところ、544個のobjectファイルから .aライブラリを作ろうとしていた
2.oファイルにlsをしてみたら、全て存在していてpermissionも問題なかった
3.Cドライブにchkdskしたが異常なし
むむむ……
>>794 cacls c:\bin\MinGW\msys\1.0\home\km /C /E /T /G myPC\km:wしてみたが変わりませんでした
cacls c:\bin\MinGW\msys\1.0\home\km /C /E /T Everyone:F
makeに-nオプションをつけた出力を確認したところ、マルチライン展開するときに限って
printf "AR\t%s\n" libavcodec/libavcodec.a; ar rc libavcodec/libavcodec.a libavcodec/[CR]
……(xxxx.oが多くあります)
……
と展開していました
(makefile上の記述はこう)
$(SUBDIR)$(LIBNAME): $(OBJS)
$(RM) $@
$(AR) rc $@ $^ $(EXTRAOBJS)
$(RANLIB) $@
この行末のlibavcodec/が余分なのでここを\に書き換えてシェルスクリプト?にコピーして走らせたらライブラリが作れました
色々ありがとうございました
printf "AR\t%s\n" libavcodec/libavcodec.a; ar rc libavcodec/libavcodec.a libavcodec/[CR]
……(xxxx.oが多くあります)
……
と展開していました
(makefile上の記述はこう)
$(SUBDIR)$(LIBNAME): $(OBJS)
$(RM) $@
$(AR) rc $@ $^ $(EXTRAOBJS)
$(RANLIB) $@
この行末のlibavcodec/が余分なのでここを\に書き換えてシェルスクリプト?にコピーして走らせたらライブラリが作れました
色々ありがとうございました
えーと
GNU bash, version 3.1.17(1)-release-(i686-pc-msys)
でしょうか
GNU bash, version 3.1.17(1)-release-(i686-pc-msys)
でしょうか
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / gcc スレッド一覧へ
みんなの評価 : 類似してるかもしれないスレッド
- Cygwin + MinGW + GCC 相談室 Part 8 (938) - [97%] - 2022/10/28 8:00
- Cygwin + MinGW + GCC 相談室 Part 7 (996) - [97%] - 2014/9/21 2:15
- Cygwin + MinGW + GCC 相談室 Part 5 (981) - [97%] - 2011/4/6 2:32
- Cygwin + MinGW + GCC 相談室 Part 4 (1001) - [97%] - 2010/3/23 18:31 ☆
- Cygwin + MinGW + GCC 相談室 Part 3 (1001) - [97%] - 2008/9/12 0:04 ★
- 【激遅】AppleGCC【絶望】 (111) - [1%] - 2010/1/15 10:31
トップメニューへ / →のくす牧場書庫について