元スレCygwin + MinGW + GCC 相談室 Part 3

gcc覧 / PC版 /

みんなの評価 : ★

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

703 = :

MinGWで移植できないか考える

704 = :

>>700
かたっぽのCygwin1.dll消すんじゃあかんの?

705 = :

>>700
その他者の移植したソフトウェアと一緒に他者のCygwin環境のcygwin1.dllを貰ってきて
そっちがロードされるようにして起動すればいいんでない？

706 = :

具体例を書いておいたほうが良かったか・・・。質問やり直し。

http://blogs.windowsnetworking.com/wnadmin/2006/09/22/lighttpd-web-server/
こういうスタンドアロンで使う事を目的としたcygwin環境を含むソフトウェアを
CygwinがインストールされてるWindowsにインストールすると、ソフトウェア同梱のcygwin1.dllよりも先に
パスが通ってるディレクトリにあるcygwin1.dllを読みに行こうとします。

バージョンの差異で起動できないのは表示されるエラーメッセージで明白なので、
早い話パスが通ってるディレクトリにあるcygwin1.dllを、同梱されてるcygwin1.dllで上書きすればいいんですが、
ソフトを使うたびにファイルを入れ替えやらをしていたら、バイナリ配布がやり易いWindowsの特権がryという話です。
# そもそも、入れ替えするくらいならソースを持ってきてコンパイルした方が早い。

そこで、>>705にある「そっちがロードされるようにして起動」の部分が知りたいと思いました。
オープンソースの恩恵を受けてるユーザだと、結構ぶち当たる問題かと思い、こちらで質問しました。
物理的にDLLを入れ替える方法しかない場合は、大人しくソースからコンパイルしマス。

707 = :

いやだから、お互いのCygwinのリビジョンを合わせればいいって話じゃないの?

708 = :

>>700
.local とか .manifest を用意すればOK。

709 = :

>>706
そのソフトってcygwinのシェルから起動するのか？
だとしたらパスの順番変えて付属のdllが先に見えるようにして起動すれば済む気がするけど…

そうじゃないとしたら普通にcygwinをインストールした場合cygwin1.dllのある
ディレクトリにパスが通ったりはしない(Windowsの環境変数の方のPATHね)からそんな
問題は起こらない気がする…

710 = :

挑発しているのでもなんでもなく
残念だがvirtualboxを使って複数のOSをシームレスに同居させられる今
わざわざcygwinを使う意味がまったくわからない。
古い Win環境でもcygwin使うより快適だよ

試していないならやってみるべきだと思うな。

711 = :

なるほど、仮想マシンに Linux 入れてクロスコンパイル用
のgccを用意してwin32用のバイナリを開発するということだな？
確かに快適だろうがその環境を作れるやつがどの程度いるのか…
# ここは一応 GCC のスレらしいよ？

712 = :

単にWindowsアプリケーションでPosixAPIを使いたいだけです

713 = :

単にシームレスにUnix系ツールを使いたいだけです。

714 = :

単にWin上でGCC系コンパイラーを使いたいだけです
Cygは使ってませんし

716 = :

それ全部このスレの話題だよな。

718 = :

敢えてWindows Services for UNIX

721 = :

もっと微妙になってしまいそうな気もするが…

723 = :

getrlimitのソースってどこにあるのでしょうか?
glibcの中のgetrlimitは空実装でした。

727 = :

>>726
なんで「\!*」？「$@」じゃないの？
つーか、そんなへんなエイリアスつくってないで、Makefile書きましょう。

728 = :

Makefile書けば済む話ではあるんですけど…。glutやらSDLやら
目的別にエイリアス作っとけば、ちょこっとした作業が楽になるかな
と思ったんです

729 = :

>>726
せめてワンライナーなaliasなんかじゃなくシェルスクリプトにすれば
記述の自由度があがってもっと便利なものも書けると思うんだが
何かaliasで定義しないといけない理由とかがある？

730 = :

SDL知ってるなら、それに倣ってgl-configでも作っておけばいいんじゃない
$ gcc `gl-config` hoge.c
で済むようになるけど

731 = :

>>729
理由は特にありません。
ただ、シェルスクリプトの使い方が良く分かってないのと、ファイルを
いちいち作りたくないとかです。

>>730
おお、すごくいい感じな気がします。こっちの方がいいですね
`sdl-config --cflags --libs`みたいなことですよね。これは、
どのような仕組みになっているのでしょうか？

732 = :

Makefile一個書くのがそんなに嫌なのかな?

733 = :

>>731
sdl-configの中身を読んでみましょう。
シェルスクリプトの書き方を習得しとくと、イロイロ便利だよ。

734 = :

>>732
ちょこっとしたテスト用ののソースのためにわざわざMakefile書くのが嫌かもです。
リンクするライブラリが多かったりすると…
Makefile書くよりもコマンドの方が手軽かな、と私が勝手に思ってるだけです。

>>733
シェルは覚えたいですね。

735 = :

>>734
もしかして、ソースファイルごとにMakefileが必要だと思っていない?
適当なMakefileを用意しておけば、例えばmake fooとするだけでfoo.cかfoo.cppをコンパイルできるのだけど。

738 = :

>>737
おお、ありがとうございます。こんな使い方できるんですね。最初からMakefileに
ついて調べとけば良かったorz

これで解決です。

ところで、autotoolsってありますよね。あれの使いどころが良く分かりません。
大規模なソフトウェア->autotools使う。
趣味範囲のソフトウェア->自分でMakefileを作って流用する
って感じなのでしょうか？

739 = :

>>738
やっぱりそうだったのかw 道理で話が噛み合わないと思った。

740 = :

>>739
知識少なくてすみませんw
プログラムしたくてもMakefileを調べていたら全然進まないので、

741 = :

やっつけでMakefile書いてきたツケが…

743 = :

なるほど。じゃあ、Makefileについてちゃんと調べようと思います。

745 = :

Makefileの中身はこんな感じ（一部抜粋）

# Makefile for MinGW

OBJS = main.o
OPTS =
LIBS =

CC = g++
RC = windres
CFLAGS = -O2 -Wall
.SUFFIXES: .cxx .hxx .rc .ro

#

$(OUT): $(OBJS)
$(CC) $(OPTS) -o $@ $(OBJS) $(LIBS)
strip $@
@(del *.o 2>&1) > NUL
@(del *.ro 2>&1) > NUL

.cxx.o:
$(CC) $(CFLAGS) -c $<

.rc.ro:
$(RC) -o $@ $<

clean:
@(del *.o 2>&1) > NUL
@(del *.ro 2>&1) > NUL
@(del *.exe 2>&1) > NUL