GCCについて part10

■ このスレッドは過去ログ倉庫に格納されています
2011/09/03(土) 14:13:04.14
史上最強かもしれなかったツール、GCC(GNU Compiler Collection)について語るスレ。

GNU本家のGCCページ
http://gcc.gnu.org/

Binutils - Collection of binary utilities ←これも必要だぞ。
http://www.gnu.org/directory/GNU/binutils.html

GNU Binutils
http://sources.redhat.com/binutils/

GCC online documentation
http://gcc.gnu.org/onlinedocs/

Installing GCC
http://gcc.gnu.org/install/

GCC Timeline
http://gcc.gnu.org/releases.html#timeline

Calendar
http://gcc.gnu.org/develop.html#timeline

前スレ
GCCについて part9
http://hibari.2ch.net/test/read.cgi/tech/1246059290/

関連スレ
【最速へ】LowLevelVirtualMachine【LLVM】
http://hibari.2ch.net/test/read.cgi/tech/1211547655/
230デフォルトの名無しさん
垢版 |
2013/01/14(月) 17:31:06.90
>227
なるほど。　とはいったものの、どうしたらいいのやら。
newlibのソースって当然ASMだろうな。mesのGCCですんなりコンパイルできる
だろうか？
2013/01/14(月) 18:00:13.06
>>229
あれはふつーのsh-coffだろう
何も考えずにプロジェクトに入れちまえ
232231
垢版 |
2013/01/14(月) 18:00:54.52
すまん
s/229/230/
2013/01/14(月) 18:35:07.31
何を悩むことがあるのか分からん。
とりあえずnewlibをコンパイルしてみればいいじゃないか。SH4ということにして。
2013/01/16(水) 01:59:09.30
newlib/libc/machine/sh/setjmp.S
2013/01/20(日) 21:02:32.76
GDBについて聞きたいんだが、ファイルポインタなどで外部ファイルからパラメータを読み込むプログラムなんだけど
デバックする場合、エラーは起きる？それともこれがエラーの原因なんかな
2013/01/20(日) 21:13:10.35
日本語でok
2013/01/20(日) 21:13:54.81
うーん、ダメやなGDBうまくわかってないから伝えられないな
すまんな
2013/01/20(日) 21:16:38.64
ニシくんテクとして壊れたパーツもあえて保持するというテクがあるんやで
2013/01/20(日) 21:17:21.02
gbk
2013/01/20(日) 21:17:26.27
GDBの問題じゃないからね、それ
2013/01/20(日) 21:27:31.25
プログラム的におかしいってことなんかな
コンパイル時にエラーは言われないんだけど、実行結果でエラー言われるんだよね
もう一度確認してみますわ
2013/01/20(日) 21:31:35.73
scanfの使い方がおかしいだけでしょ
&のつけ忘れとか
2013/01/20(日) 21:33:52.87
エスパーすげえな
SetFilePointerとデバッガで挙動が変わるのと何の関係が？としか思えなかったわ
2013/01/20(日) 21:47:35.79
書き方がおかしな所はコンパイル時にわかるけど
実行時の問題まで探してくれてるわけじゃないからね
2013/01/20(日) 21:59:32.49
エスパーな質問なのに答えてくれてほんとありがとう
scanf確認したんですが&は一応ついてました
もう少し色々お聞きしたいのですが、C言語の話題になってしまいそうなのでC言語スレで聞いて見ようと思います

