UNIXプログラミング質問すれ Part5

1 名前：名無し募集中。。。 [05/01/15 02:18:37] UNIXおよびUNIX clone環境一般のプログラミングに関する質問スレッド 前スレ Part4 pc5.2ch.net/test/read.cgi/tech/1095843584/ Part3 pc5.2ch.net/test/read.cgi/tech/1085930894/ Part2 pc5.2ch.net/test/read.cgi/tech/1055110889/ Part1 pc2.2ch.net/tech/kako/992/992057422.html Part3のミラー makimo.to/2ch/pc5_tech/1085/1085930894.html Part2のミラー makimo.to/2ch/pc5_tech/1055/1055110889.html 関連スレ Cygwin使っている人いますか？ その13 (UNIX板) pc5.2ch.net/test/read.cgi/unix/1099157755/ Cygwin使っている人いますか？ 3 (Windows板) pc5.2ch.net/test/read.cgi/win/1090131123/ 関連板 pc5.2ch.net/unix/ pc5.2ch.net/linux/ 381 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:14:50 ] で、アイコンとかダイアログのリソースはどっから取ってきてるのかね？ん？ 382 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:16:20 ] ある一人のレスが浮き上がって見える 383 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:16:41 ] >>377 >リソースにもいろいろあるでしょ。 この流れだとWindowsや(旧)Macで言うところのリソースのことではないでしょうか。 >>381 WineではPEファイルから取ってくるみたいですよ。 384 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:18:59 ] たった今、UNIXに挫折したとです。 385 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:20:04 ] UNIXで良書なんて見たことないから どこに載ってるか書いて欲しいなあ。 386 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:20:41 ] >>384 ！！！そのキーワードは、 いっちゃいかん！！ 387 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:21:49 ] WindowsみたいなリソースはOSはサポートしないだろう。 388 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:23:21 ] リソースがなにを指しているか分からないと、 本の名前も出せないでしょ。 >>381みたいな質問している人にOSの本勧めても 無意味だし。 >>381 Xの場合、ダイアローグの表示はツールキットの 仕事なのでツールキットの種類によりけり。 アイコンの表示はウィンドウマネージャの仕事 なので、ウィンドウマネージャによりけり。 (ツールキットが決まると、ツールキット標準の ウィンドウマネージャが決まる場合もある。) 知りたいツールキットとウィンドウマネージャの 種類を具体的に述べれば、もっと具体的な答も 出せるかもね。 いにしえのXtとtwmで言うなら /usr/X11R6/include/X11/{bitmaps,pixmaps}/ と /usr/X11R6/lib/X11/app-defaults/ あたりが 標準的な場所なわけだが。(アプリケーション固有 の場所に置くこともできる。) ツールキットは狭義ではOSの一部ではない。 >>387が言ってるのはそういう意味。 389 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:23:27 ] つか、ELFをばらして好きに弄ってもう一回固めればいいんじゃないの？ 390 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:26:23 ] >>389 わかってないなあ 391 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:27:27 ] UNIXを捨てた おれは正解を選んだ 392 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:28:33 ] 452 名前：デフォルトの名無しさん 投稿日：05/02/28 01:15:33 もうUNIXで仕事したくないのに UNIXの仕事がきます。 どうすればよいですか？ 453 名前：デフォルトの名無しさん 投稿日：05/02/28 01:18:47 仕事があるだけマシってもんよ そうだろう？兄弟 454 名前：デフォルトの名無しさん 投稿日：05/02/28 01:26:38 もういやだ！ もういやだ！ もういやだ！ 393 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:30:51 ] あほくさ 394 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:31:13 ] ELFフォーマットを採用してるOSを上げてください。 自分はLinux以外知りません。 395 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:34:08 ] >>394 商用、フリーを問わず、現役のUNIX系OS、ほぼ全て。 ELF の規格を定めたのは、AT&T と Sun じゃないかな。 linux は最初のうちはa.outしかサポートしてなかったね。 396 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:35:29 ] じゃ、とりあえずELFでトロイ作ってみるよ。 あんがと。 397 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:37:56 ] Windowsヲタは固定観念のかたまりだな... 398 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:38:25 ] >>394 Solaris, *BSD, IRIX, SVR4 等... 最近は組み込み用途の開発ツールも ELF を吐き出す. 399 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:40:27 ] BSD系は最近だな 400 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:42:04 ] CPUの種類やOSの種類が異なると、同じ elf でも 使える命令セットやシステムコールが異なるので、 同一のトロイの木馬を複数のOSに対応させるのは 面倒なんだけどね。まあやれば当然できるが。 つうか、そういうものを作るだけの知恵のある奴は、 ふつうはもう少し建設的なことに暇を使うと思うんだが。 そういう、できて当たり前で、人が困るだけのプログラム を作るのは、そういうことの判断ができない頭弱い奴だけ じゃない？ 401 名前：デフォルトの名無しさん mailto:sage [05/03/01 20:58:38 ] 商用UNIXだとしっかりしてるんだけどね。 402 名前：デフォルトの名無しさん [05/03/01 22:05:13 ] お前ら落ち着け 403 名前：デフォルトの名無しさん mailto:sage [05/03/01 22:09:20 ] さては藻前も釣りだな。 404 名前：デフォルトの名無しさん mailto:sage [05/03/01 22:25:28 ] UNIXにもノートンみたいな製品を進出させるには トロイとかウィルスばらまかないとね 需要のための供給 405 名前：だよもん mailto:だよもん [05/03/01 22:37:03 ] だよもんウィルスだよもん 406 名前：335 mailto:sage [05/03/01 22:49:49 ] １文書に複数文字コードが入ってるとか，そういうややこしいのじゃなくて １文書が１つの文字コードに限定されてるんです． >>341 そうです．自動判別”も”したいんですけど， どうも良いライブラリがみつかんないんですよねぇ． >>344 >文字コードを自動判別しないといけない時点で負け。 orz. 完全に自動判別すんのが厳しいのは分かってるんですけど… 大体でよいんです． >>346 nkfに渡すのも考えてるんですけど… ライブラリ化されてて使いやすいのはないものかと． 407 名前：デフォルトの名無しさん mailto:sage [05/03/01 23:36:56 ] >>335 tricklib.com/cxx/ex/babel/ g++ だと多少問題があるらしいがこれはどうだ？ 僅かな文字数でも高い精度で判別できるぞ。 408 名前：デフォルトの名無しさん mailto:sage [05/03/02 11:14:24 ] コードに日本語でコメントが入っているというだけで 使う気がしなくなるのは俺だけか？ 409 名前：デフォルトの名無しさん mailto:sage [05/03/02 11:23:12 ] ↑ソースクレ厨 410 名前：デフォルトの名無しさん mailto:sage [05/03/02 13:38:21 ] ↑車輪を何度も再発明して貴重な人生を無駄にする香具師 411 名前：デフォルトの名無しさん mailto:sage [05/03/02 15:11:02 ] >>410 ↑見ず知らずの他人の趣味を「人生の無駄」呼ばわりする香具師 412 名前：335 mailto:sage [05/03/02 15:50:59 ] >407 ありがとうございます。よさげですね。 g++だと何か問題があるんですかね？ ちょっと試してみます。 413 名前：デフォルトの名無しさん [05/03/03 23:45:23 ] 414 名前：デフォルトの名無しさん mailto:sage [05/03/05 05:52:29 ] 各種UNIXでcursesの互換性ってどの程度まであるの？ 415 名前：デフォルトの名無しさん [05/03/05 11:28:09 ] 問題ないくらい 416 名前：デフォルトの名無しさん [05/03/07 13:17:21 ] linuxだとアドレス値を整数演算するときに unsigned longに入れてるんだけど、これって 128bitCPUが出てきたときに問題にならないの？ 417 名前：デフォルトの名無しさん mailto:sage [05/03/07 13:30:53 ] 問題になるかならないかは不明。 128bit CPU が実用になる時代が本当に来たとしても、 その CPU で long>=128bit なら問題にならない。 long<128bit なら問題になる。 一般論としては、そういう用途には unsigned long では なく、uintptr_t ないし intptr_t を使うべき。 この型は C99 なら #include <stdint.h> すると定義 される。 418 名前：デフォルトの名無しさん [05/03/07 13:42:04 ] >>416 longを128bitにするから問題なし。 419 名前：デフォルトの名無しさん mailto:sage [05/03/07 13:42:08 ] 仮想メモリアドレスの時代に型の大きさなんて気にしても仕方がないと思う ほとんどの場合unsignedにする意味なし Linuxのプロセスメモリマップの使い方でも調べたほうが賢明 420 名前：デフォルトの名無しさん mailto:sage [05/03/07 14:16:30 ] >仮想メモリアドレスの時代に型の大きさなんて気にしても仕方がないと思う なんだこりゃ 421 名前：デフォルトの名無しさん mailto:sage [05/03/07 18:18:53 ] >>419 さんは、>>416 さんが 「 unsigned 」 を疑問視されていると受け取られた ようでつね。 対して、多くの方々は >>416 さんが疑問視しているのは 「 long 」 の方だと・・・ どちらにしても、>>417 さんの答えで解決でつよね？ 422 名前：デフォルトの名無しさん mailto:sage [05/03/07 19:12:18 ] UNIXが採用してるLP64というCの型システムだけど、 128bitCPUが出てきたときは、LP128というものを定義して、 unsigned longはつねにポインタサイズと同じビット長になる ことを暗に想定してるのかな？ LP128だと short(16),int(32),long(128),long long(128) こんな感じなのかな？ >>128 >一般論としては、そういう用途には unsigned long では >なく、uintptr_t ないし intptr_t を使うべき。 ですよねえ 423 名前：デフォルトの名無しさん mailto:sage [05/03/07 19:22:13 ] システムによって定義されるのはたった数個の型だけど、 これがいろんな型にtypedefされて、またそれらが インターフェイスの定義に既に使われていたりするところが ややこしいね。 424 名前：デフォルトの名無しさん mailto:sage [05/03/07 19:50:19 ] >>422 予測できる将来に128bit CPUが実現するかどうかは 良く分からないけど、もし実現したらUNIX系は short:int:long:long long=16:32:64:128 になるん じゃないかなあ。だって、1/2/4/8/16 全てのサイズの 整数型が使えないと不便でしょ。 今やuintptr_tがあるから、long がポインタ変数を 保持できるとかいった仮定を設ける必要ないし。 425 名前：デフォルトの名無しさん mailto:sage [05/03/07 19:53:29 ] とりあえず、LP64, ILP64, LLP64, ILP32, LP32くらい理解してからレスしろよ、この屑。 www.opengroup.org/public/tech/aspen/lp64_wp.htm 426 名前：デフォルトの名無しさん mailto:sage [05/03/07 20:19:14 ] LP64・・・longとポインタが64ビットに ILP64・・・intとlongとポインタが64ビットに LLP64・・・long longとポインタが64ビットに ILP32・・・intとlongとポインタは32ビット(今の32bit向けCコンパイラはこれかな？) LP32・・・longとポインタは32ビット、intは16ビット こんな感じ？ 427 名前：デフォルトの名無しさん mailto:sage [05/03/07 20:23:57 ] TRANSITION FROM CURRENT INDUSTRY PRACTICEも読め。 428 名前：デフォルトの名無しさん mailto:sage [05/03/07 20:29:51 ] 128bit化なんてその時になってから泥縄的に考えればいいんだよ。 もし動かなかったらIBMに金出させて力技で修正すればいいだけ。 今困っていない事を今対応するな。これがLinuxのモットーだ。 429 名前：デフォルトの名無しさん mailto:sage [05/03/07 20:33:26 ] 128bit が主流になる頃はおいらは隠居してる. 勝手にやってくれ. 430 名前：デフォルトの名無しさん mailto:sage [05/03/07 20:48:26 ] というか32→64の経験でスキームは固まっている。 431 名前：デフォルトの名無しさん mailto:sage [05/03/07 20:52:54 ] ところでIPV5って64bitだったの? 432 名前：デフォルトの名無しさん mailto:sage [05/03/07 20:54:59 ] 型同士の相対的な関係と実際のデータ長っていう 二つの視点で見るとこんなかな。 UNIXは32bit,64bitそれぞれILP32とLP64だけど、 char:short:int:longそれぞれ ILP32 8:16:32:32 32(pointer) LP64 8:16:32:64 64(pointer) ILP32からLP64への移行で変わったのは、 (int,long)と(int,pointer)の相対的関係が変わったことと、 longとpointerの実際のデータ長が変わったということ。 char:short:int:long:long long ILP128 8:16:128:128:128 LP128 8:16:32:128:128 LLP128 8:16:32:64:128 128bitCPUにおいてはこんな感じのがありえると思うけど、 今UNIXで32bit64bit両方に通用するコードとしてlong=pointerという 仮定の元にコードを書いてしまうともうLP128しかないと思うんだよね。 というかILP32から64bit化においてLP64を採用した時点で long=pointerという想定を受け入れてるように見える。 ILP128はちょっとありえないね。LP64でせっかくintの実データ長を32で固定した意味がなくなる。 LLP128が1番よさそうに見えるけど、LP64からlongとpointerの相対的関係が異なる。 素人考えだとLP128しかなさそうに見えるけど。 433 名前：デフォルトの名無しさん mailto:sage [05/03/07 21:01:51 ] つーか128bit時代にもなってLinux使ってたとしたらソフトウェア界の敗北だな。 434 名前：デフォルトの名無しさん mailto:sage [05/03/07 21:02:19 ] > LP64からlongとpointerの相対的関係が異なる だから intptr_t, uintptr_t を使えってばさ。 それで問題なし。 435 名前：デフォルトの名無しさん mailto:sage [05/03/07 21:43:35 ] 32bitマシンって1960年代にできて、64bitマシンって1990年頃 だよね。30年くらいかかっている。 同じような指数的ペースで発展する(1年で1bitくらい)として 128bit マシンができるのは、2050年を過ぎたぐらい… 俺は死んでるな。 436 名前：デフォルトの名無しさん mailto:sage [05/03/07 21:46:46 ] UNIX/Cを潰したいメーカーが96bitマシンとか出して来たりして。 437 名前：デフォルトの名無しさん mailto:sage [05/03/07 22:51:54 ] なぜbit数が増えるのか という根源的な疑問は起きないのか？ 438 名前：デフォルトの名無しさん mailto:sage [05/03/07 22:59:35 ] 基本的にはストレージのサイズが増えるからという要因が 一番大きいでしょ。(AS/400 みたいに、アドレス空間の ほとんどを無駄に捨てざるをえないアーキテクチャだと 話は別だが。) 問題は、現在の指数関数的なストレージサイズの増大が、 あと50年続くかどうかと、たとえ続いたとしても、そんなに 使い道があるかどうかだな。 64ビットでも、人類ひとりひとりに、それぞれ2GB以上も あるというのに。 439 名前：デフォルトの名無しさん mailto:sage [05/03/07 23:02:38 ] いつの時代もそういう近視眼的な発言をする奴がいたわけで 440 名前：デフォルトの名無しさん mailto:sage [05/03/07 23:05:37 ] いつの日にか、家庭向けPCで地球シミュレーションが軽く動く日がくるんだよ 441 名前：デフォルトの名無しさん mailto:sage [05/03/07 23:07:41 ] 昔、12bit マシンってのもあったぞ。 442 名前：429 mailto:sage [05/03/08 01:57:05 ] >>439 438 じゃないんだけど, そのころはおいらは隠居してるわけだ. 興味ねぇ. >>438 > 基本的にはストレージのサイズが増えるからという要因が > 一番大きいでしょ。 数値計算とかやってると, アドレッシングできる領域がどれだけ増 えても実際の計算速度が上がらないと, メリットは小さい. やっと 64bit を有効に使える計算速度に達したってのが現実では? # DB 検索なんかでもそぉだと思うぞ, エンジン作ってる連中にし # てみれば... 443 名前：デフォルトの名無しさん mailto:sage [05/03/08 01:59:32 ] >>429 ダウト。 データベースとか情報検索とかはとっくに64bitないと話にならなくなってる。 444 名前：デフォルトの名無しさん mailto:sage [05/03/08 02:36:39 ] ファイルシステムが2G4G以上をサポートしてる時点で64bit化の恩恵を受けられるわけで。 445 名前：デフォルトの名無しさん mailto:sage [05/03/08 03:12:48 ] >>444 ブー。mmapが使えないと結構苦しい。 446 名前：445 mailto:sage [05/03/08 03:13:48 ] なんか444へのレスとするのは意味不明だな。ごめん。 447 名前：デフォルトの名無しさん mailto:sage [05/03/08 03:28:32 ] 32bit,64bitそれぞれのシステムでintとlongを使い分けてるけど、 これは一言でいってどういう事情によるものなのかしら？ Linux linux/include/asm/posix_types.h BSD sys/arch/`uname -m`/include/ansi.h /*i386*/ #define _BSD_SIZE_T_ unsigned int #define _BSD_CLOCK_T_ unsigned long /*amd64*/ #define _BSD_SIZE_T_ unsigned long #define _BSD_CLOCK_T_ unsigned int 448 名前：デフォルトの名無しさん mailto:sage [05/03/08 03:35:29 ] Linuxの場合 /*i386*/ typedef unsigned int __kernel_size_t; typedef long __kernel_clock_t; /*amd64*/ typedef unsigned long __kernel_size_t; typedef long __kernel_clock_t; 449 名前：デフォルトの名無しさん mailto:sage [05/03/08 05:16:22 ] つまりポインタをlong型で扱う奴はバカint型で扱う奴はもっとバカってことでいいですか？ 450 名前：429 mailto:sage [05/03/08 07:20:28 ] >>443 > データベースとか情報検索とかはとっくに64bitないと話にならなくなってる。 そぉゆう意味で言ってるんだが... 「やっと」ってゆう言い方が悪かった. すまん. おれ的には, やっと 10年くらい前からってな感覚だったもんで... 当初からそれなりに, 64bit マシンはメモリバス帯域広いし, マル チプロセッサ化するために, バスのクロスバ化なんて, ハードウェ ア的に見た場合, 非効率以外のなにもんでも無いようなことまでやっ てるところもあるし... それ以前は, こんなぜいたくはスパコンにしか許されなかったわけ だから... 451 名前：デフォルトの名無しさん mailto:sage [05/03/08 07:39:51 ] pc5.2ch.net/test/read.cgi/tech/1109793931/l50 452 名前：デフォルトの名無しさん [05/03/08 09:07:01 ] printfでtypedefな型を扱えればいいんだが 453 名前：デフォルトの名無しさん mailto:sage [05/03/08 09:12:18 ] >>448 BSDの方の型は、ユーザー空間にも公開しているものなので、 一度決めると変えない方がいいんじゃないかな。まあユーザー プログラムが行儀良く書かれていれば、同じサイズの型に 変えても問題ない筈だけど、行儀良く書かれてない場合、 int と long の食い違いが生じると、lint では警告さえる ケースがありそうな。 あとは、その CPU アーキテクチャの ABI の仕様書に書かれて いる型名に合わせてるとかもあるかも。 Linux の方はカーネル内部用の型に見えるなので、良くわかんない。 454 名前：デフォルトの名無しさん mailto:sage [05/03/08 09:29:17 ] >>452 C99 なら一応できるよ。 intptr_t x; なら #include <inttypes.h> printf("%" PRIdPTR "\n", x); とか。 typedef intptr_t MyType; してるなら同時に #define PRIdMYTYPE PRIdPTR もとしておいて、MyType の printf には PRIdMYTYPE を同様に指定すればいい。 size_t も "z" 修飾子を使ってどうような ことができる。 455 名前：デフォルトの名無しさん mailto:sage [05/03/08 09:43:57 ] >>454 > size_t も "z" 修飾子を使ってどうような > ことができる。 ついでにここも詳しく…… 456 名前：デフォルトの名無しさん mailto:sage [05/03/08 10:48:23 ] 128ビットCPU(データバス幅>=アドレスバス幅>=64bit)なCPUは 相当長い間必要ないだろ。データバスが128bitなのはGPUじゃ 当たり前になってるんだろうけど。 16bit -> 32bit アドレス空間は6万5千倍。 32bit -> 64bit アドレス空間は42億倍。 このアドレス空間を使い尽くすのっていつ頃？ ヘタしたら人間が絶滅してるかもなｗ 457 名前：デフォルトの名無しさん mailto:sage [05/03/08 10:49:29 ] >128ビットCPU(データバス幅>=アドレスバス幅>=64bit)なCPUは 　　　　　　　　　　　　　　　　　　　↓ 128ビットCPU(データバス幅>=アドレスバス幅=128bit)なCPUは 458 名前：デフォルトの名無しさん mailto:sage [05/03/08 11:21:26 ] >>455 z A following integer conversion corresponds to a size_t or ssize_t argument. (Linux libc5 has Z with this meaning. Don't use it.) #define PRIdSIZE "z" こういうのあんまり好きじゃないが。 459 名前：デフォルトの名無しさん mailto:sage [05/03/08 11:22:55 ] >>458 うちのシステムには入ってないや……。 460 名前：デフォルトの名無しさん mailto:sage [05/03/08 11:24:18 ] あ、標準では定義されてないけど458のように定義すりゃ同じようにできるよ、って 話かな? 461 名前：デフォルトの名無しさん mailto:sage [05/03/09 13:00:27 ] そゆこと。でも>>458みたいにするんじゃなくて #define PRIdSIZE "zd" の方がいい。小文字の「d」の意味がなくなっちゃうから。 #define PRIxSIZE "zx" とかしたいしね。 462 名前：461 mailto:sage [05/03/09 13:46:14 ] 補足。 C99を前提にしていいソフトなら、#defineせずに "z"を直に書いた方がいいだろうけどね。 #defineする必要があるのは、C99より前の処理系 への移植を考慮する必要があるケースと、あとは typedef size_t MyType; #define PRIdMYTYPE "zd" のように、自分で定義した型に対して printf の フォーマット文字列を提供したい場合。 463 名前：デフォルトの名無しさん [05/03/09 23:29:27 ] linuxで、mallocの関数の中身を知りたくて探してるのですが見当たりません。 glibcのソースを探してるのですが。。どこにあるのでしょうか？ 464 名前：デフォルトの名無しさん mailto:sage [05/03/09 23:32:00 ] >>463 ダウンロードした場所にありましたよ 465 名前：463 [05/03/09 23:37:42 ] ダウンロードした場所ですか？ うーん。glibc-xxx/malloc/malloc.cの中とかその周辺とか調べたんですがないんですよ。。 466 名前：デフォルトの名無しさん mailto:sage [05/03/09 23:38:51 ] 入れなきゃ無いわな 467 名前：デフォルトの名無しさん mailto:sage [05/03/09 23:40:22 ] 勝手にソース覗くのはストールマンに失礼ですよ。 468 名前：デフォルトの名無しさん mailto:sage [05/03/09 23:43:22 ] >>467 アホ発見 469 名前：463 mailto:sage [05/03/10 00:03:13 ] 検索したらやっとそれらしいのにヒットした。。 www.gelato.unsw.edu.au/linux-ia64/0111/2457.html >BTW, calloc is included in malloc.c. > You would like to open the file glibc-2.2.4/malloc/malloc.c, > and then you will be looking for cALLOc. It is calloc function. そういえばmALLOcみたいな変なのがあったな。。 今ソースがないので明日調べてみます。お騒がせしました。 470 名前：デフォルトの名無しさん mailto:sage [05/03/10 00:38:22 ] UNIXのソースってなんでこんなに汚いの？ 471 名前：デフォルトの名無しさん mailto:sage [05/03/10 00:39:56 ] お前の顔より綺麗だ 472 名前：デフォルトの名無しさん mailto:sage [05/03/10 16:32:09 ] なんで俺の顔知ってんの？ 473 名前：デフォルトの名無しさん mailto:sage [05/03/10 17:16:57 ] 基本 474 名前：デフォルトの名無しさん mailto:sage [05/03/10 20:35:26 ] おそらく基本的な質問だとおもいますが -lpthreadのリンクを下のようにMakefileで記述するとcannot find -lpthreadという エラーがでてしまいます。 test:main.o sub.o gcc -o test main.o sub.o -lpthread main.o:main.c test.h gcc -c main.c test.h sub.o:sub.c test.h gcc -c sub.c test.h コンソールで一つずつコンパイルしていけば問題はないんですが・・・ よろしくおねがいします 475 名前：デフォルトの名無しさん mailto:sage [05/03/10 21:34:31 ] -lpthreadをオプションと認識していないみたいですな。 それはともかく、スレ違いです。 476 名前：デフォルトの名無しさん mailto:sage [05/03/10 21:46:46 ] >>475 Unixプログラミングの場合、スタンダードなIDEがないので、 Makefileやコンパイルオプション指定をする段階から すでにコーディングの戦いが始まっていると思うのは俺だけですか？ 477 名前：デフォルトの名無しさん mailto:sage [05/03/10 21:50:13 ] ある程度以上の規模なら、IDEを使おうと使うまいと 素敵なビルドの仕組みを作ることは コード自体を書くことと同じくらい重要でぷ。 478 名前：デフォルトの名無しさん mailto:sage [05/03/10 21:51:24 ] だからあれほどUNIX捨てろって言ったのに・・・ 479 名前：デフォルトの名無しさん mailto:sage [05/03/10 21:53:09 ] Windowsだとマウスでポチポチやるだけで終わる作業なのにねえ。 UNIXって頭悪すぎ。 480 名前：デフォルトの名無しさん mailto:sage [05/03/10 21:56:15 ] みえみえの展開に萎え 481 名前：デフォルトの名無しさん mailto:sage [05/03/10 21:58:32 ] >>474 -lpthread の前に変なコード入ってないか od ででも確認してみたらどうだろう。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef