元スレCygwin + MinGW + GCC 相談室 Part 7
gcc覧 / PC版 / みんなの評価 :
前へ
151 = :
どのg++だよ。自分でビルドしたならまずそれを疑うべきだろ
またg++で作成したexeで古い環境ではサポートしてないAPIやライブラリを使ってれば当然まともに動かない
そして正当な指定と思い込んで実は適切でないコンパイルオプションを指定してコンパイルすればやっぱり問題はおきる
152 = :
あれか、dll依存でビルドしておいてexeだけ持っていったとかだろ
158 = :
理由は、エクリプスがstd:int64_tがマクロで隠されていると思い込むバグでした。
しかも<cstdint>をincludeしなくてもstd::int64がつかえるのはなぜですか？
159 = :
>>158
本日Keplerが出たから入れ替えたら直ってるかな
後からやってみる
160 = :
KeplerにしたらDistro MinGWをMinGW GCCとしてツールチェーンで認識しなくなった
いろいろ検索してみたら、どうもレジストリを見ているらしい
取り敢えずアンインストール情報に適当にDistro MinGWを登録したら警告は出るけど
環境変数はうまく設定出来るようになったので実用上は問題はない
しかし気持ちわるいな
MinGWのある場所を検索する方法が変わったのか？
162 = :
最終リンクを通過できない。どうしたらいいんだ
164 = :
>>162
とりあえずリンクするライブラリのパス(-L で指定するやつね)が
mingw32 用のを指しているか確認すべき。
そっちの環境がわからんが、ひょっと見では cygwin 用と mingw 用が混じっている指定に見える。
あと、ftell() とか fseek() の入った素の C ソースを g++ でコンパイルしているのが気になる。
デフォルトでは gcc とリンカの動き方が違ったと思う。
リロードして >>163 ので気付いた。
コンパイラは 64bit 版なのに(ftello64() をリンクしようとしてる)ライブラリは 32bit 版使ってるね。
64bit 用はうちの環境では /usr/x86_64-w64-mingw32/sys-root/mingw/lib にある。
i686-pc-cygwin は 32bit 用だ。
configure での指定を見直すべきかな。
165 = :
コンパイラとライブラリを合わせてもfteelo64がリンクできなかったら
configureのオプションに--disable-largefileを追加
リンクは通るがでかいファイルが処理できなくなるかもしれない
167 = :
>>164
ありがとうございます
/binのgcc.exe等をgcc.exe.backupに、/bin/x86_64-w64-mingw-gcc.exe等を/bin/gcc.exeにコピー
インクルードフォルダ指定を/usr/x86_64-w64-mingw/sys-root/mingw/include
ライブラリフォルダ指定を/usr/x86_64-w64-mingw/sys-root/mingw/lib
ヘッダを参照パスへコピーして無事できました
169 = :
自分がやりたいことが「クロスコンパイル」であるということをまず知ろう
cygwinはwindows上で動いてるけど、cygwinネイティブではないプラットフォーム
向けにネイティブとは違うヘッダ等を参照しランタイムとリンクさせるわけで、
linuxからmingwクロスコンパイルするのと基本的に一緒なんだわ
クロスコンパイルといっても別に難しい話ではなくて、
GNU autotools系で生成されたconfigureついてるんなら、普通はconfigure時に
./configure --host=x86_64-w64-mingw32 --prefix=/usr/x86_64-w64-mingw32/sys-root/mingw
などとすればいいだけ
hostにはクロスコンパイラツールセットの3つ組を指定する、これは必須
prefixはどうでもいいがmake installでインストールしたい場所を指定、
少なくともクロスならデフォルトの/usr/localでは嬉しくないだろう
後configureスクリプト内でpkg-config走らせてることが結構あるので、その場合は
PKG_CONFIG_PATHを前もって設定してexportしておいたほうがいい
170 = :
Ｃｙｇｗｉｎについて、 WindowsとＵＮＩＸとでは、改行と漢字コードにかんしてそれぞれどのような相違がありますか？
また、それにより、どのようなことが起きるのか、相違による影響にどのような対処を行うべきかなども教えてください
171 = :
>>170
それ語りだすと、とても１レスじゃ収まる気がしないので適当に答える
もっと対象を絞った質問が望まれる
Windows, UNIX、それぞれの基本的な改行コードは<CRLF>. <LF>だ。
それぞれを16進数で言うと以下の通り
<CRLF> = 0x0D 0x0A
<LF> = 0x0A
で、Cygwin上で作成したテキストの改行コードはどうなるか
どうやら<LF>らしい。
ということはWindows上で作成したテキストファイルはそのままでは
つかえないかもしれない。Windows上で作成したテキストファイルは
基本<CRLF>で保存されるから。
試しにメモ帳でテキストファイルを作成して、そのファイルを
Cygwin上で # cat -v <file> してみてほしい
多分結果には ^M という意味不明な文字列が出力されるはず。
これは <CRLF> の CR部分を表している。
172 = :
プログラムのソースコードのことを聞いてんの？
それとも、プログラムするときのファイル処理の仕方？
173 = :
>>170
ファイルをメモ帳やバイナリエディタで開けばわかると思うけど、
改行コードは、windowsで"\r\n"、UNIXで"\n"になっている。
UNIXのテキストをwindowsで開くと改行されずに黒い四角が表示される。
fopenでテキストファイルをテキストモードで開くとそのあたりの違いは吸収してくれる。
174 = :
>>170
<CRLF>, <LF>を気にせずにプログラミングすると
いろいろな不具合が起こる
特にシェルみたいな単純なインタープリター言語はそのせいでバグる
Cygwin上だと<CR>部分が邪魔でまともな動作ができないかもしれない
そのときどうするかというと dos2unixを使用する（←ここテストに出ます）
このコマンドはUNIX系の環境ではだいたい標準で入っているし
なければパッケージ管理システムからインストールできる
$ dos2unix <file>
という具合に実行すれば<CRLF>のファイルが<LF>になる
やったね、これで問題なくプログラミングできる
と、まあここまでがCygwin上での改行コードの違いとそれによる影響、
対処はどうするべきかという話
175 = :
>>170
次に漢字コード？
なのだが、まず言葉を正確に使うべきだ「文字コード」と呼ぼう
漢字コードだとnkfのような大昔のプログラムを思い出してしまう
嬉しいことに文字コードはWindows, Cygwin(Windows上)で共通だ
この文字コードで保存する、と決めればその文字コードになる。
一応Windowsでの標準文字コードはCP932, 別名Windows-31Jだ。
これはShift_JISの拡張で、一部Shift_JISにない文字を含んでいる。
詳しくはググってください。
Cygwinでの文字コードに関する相違とそれによる影響はそんなに
なさそうなので、このへんにしとく。
177 = :
自分に合うマシなテキストエディタ探してこいよ
謹製のメモ帳は禁止な
179 = :
答えてくださった方、ありがとうございました
181 = :
愛が足りない
182 = :
愛って何だ
183 = :
人工無能
184 = :
天才チンパンジー
185 = :
>>182
だいじにすること
186 = :
アイちゃんわろた
187 = :
>>182
ためらわないこと
189 = :
なんでや
普通の反対は特急、
無蓋の反対は有蓋やろ
190 = :
在特←キチガイ
ですね判ります
191 = :
なんでや！阪神関係ないやろ！
195 = :
cygwinはやぱっり糞
面倒でも仮想環境構築したほうが結局は面倒事が少ないよ
197 = :
「std::ofstream fout(FileName2.c_str());」に書き換えてコンパイルしたところ、
$ gcc -O3 code.cpp
/tmp/ccZuON0C.o:code.cpp:(.text+0x16): `std::basic_ios<char, std::char_traits<char> >::clear(std::_Ios_Iostate)' に対する定義されていない参照です
/tmp/ccZuON0C.o:code.cpp:(.text+0xbcf): `std::cin' に対する定義されていない参照です
/tmp/ccZuON0C.o:code.cpp:(.text+0xbd4): `std::istream::operator>>(int&)' に対する定義されていない参照です
(中略)
/tmp/ccZuON0C.o:code.cpp:(.text+0x7486): `std::__throw_bad_alloc()' に対する定義されていない参照がさらに続いています
/usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../../i686-pc-cygwin/bin/ld: /tmp/ccZuON0C.o: 誤った再配置アドレス 0x29 がセクション `.text$_ZNSt5dequeIiSaIiEED1Ev[__ZNSt5dequeIiSaIiEED1Ev]' 内にあります
/usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../../i686-pc-cygwin/bin/ld: 最終リンクに失敗しました: 無効な操作です
collect2: エラー: ld はステータス 1 で終了しました
などと、大量にエラーメッセージが表示されてしまったのです。
最初のエラーは「std::ofstreamのコンストラクタはconst char*型しか取らない」ということで、
だったらc_str()でstd::stringをchar型に変換して渡しても問題ないはずですよね？
どう書き直せばいいのでしょう……ご教示願います。
みんなの評価 :
gcc一覧へ類似してるかもしれないスレッド
- Cygwin + MinGW + GCC 相談室 Part 8 (938) - [97%] - 2022/10/28 8:00
- Cygwin + MinGW + GCC 相談室 Part 6 (981) - [97%] - 2012/12/30 23: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
トップメニューへ / →のくす牧場書庫について