GDB自体は実際の実行と同じように動作すると分かって良かったでうｓ
2013/01/22(火) 00:45:18.92
GCCVer3の最終版使うのとGCC最新版(Ver4)使うのではどっちが安定なんだろうか
2013/01/22(火) 00:56:08.11
対応したarchなら、コンパイルという動作はどっちも安定してるんじゃね
2013/01/22(火) 09:26:59.11
４の安定版使え。
2013/01/22(火) 09:44:34.52
コンパイラ単体で見れば歴史の長い3の方が枯れていると言えるかもしれないけど、
そう単純なものでもないんだよね。
C++ABI がちょっと違ったりするので、今更3を使うのは問題の種になると思う。
と言うわけで私としては4を推す。
2013/01/31(木) 20:15:33.81
short-enum な --taret=arm* な 4.6.4 で,
short-enam な --hist=arm* な 4.6.4 を作ろうとすると
色々まずいっぽいんだが， 既知の事実ですか?
2013/01/31(木) 20:24:56.18
コンパイル時にしてするものでビルド時に指定するもんじゃないような
2013/01/31(木) 20:36:24.41
>>251
やっぱそうなるか
じゃあ libgcc だけ， 単独に short-enum にできる安直な方法ってある?
2013/01/31(木) 20:40:44.15
4.7だと
libgcc/config/arm/t-linux
に仕込めばいいような
2013/01/31(木) 20:43:16.98
もしくは
make CFLAGS_FOR_TARGET="-g -O2 -fomit-frame-pointer" CXXFLAGS_FOR_TARGET="-g -O2 -fomit-frame-pointer"
な感じか？
2013/03/06(水) 23:53:27.37
たのもう
gcc 4.7.2 のコンパイルでつまづいてる （gmp 5.1.1、mpfr 3.1.1、mpc 1.0.1 はコンパイルできた）

../configure --enable-languages=c,c++ --enable-bootstrap --enable-shared --enable-threads=posix \
--enable-checking=release --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object \
--disable-dssi --disable-multilib --with-gmp-lib=/usr/local/lib64 --with-mpfr-lib=/usr/local/lib64 \
--with-mpc-lib=/usr/local/lib64 --without-ppl --with-tune=generic

の後の make 実行したら mkdir -p -- x86_64-unknown-linux-gnu/libgcc のあるフェーズで、

