Q&A
環境変数の違い、処理系バイナリの違いなどはないのでしょうか？
念のため言うと、Windowsだとビルドする度に実行可能ファイルバイナリは変わる仕様だったと思うので、一般的には確認手段としてもあまりよくない気がします
実現したいこと
同じオブジェクトファイルを生成したい
前提
IDEを使わずに開発された案件を、IDEに移行しクロスデバッグ環境を
実現したいのですが、まず元と同じ実行ファイルがビルドできるよう
環境を作成しています
あくまで実現したいことは上述の内容なので、この前提を読んで違う方法
での実現方法の提案等はお控えください。
ソースの内容やファイル名などは出せません
発生している問題・エラーメッセージ
同じコンパイラのバージョン、同じオプションで、同じソースをコンパイルしても
同じオブジェクトが作成されない(中身もサイズも数バイト～数kバイト違う）
該当のソースコード（Makefile）
VPATH = ../aaa:../bbb (伏せ)
CROSS_COMPILE ?=
CXX = arm-linux-gnueabihf-g++
CXXFLAGS = -O0 -Wall -std=c++0x -Wextra
INCLUDES = -I..
LDFLAGS = -L../extra/lib
LDLIBS = -lpthread -lrt -lcurl -ljson-c
EXEC = zzzz(伏せ)
CPP_SRCS =
xxx/yyy.cpp(伏せ)
(省略）
OBJS = $(notdir $(CPP_SRCS:.cpp=.o))
all: $(EXEC)
$(EXEC): $(OBJS)
$(CXX) $(CXXFLAGS) $(LDFLAGS) -o $@ $(OBJS) $(LDLIBS)
cp -a $(EXEC) $(EXEC).org
arm-linux-gnueabihf-strip $(EXEC)
%.o: %.cpp
$(CXX) $(CXXFLAGS) $(INCLUDES) -c -o $@ $<
jjj/kkk.o: ../jjj/kkk.cpp(伏せ)
$(CXX) $(CXXFLAGS) $(INCLUDES) -c -o $@ $<
clean:
-rm -rf $(EXEC) $(OBJS) $(EXEC).org
eclipseの結果に合わせるように変更してます
試したこと
ひたすらオプションやビルド順序も含めて同じになるようにした
eclipseでビルド時のオプションに--versionを付けて実行して、バージョンがあっている
ことを確認した（これだとビルドは失敗するのであくまで確認のため）
補足情報
・eclipseのビルド時のコマンド
arm-linux-gnueabihf-g++ -O0 -Wall -std=c++0x -Wextra -I.. -c -o ccc.o ddd.cpp
（makefileの結果もテキスト比較アプリに張り付けて確認しましたが同じでした）
・環境
OS:Linux,debian系,32bit
eclipse:ver3.8.1
・arm-linux-gnueabihf-g++ (Debian 6.3.0-18) 6.3.0 20170516
・差分を実際に計算してみたら、4096byteちょうどでした。
問題解決に関係あるかわかりませんが。
OS:Linux,debian系,32bitです。
自作のメイクファイル、あるいはeclipseどちらか一方ではオブジェクトファイルが毎回違うということはありません。
また実行可能ファイルではなくオブジェクトファイルの段階で違います。
一般的な確認手段という意味なので、LinuxとWindowsの区別もなくし、実行可能ファイルなのか、オブジェクトファイルなのかの区別もなくしています。
処理系は同じアプリ、バージョンでもビルド段階のconfig設定でも違いますし、Linuxだとdistributionごとにパッチの当て方も違うことがあり、細かいことを言うと違うと思いますよ。
気にしているのはeclipseから呼んでいる処理系とコマンドラインから呼んでいる処理系が違う可能性があるとか、環境変数の違いによる挙動の違いがあるとかですね。
その辺の情報が不十分なのです。
eclipseのコンパイル実行結果を見る限り同じコマンドなのですが、
同じコンパイラに同じ引数を与えても、異なる処理系が呼ばれて
コンパイルされることがあるということでしょうか？
はい
回答ありがとうございました。
処理系とは具体的になんでしょうか。
コンパイラからみて、引数以外の何を見て処理を変えているのでしょうか。
処理系とはここではコンパイラなどソースからバイナリを生成する際に必要な諸々のファイルセットのことです。
コンパイラというよりプロセスから見ると環境変数やバイナリ生成に必要なファイルですね。
コンパイラは同じバージョンを使用しています。
コンパイラがソースコードを解読してオブジェクトファイルを生成していると思うのですが、
おっしゃっているプロセスは何を指しますか？
全然伝わっていないようですね。クロスコンパイラが2つ以上入っている可能性を危惧しています。eclipseというだけではどんなものか分からないので。前に言ったとおり、同じバージョンであってもバイナリが同じとは限りません。
プロセスとはpsコマンドやtopコマンドで出てくるアレのことです。
そろそろ
> 環境変数の違い、処理系バイナリの違いなどはないのでしょうか？
にご回答ください。
ご質問は違うコンフィギュレーションでビルドされた同じバージョンのクロスコンパイラが
2つ以上システムに入っていて、違うものを実行してコンパイルしていないか？ですね？
回答しますとeclipseの設定上は自作Makefileでコンパイルするためにインストールした
G++と同じ、/usr/binの下のarm-linux-gnueabihf-g++を参照しています。
コンパイラが複数含まれていないか、検索してみた結果を添付します
これでは調べたことにならないようでしたら、他に調べる方法を教えてください。
XXXXX@YYYYY:/$ which arm-linux-gnueabihf-g++
/usr/bin/arm-linux-gnueabihf-g++
XXXXX@YYYYY:/$ sudo find / -name arm-linux-gnueabihf-g++
[sudo] XXXXX のパスワード:
/usr/bin/arm-linux-gnueabihf-g++
XXXXX@YYYYY:/$ echo $PATH | tr ':' '\n' | xargs -I {} find {} -name arm-linux-gnueabihf-g++
/usr/bin/arm-linux-gnueabihf-g++
環境変数は実行時に調べないと意味がありません。
makeプロセス自体に与える引数でも変わるし、IDEが何をしているか分からないので。
eclipse(CDT)がどんなものなのかも簡単に教えてください。
すみません。私も使いこなしているわけではないので本当にうわべだけなのですが
eclipseが統合開発環境で、Java以外は最初から特定のプログラムを開発するようには
できていない、VSCODEみたいなものです。CDTはeclipseでCまたはC++で開発する
ためのプラグインになります。
コンパイラのディレクトリ（/usr/bin）、prefix（arm-linux-gnueabihf-）、コマンド（g++）、
が指定できるようになっており、また実行時にそのコマンドがコンソールで見えるようになって
いて、バージョンはそこで確認しました。
いやご使用のeclipse CDTの構成や設定を知りたかっただけなんですが。。。CDT自体の概要は使った事があるので知ってます。
でも普通の使い方のようですし、まずは環境変数を見てもらえますか？
終わったらobjdumpで違う部分を調べてください。
あ、素のeclipseにCDTを入れたのではなく、arm用のやつを拾ってきたりしてないですよね？
環境変数の表示結果を添付します。
ZZZZ:~/workspace/env
CLUTTER_IM_MODULE=xim
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:
XDG_MENU_PREFIX=gnome-
LANG=ja_JP.UTF-8
GDM_LANG=ja_JP.UTF-8
DISPLAY=:0
COLORTERM=truecolor
USERNAME=YYYY
XDG_VTNR=2
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
XDG_SESSION_ID=2
USER=YYYY
DESKTOP_SESSION=default
QT4_IM_MODULE=uim
QT_QPA_PLATFORMTHEME=qgnomeplatform
PWD=/home/YYYY/workspace/XXXXX
HOME=/home/YYYY
JOURNAL_STREAM=8:19205
SSH_AGENT_PID=1184
QT_ACCESSIBILITY=1
XDG_SESSION_TYPE=x11
XDG_DATA_DIRS=/usr/share/gnome:/usr/local/share/:/usr/share/
MALLOC_CHECK_=2
XDG_SESSION_DESKTOP=default
GJS_DEBUG_OUTPUT=stderr
GTK_MODULES=gail:atk-bridge
WINDOWPATH=2
SHELL=/bin/bash
TERM=xterm-256color
VTE_VERSION=4601
QT_IM_MODULE=uim
XMODIFIERS=@im=uim
XDG_CURRENT_DESKTOP=GNOME
GPG_AGENT_INFO=/run/user/1000/gnupg/S.gpg-agent:0:1
QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1
SHLVL=1
XDG_SEAT=seat0
WINDOWID=27265119
GDMSESSION=default
GNOME_DESKTOP_SESSION_ID=this-is-deprecated
LOGNAME=ZZZZ
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
XDG_RUNTIME_DIR=/run/user/1000
XAUTHORITY=/run/user/1000/gdm/Xauthority
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
GJS_DEBUG_TOPICS=JS ERROR;JS LOG
SESSION_MANAGER=local/YYYY:@/tmp/.ICE-unix/1101,unix/ZZZZ/tmp/.ICE-unix/1101
GTK_IM_MODULE=uim
_=/usr/bin/env
OLDPWD=/home/YYYY/workspace/XXXX
特別なところから拾ってきたものではなく、素のeclipseに登録されているサイトからのInstall機能を
つかったので、普通のCDTが入っていると思います。Installation Detailsを添付します
C/C++ Development Tools 8.0.2.201202111925 org.eclipse.cdt.feature.group Eclipse CDT
C/C++ Development Tools SDK 8.0.2.201202111925 org.eclipse.cdt.sdk.feature.group Eclipse CDT
C/C++ GCC Cross Compiler Support 1.0.2.201202111925 org.eclipse.cdt.build.crossgcc.feature.group Eclipse CDT
C/C++ Remote Launch 6.0.0.201202111925 org.eclipse.cdt.launch.remote.feature.group Eclipse CDT
Eclipse CVS Client 1.3.200.dist-7B79FJJ9exZ_ org.eclipse.cvs.feature.group Eclipse.org
Eclipse CVS Client Resources 1.3.200.dist-7B79FJJ9exZ_ org.eclipse.cvs.source.feature.group Eclipse.org
Eclipse Help Developer Resources 1.4.1.dist-987tFQDFAuKLTsEBE4 org.eclipse.help.source.feature.group Eclipse.org
Eclipse Java Development Tools 3.8.1.dist-8-8nFqrFFgQGJ org.eclipse.jdt.feature.group Eclipse.org
Eclipse PDE Plug-in Developer Resources 3.8.1.dist-7c7vFiyFALX8A org.eclipse.pde.source.feature.group Eclipse.org
Eclipse Platform 3.7.0.debbuild org.eclipse.platform.ide null
Eclipse Plug-in Development Environment 3.8.1.dist-7c7vFiyFALX8A org.eclipse.pde.feature.group Eclipse.org
Equinox p2 RCP Management Facilities Source 1.1.0.dist-785EoAUkckGofGLmS7BA7 org.eclipse.equinox.p2.rcp.feature.source.feature.group Eclipse.org - Equinox
Remote System Explorer End-User Runtime 3.3.2.R33x_v201110030150-7L7CFGH8wqio8s-qYtkPgn8qWd4T org.eclipse.rse.feature.group Eclipse TM Project
Remote System Explorer User Actions 1.1.300.v201103142315-31F8N8s7355353B75DD org.eclipse.rse.useractions.feature.group Eclipse TM Project
投げっぱなしみたいな感じになって申し訳ありません。
上記の内容をどういう観点で見ればよいか教えて頂ければ、自分で見てみようと思います。
環境変数についてはコマンドラインからmakeした場合と、eclipseからmakeした場合で異なるかの確認です。違いはないですか？
というか言ってる意味が伝わってませんね。。。
実行時の環境変数って言ってるのは、Makefileの
%.o: %.cpp
の直後に
env >$@.env.log 2>&1
$(CXX) -v >>$@.env.log 2>&1
でも入れておいたらどうかくらいの意味です。最初のやつは環境変数取れるし次のやつはg++のconfigが取れます。各objについて出るので邪魔くさいですが。。。
あと以下も追加
which $(CXX) >>$@.env.log 2>&1
実行時に呼ばれるg++バイナリが分かります
eclipseでは通常のg++が呼ばれているのかなと思い、今度は/usr/bin/g++をリネームして試してみたのですが普通にコンパイルできていてオブジェクトファイルの結果はかわりませんでした。
引き続き自分なりに調べてみます。
まずeclipseで何のプロジェクトを使っているのかをきちんと質問文に書きましょう。
その設定も他の人が再現できるよう正確に記述する必要があります。
とりあえず以下のようにやってみて…
C++ Managed Build Projectを作成
Hello World C++ Proejctを選択
ProjectのPropertyからC/C++ Build>Settingsにある各ToolのCommandにprefixとしてarm-linux-gnueabihf-を追加
projectをbuild
→workspace上のprojectのDebug/src/プロジェクト名.oにオブジェクトが生成されるのでプロジェクト名.o.eclipseにコピー
workspace上のprojectのDebugにMakefile.orgを作成
以下の内容を記述
CXX = arm-linux-gnueabihf-g++
CXXFLAGS = -O0 -g3 -Wall -fmessage-length=0
EXEC = zzzz
CPP_SRCS = src/プロジェクト名.cpp
OBJS = $(CPP_SRCS:.cpp=.o)
all: $(EXEC)
$(EXEC): $(OBJS)
$(CXX) $(CXXFLAGS) $(LDFLAGS) -o $@ $(OBJS) $(LDLIBS)
arm-linux-gnueabihf-strip $(EXEC)
src/%.o: ../src/%.cpp
$(CXX) $(CXXFLAGS) $(INCLUDES) -c -o $@ $<
clean:
rm -rf $(EXEC) $(OBJS)
workspace上のprojectのDebugでmake -f Makefile.orgを実行
cmp プロジェクト名.o.eclipse プロジェクト名.o
で戻り値が0であることを確認
できました。つまりバージョンやコンパイルオプションなどは一致してないのですが、オブジェクトファイルの一致が確認できたということです。
質問者さんのMakefileの暗黙ルールから察するに、ソースが別の場所にありそうなので、デバッグ情報分違っているとかではないでしょうか？
参考情報です。amd64で同じファイルを別のディレクトリからデバッグ情報付きコンパイルした場合のオブジェクトファイルを比較するshellスクリプトを書いてみました。
src=hoge.cpp
obj=$(echo $src | sed 's/\.cpp$/.o/')
cat >$src <<EOF
int main() { return 0; }
EOF
envs="build1 build2"
for i in $envs; do
mkdir $i
pushd $i
g++ -c -g ../$src -o $obj
strings $obj > $obj.strings
objdump -S $obj > $obj.S
strip $obj -o $obj.stripped
popd
done
diff -uprN build* | tee build.diff
結論から言うと、デバッグ情報部分にディレクトリ情報が載ってしまい、異なるという結果になりました。
$ bash hoge.sh
/run/user/1000/tmp/build1 /run/user/1000/tmp
/run/user/1000/tmp
/run/user/1000/tmp/build2 /run/user/1000/tmp
/run/user/1000/tmp
バイナリーファイル build1/hoge.o とbuild2/hoge.o は異なります
diff -uprN build1/hoge.o.strings build2/hoge.o.strings
--- build1/hoge.o.strings 2023-10-10 20:17:40.710873020 +0900
+++ build2/hoge.o.strings 2023-10-10 20:17:40.742866608 +0900
@@ -1,6 +1,6 @@
hoge.cpp
main
-/run/user/1000/tmp/build1
+/run/user/1000/tmp/build2
../hoge.cpp
GNU C++14 9.4.0 -mtune=generic -march=x86-64 -g -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protection -fcf-protection
GCC: (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0
$
一応ちゃんと書いておくと、
> eclipseでは通常のg++が呼ばれているのかなと思い、今度は/usr/bin/g++をリネームして試してみたのですが普通にコンパイルできていてオブジェクトファイルの結果はかわりませんでした。
は見解として間違ってると思います。Makefileは理解して使ってますか？
なぜか今は調べた結果がコメントから削除されてるので意味不明になってますが。。。
デバッグオプション無しにしていたのですが、それでもデバッグ情報としてメイクしたディレクトリが埋まってしまうものなんですね。
makeするディレクトリを自作makefileと同じ場所を指定することで同じオブジェクトを生成することができました。
ありがとうございました。
ベストアンサーにしたいので、回答として記入して頂けませんか？
質問内容すら明確に出来てないのに、回答なんて出来ませんよ
まずは以下を実施してください。
> まずeclipseで何のプロジェクトを使っているのかをきちんと質問文に書きましょう。
> その設定も他の人が再現できるよう正確に記述する必要があります。
また
> デバッグオプション無しにしていたのですが、それでもデバッグ情報としてメイクしたディレクトリが埋まってしまうものなんですね。
この情報のソースは何ですか？
> makeするディレクトリを自作makefileと同じ場所を指定することで同じオブジェクトを生成することができました。
そうなのであれば、他の人が確実に再現できるように情報を正確にした上で自己解決回答を載せてください。
私がデバッグ情報を付けていた(-g)のは、当初の目的にあった「IDEに移行しクロスデバッグ環境を実現したい」を実施する上で必要だと思ったからです。
回答1件
0
ベストアンサー
IDEを使わずに開発された案件を、IDEに移行しクロスデバッグ環境を
実現したいのですが、まず元と同じ実行ファイルがビルドできるよう
環境を作成しています
もしかして、セルフコンパイラ環境とクロスコンパイラとで同じ実行ファイル、という話なんでしょうか。
それはどだいムリムリな話なので諦めましょう
投稿2023/10/06 12:19
総合スコア88163
あなたの回答
tips
プレビュー