checking for suffix of object files... configure: error: in `/w/gcc/gcc-4.7.2/build/x86_64-unknown-linux-gnu/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.

とか言われた
x86_64-unknown-linux-gnu/libgcc/config.log には

configure:3344: /w/gcc/gcc-4.7.2/build/./gcc/xgcc -B/w/gcc/gcc-4.7.2/build/./gcc/ -B/usr/local/x86_64-unkn
own-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gn
u/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -V >&5
xgcc: error: unrecognized command line option '-V'

とか出てるんだけど、何が悪いかわかる人いたら教えてくらさい
ただし英語のドキュメントは読めない
2013/03/06(水) 23:56:04.33
ちなみに OS は CentOS 5.3 x86_64 でございますれば
他に補足の情報が必要であれば指摘ください
2013/03/07(木) 00:20:28.62
command line option とみなされてるのが問題なんだろ
shell 変えてみるとか
2013/03/08(金) 09:11:55.41
うーん、sh、csh、ksh、bash を試しましたが変化ありませんなあ・・・orz
2013/03/09(土) 02:46:26.94
-Vを消しちゃえばいいやん
2013/03/09(土) 13:30:08.59
>>255
同じような症状で
--disable-libquadmath
つけたら通った
2013/03/11(月) 04:33:46.70
'unrecognized' command line optionでxgccのエラーだぜ、ってことで>>257はおかしい
xgccってのはまさにいま作ってる最中のgccで、そいつが-Vを受け付けてない(手元のgccで試したら確かに4.7系は-Vを受け付けない)
-Vの出力から'compute suffix of object files'をしようとしてるんだから>>259もおかしい
エラーはlibgccのconfigureで起きてるっぽいので>>260もどうかなあ

つーことで、configureのその行の前後にxgcc -B中略 -Vの結果を加工して
suffix of object files(たぶん.o)をどっかの変数に入れてるところがあるはずなんで
その辺書き換えて直接.oをセットしてしまえばいいと思う
環境差かなんかで普通入り込まない過去のgcc互換かなんかの分岐に入ってしまってるんだろう

と予想、外れてたらごめん
2013/03/11(月) 05:49:25.22
たぶん、glibc-develあたりのパッケージが入ってないような
# yum groupinstall "Development Tools"
をやれば、いいような
263257
垢版 |
2013/03/11(月) 07:03:51.09
>>262
漏れも最初にそう思ったんだけど、
わざとボケてみたんだ。
ごめん。
2013/03/11(月) 09:38:08.17
俺も俺も
2013/03/17(日) 14:29:39.93
すいません、これでできました
su
mkdir /w; mkdir /w/gcc; cd /w/gcc
wget http://ftp.tsukuba.wide.ad.jp/software/gcc/releases/gcc-4.7.2/gcc-4.7.2.tar.bz2
wget ftp://ftp.gmplib.org/pub/gmp/gmp-5.1.1.tar.bz2
wget http://www.mpfr.org/mpfr-current/mpfr-3.1.2.tar.bz2
wget http://core.ring.gr.jp/pub/GNU/mpc/mpc-1.0.1.tar.gz
tar xvfj gcc-4.7.2.tar.bz2
tar xvfj gmp-5.1.1.tar.bz2
tar xvfj mpfr-3.1.2.tar.bz2
tar xvfz mpc-1.0.1.tar.gz
mkdir gcc-4.7.2/build
mkdir gmp-5.1.1/build
mkdir mpfr-3.1.2/build
mkdir mpc-1.0.1/build
cd gmp-5.1.1/build
../configure --enable-cxx
make
#make install
cd ../../mpfr-3.1.2/build
../configure
make
#make install
cd ../../mpc-1.0.1/build
../configure
make
#make install
cd ../../gcc-4.7.2/build
../configure --enable-languages=c,c++ --enable-cxx --with-newlib --disable-multilib --enable-threads=posix --with-tune=amdfam10
export LD_LIBRARY_PATH=/usr/local/lib64
make
#make install
2013/03/17(日) 15:08:52.01
あ、↑の #make install は make install でございますれば

で、

../configure --enable-languages=java --with-newlib --disable-multilib --enable-threads=posix --disable-bootstrap

とするとコケて、どうしても Java コンパイラが作れないです

libtool: compile: /w/gcc/gcc-4.7.2/build_java/./gcc/xgcc -shared-libgcc
---snip---
java/net/.deps/natVMInetAddress.Tpo -c java/net/natVMInetAddress.cc -fPIC -DPIC -o java/net/.libs/natVMInetAddress.o
java/net/natVMInetAddress.cc:42:52: error: declaration of C function ‘int gethostname(char*, int)’ conflicts with
In file included from java/net/natVMInetAddress.cc:12:0:
/usr/include/unistd.h:845:12: error: previous declaration ‘int gethostname(char*, size_t)’ here
make[3]: *** [java/net/natVMInetAddress.lo] Error 1

Web 検索しても、なぜかコケて回避できないみたいな記述があったような無かったような
2013/03/17(日) 15:44:56.69
あー、

../configure --enable-languages=java --disable-multilib --disable-bootstrap

にしたらコンパイルできますた
が、実際に .java ファイルをコンパイルしようとすると

gcc: error trying to exec 'ecj1': execvp: No such file or directory

とか怒られる
ググったらこんな感じ
http://barutan.s296.xrea.com/cgi-bin/tdiary/?date=20100220#p04
お手上げでしょか？
2013/03/17(日) 16:31:58.39
ecj1って、eclipse関連のパッケージみたいだね。
https://launchpad.net/ubuntu/+source/ecj/3.5.1-6
2013/03/17(日) 16:41:06.65
GCJ使うのが目標だったのね。
ディストリビューションのspecファイル参考にするといいんじゃないかな。
2013/03/20(水) 09:53:14.28
4.8.0リリース？
2013/03/20(水) 19:02:05.70
リリースアナウンス出てないからまだだろう
2013/03/21(木) 12:32:55.08
gcc 4.8.0をmakeしようとしたらこんなの出ました。
この前にmakeをビルドしたのですが、makeのビルドに失敗したって意味でしょうか？
http://www.07ch.net/up2/src/lena8828.png
2013/03/21(木) 16:35:57.64
makefileの1〜6行目を晒すとか
2013/03/21(木) 16:42:10.00
makeで始める行はmakeコマンドが出力してる。[n]はネストの深さ。
エラーが起きているのはシェルにコマンド行で渡して実行させているコード。
EOFが出てるのは、Win32上で有名な
> [Please ignore a syntax error on the next line - it is intentional]
じゃないんだな。この部分は出てないので。
2013/03/21(木) 19:49:40.74
http://www.07ch.net/up2/src/lena8830.png
すみません。今見たらbuild/libiberty/config.logにNo such file or directoryと書いてありました。
ぐぐってみます。
ありがとうございました。
276275
垢版 |
2013/03/22(金) 11:21:05.10
しつこくてすみません
MinGWにpthreadsをインストールしてgcc 4.8.0をコンパイルしようとしたのですが、sys/systemcfg.hが無いといわれて
ググったのですが、見当たらないのでwinpthreadsをコンパイルしようとしたのですが、makeでエラーになります。
http://www.07ch.net/up2/src/lena8836.png
configureもmakeも改変せずにビルドしているのですが、makeが存在していないファイルを作ろうとしていてmakefileに問題があるのでしょうか？
2013/03/22(金) 13:45:00.07
windowsでは無理
2013/03/23(土) 01:57:39.27
GCC 4.8.0 released [2013-03-22]
279275
垢版 |
2013/03/23(土) 10:20:20.80
しつこくてすみません
make[1]: *** `src/libwinpthread_la-barrier.lo' に必要なターゲット `src/.dirstamp' を make するルールがありません. 中止.
make: *** [all] エラー 2
となるんですがmakefileの該当部分は

libdummy.la: $(libdummy_la_OBJECTS) $(libdummy_la_DEPENDENCIES)
$(LINK) $(libdummy_la_OBJECTS) $(libdummy_la_LIBADD) $(LIBS)
src/$(am__dirstamp):
@$(MKDIR_P) src
@: > src/$(am__dirstamp)
src/$(DEPDIR)/$(am__dirstamp):
@$(MKDIR_P) src/$(DEPDIR)
@: > src/$(DEPDIR)/$(am__dirstamp)
src/libwinpthread_la-barrier.lo: src/$(am__dirstamp) \
src/$(DEPDIR)/$(am__dirstamp)
これでは.dirstampは作れていないのでしょうか？
280275
垢版 |
2013/03/23(土) 10:27:04.93
くっつけるerr.logを間違えました上の部分のエラーログは
process_begin: CreateProcess(NULL, /bin/mkdir -p src, ...) failed.
make (e=2): 指定されたファイルが見つかりません。
make[1]: *** [src/.dirstamp] エラー 2
make: *** [all] エラー 2
こちらです
281275
垢版 |
2013/03/23(土) 10:57:48.87
cd src
touch .dirstamp
cd .deps
touch .dirstamp
したらmakeできました
お騒がせしました
2013/03/25(月) 12:34:35.28
4.8で動かなくなる奴たくさんありそうだな

普通の実行順序で考えると動きそうだし
たまたまローカル変数ですべて収まってたから、
過度に最適化されたのかな？
2013/03/25(月) 12:48:29.38
SPECのコードが壊れた話？

C言語は高級アセンブラで、思った通りの機械語コードを吐いてくれる、
なんてのが昔話だと、いい加減みんな認識すべきなんだな。

現代のC言語は、最適化オプション付けていて、未定義を踏んでたら
悪魔と契約してでも最適化を掛けてくるもんだ、と思うべき。
2013/03/25(月) 12:53:58.03
日本語でどうぞ
2013/03/25(月) 13:01:18.08
壊れるようなコードを書いているやつが悪い
2013/03/25(月) 13:26:59.99
>>284
このスレでこの程度のジャーゴンもわからないとか。
2013/03/25(月) 13:55:39.89
>>286
単語の問題ではなく文法の問題では?
2013/03/25(月) 14:46:33.36
brokenな日本語でも日本語の話者ならば補って理解できる。
2013/03/25(月) 21:04:51.78
実行される可能性がある未定義動作のコードが一行でも混じっていれば
そのプログラムは起動直後からソースコードを一切無視してどういうふるまいをしても構わない。

過度の最適化ではない。
2013/03/25(月) 22:16:03.70
>>286
底辺職種に従事している人が多いからね
そんな奴は脳レベルが低すぎてbrokenな日本語は理解不能
2013/03/25(月) 23:31:42.31
罵倒遊びも飽きた
2013/03/28(木) 12:01:59.57
4.8、動かない以前にビルド通らんのが出てきたぞ
バージョン上がる度に型チェック厳しくなる一方だぜ
2013/04/02(火) 05:44:55.99
http://gcc.gnu.org/projects/cxx0x.html
Rvalue references for *this : GCC 4.8.1
294デフォルトの名無しさん
垢版 |
2013/04/06(土) 15:49:25.58
fast-mathオプションをつけるとisnanが機能しなくなるのだけど、何かいい手はない？
2013/04/06(土) 16:06:06.33
そのファイルだけfast-mathを外してコンパイルする。
と、どうなるか試してほしい。
296デフォルトの名無しさん
垢版 |
2013/04/06(土) 16:45:32.27
fast-mathつけなければ大丈夫。
fast-mathをつけると、isnan以外にも、a != aで判定する方法もダメ。
何かいい方法ないかな
2013/04/06(土) 16:57:51.17
-ffast-math をばらして必要なオプションだけを指定してみたら？

-ffast-math
　 Sets -fno-math-errno, -funsafe-math-optimizations,
　 -fno-trapping-math, -ffinite-math-only, -fno-rounding-math, -fno-signaling-nans and fcx-limited-range.
2013/04/06(土) 22:18:43.85
-ffast-math -fno-finite-math-only の併用でｏｋ
2013/04/08(月) 21:00:04.38
4.8ビルドしようとするとgccでintl-printと__printf__が不明と怒られる
仕方ないのでconfig.hに#include <libintl.h>を書き足すと>>255と同じ事
言われて怒られる、しかしgmp等はインスト済み
これってx64のライブラリ以外にx86のライブラリも必要って事なのかな？
2013/04/08(月) 22:29:24.61
コマンドラインまで >>255 と同じなら

× --with-gmp-lib=/usr/local/lib64
○ --with-gmp=/usr/local

mpfr,mpc も同様
2013/04/08(月) 23:18:38.75
レスありがとう！

んでも
64ビットのWindowsおよびgccだけSJLJ例外の32ビットベースのmultilibの
バージョンについては＃エラーがサポートされています。
って怒られた。。。ウチの環境はWin7x64、gccはTDM64です

configureはこれ
LIBS="-lintl -liconv " ../gcc-4.8-20130404/configure --prefix=/usr/gcc \
--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 \
--with-tune=generic --enable-threads=posix --disable-multilib --enable-static \
--enable-languages=c,c++,objc,obj-c++ --enable-libgomp --disable-sjlj-exceptions \
--with-dwarf2 --enable-version-specific-runtime-libs --disable-win32-registry \
--disable-werror --disable-nls --enable-lto --with-system-zlib \
--enable-libstdcxx-debug --enable-cxx-flags='-fno-function-sections -fno-data-sections' \
--enable-fully-dynamic-string --disable-libstdcxx-pch --disable-bootstrap \
--with-mpc-lib=/usr/tool/lib --with-mpc-include=/usr/tool/include \
--with-mpfr-include=/usr/tool/include --with-mpfr-lib=/usr/tool/lib \
--with-gmp-include=/usr/tool/include --with-gmp-lib=/usr/tool/lib \
--with-cloog-include=/usr/tool/include --with-cloog-lib=/usr/tool/lib \
--with-isl-include=/usr/tool/include --with-isl-lib=/usr/tool/lib

--disable-multilibを消しても、やっぱりx64云々で蹴られますた
ってかconfigureのログ見てると、intl=ok, iconv=okって言ってるのになんで
intlの関数が不明って言われるのかなあ。
2013/04/08(月) 23:45:08.36
消すなら --disable-multilib ではなくて --disable-sjlj-exceptions だろｊｋ

あと、もし binutils を一緒にビルドしようとして、
gcc のフォルダ内に binutils/{なんやらかんやら} へのリンクを張ってるなら、
両者に共通のライブラリが、バージョン違って失敗するかも
2013/04/09(火) 00:07:40.47
消したけどダメ。。
ターゲット・ホスト・ビルドのx86_64-w64を消さないとどうしても
「はぁ？x64？」みたいな事言われるので消して、それでもintlで文句言われて
config.hに<linintl.h>書き加えてビルド進めるとlibgccで

Assembler messages:
Error: invalid instruction suffix for `push'

アセンブラ関連のエラーだと思うんだけど、ターゲットをx86_64-w64にすると怒
られ、libintlで怒られ…gccサイトのQ&A見ても「我々は悪くない、文句言われる
テメーが悪い」みたいな事書いてあるし。。。。

もうネルソン！
2013/04/09(火) 22:43:32.74
やっとでけたあああ
七誌さんそして>>300ありがとう！
一応手順

gcc用のディレクトリを作成、binutilsをビルド→インストール
gccをコンパイラのみビルドしてinstall-gcc
ここでmsys上のmingwを今作ったgccに切り替え
mingw-w64ランタイムをヘッダのみビルド→インストール
ランタイムをビルド→インストール
gccの残りをビルド→インストール

今まで通常使ってるmingwだけでビルドしようとしてたのが間違ってた？っぽい
2013/04/09(火) 22:49:25.32
なんだかよく分からなかったけど強引に潰したエラー、3件

1.↓って言われる
i386/cygming.h:358:2: error: #error For 64-bit windows and 32-bit based multilib version of gcc just SJLJ exceptions are supported.
i386/mingw32.h:101:2: error: #error DW2 unwind is not available for 64-bit.
i386/cygming.h:358:2: error: #error For 64-bit windows and 32-bit based multilib version of gcc just SJLJ exceptions are supported.
i386/mingw32.h:101:2: error: #error DW2 unwind is not available for 64-bit.
i386/cygming.h:358:2: error: #error For 64-bit windows and 32-bit based multilib version of gcc just SJLJ exceptions are supported.
i386/mingw32.h:101:2: error: #error DW2 unwind is not available for 64-bit.
コメントアウト

2.
intl_printが不明
config.hに<libintl.h>を書き足す

3.
libstdc++-v3/include/bits/basic_string.hでエラー

call googleで外人さんのパッチをクローン
+++ ./libstdc++-v3/config/os/mingw32-w64/os_defines.h
+#include <_mingw_mac.h>
+#if !defined (__MINGW64_VERSION_MAJOR) || (__MINGW64_VERSION_MAJOR < 3)
　#define _GLIBCXX_HAVE_BROKEN_VSWPRINTF 1
+#endif

3は、なんだか公式のmingw32使えみたいな事言ってた気がするけど1.2が分からんち
特に2番、なんでヘッダを要求されるのか。公式になんか書いても怖い人しかいないよう
な雰囲気なので聞けない。。。

グダグダ書いたけど結局は>>302のbinutils云々がヒントになってビルド出来た、ありがとね
2013/04/09(火) 23:22:10.38
追記：libintlがぶっこわれてた
今までどうやってビルド通ってたんだろ・・・・・・・・・
2013/04/10(水) 12:19:18.40
馬鹿には無理
2013/04/13(土) 12:00:07.40
ネタじゃないので聞いてください。
一番最初のgccはどのようにコンパイルされたのですか？
2013/04/13(土) 13:04:09.04
別のコンパイラを使う。UNIXのccとか。

歴史の話じゃなくて実用的な意味でどうするかといえば、
オフィシャルでバイナリのgccが配布されているのでそれを使う。
2013/04/13(土) 13:12:18.33
最初のGCCはCで書かれていたわけでは無いらしい
2013/04/13(土) 13:13:20.52
ネタじゃないので聞いてください。
一番最初のccはどのようにコンパイルされたのですか？
2013/04/13(土) 13:25:22.63
最初のコンパイラは機械語で書いた
2013/04/13(土) 14:56:44.41
最初のコンパイラはA-0 Systemらしい。
2013/04/13(土) 18:04:08.51
gccをどうやってコンパイルするかを勉強してると
そのあたりまで平然と遡らされるよな
2013/04/13(土) 18:20:46.26
Z80アセンブラをN88-BASICで実装しようとしたのは良い思い出…
2013/04/13(土) 23:18:45.40
>>311
> 一番最初のccはどのようにコンパイルされたのですか？
当時一般的に使われていた, Unix 上の PCC 互換コンパイラでコンパイルされたんだが，
なんか問題あるの?
2013/04/14(日) 00:00:12.33
>>316
どこまで遡れるか大会だろ空気嫁よ
2013/04/14(日) 05:34:33.84
ネタじゃないので聞いてください。
一番最初のアセンブラはどのようにアセンブルされたのですか？
2013/04/14(日) 05:50:10.27
ネタじゃないならアセンブラスレで訊きましょう
2013/04/14(日) 10:08:15.61
２ｃｈは優秀な技術者が議論する場所
2013/04/14(日) 10:54:15.95
>>318
ハンドアセンブル
2013/04/14(日) 11:37:22.44
multilib有効にしてGCCビルドしたら、ライブラリビルドでldちゃんが
32ライブラリに64libを合体させてしまいまする
export -m32 -L/lib32 とかにしても言う事を聞いてくれませぬ
ググっても、バカには無理みたいな風潮
TDMとか、どうやってmultilibなGCCビルドしてるんだろ？
2013/05/08(水) 21:32:17.28
gccの2.95.3なんですが、
gccがコンパイルされたときの./configureに渡された設定など
調べる方法は無いでしょうか?
2013/05/09(木) 02:22:37.84
gcc -vは？

どうでもいいことだが、なぜそんな化石を使うのか聞いてみたい
2013/05/22(水) 15:12:42.53
gccで、以下のような情報を得るためのコマンドラインオプション、あるいは
ツール・手段はありませんでしょうか？

知りたいのは、どういう過程でライブラリがリンクされているかです。
例えば、main.cでprintf()が使われている時、
(1) main.o には未解決のシンボル'printf'がある
(2) 未解決シンボル'printf'を解決するため、libc.a 内の lib_a-printf.o をリンクした
(3) さらに lib_a-printf.o には未解決のシンボル'vfprintf'がある
(4) 未解決シンボル'vfprintf'を解決するため、libc.a 内の lib_a-vfprintf.o をリンクした
(5) さらに lib_a-vfprintf.o には未解決のシンボル・・・・
　　：
のような情報が得たいのです。

目的は、組み込み用でコードサイズ小さくしたい場合に、想定外のライブラリがリンク
されているような場合、何が起点になっているかを調べるためです。
(例えば、標準入出力は使ってないのに標準入出力関係のライブラリがごっそりリンクさ
れてしまう場合に、sprintf()→vfprintf()→・・・と、sprintf()を使っているのが原因
であることを知りたい)

-Wl,--verbose は試してみましたが、ダメでした。
326デフォルトの名無しさん
垢版 |
2013/05/22(水) 15:23:31.68
man(2)
327デフォルトの名無しさん
垢版 |
2013/05/22(水) 15:25:10.67
lint
2013/05/22(水) 16:31:27.29
>>325
スマートリンクを使った方がてっとりばやいんじゃね？
329３２５
垢版 |
2013/05/22(水) 19:12:38.41
>>328
レス、ありがとうございます。

スマートリンクもコードサイズ削減に効果が無くはありませんが、(newlibは結構細かく
ソースが分けてあるので)効果は小さいと思われます。

例えば、newlibの場合newlib内で使用する静的変数を(マルチスレッド対応等が容易なよ
うに)_reent構造体にまとめてありますが、これをリンクするような関数を一つでも使用
してしまうと_reent構造体に関連する関数が多数リンクされ、コードサイズが肥大します。
これは(実行時に呼ばれることは無くても)未定義シンボル解決には必要であり、
-Wl,--gc-sectionsでは防止できません。
コードサイズの肥大の起因となるライブラリ関数が(質問に記述のように)特定でき、これ
がごく少数なら、この関数を使用しないようにプログラムを書き換えてしまえ、という
わけです。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況