_end
Linux では、D ランタイム ライブラリはシンボルに依存してGC ルート範囲 ( man 3 end
) を決定します。これは実際、Boehm GC が行うことと非常によく似ています。ただし、libcurl でリンクすると、リンカーによってシンボルが検出されなくなります。
$ cat test.c
#include <stdio.h>
extern char _end[];
int main() {
printf("%p\n", &_end);
return 0;
}
$ gcc test.c # works
$ gcc test.c -lcurl
/usr/bin/ld: /tmp/ccOPtbEv.o: undefined reference to symbol '_end'
/usr/bin/ld: note: '_end' is defined in DSO /usr/lib/libssl.so.1.0.0 so try adding it to the linker command line
/usr/lib/libssl.so.1.0.0: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
D フォーラムでの簡単な検索から、libpq、libdw、および他のいくつかのライブラリが同じ問題を引き起こしているようです。ここで何が起こっているのでしょうか?test.c
libcurl のシンボルにも依存しません。(Arch Linux x86_64、GCC 4.7.2、ld 2.23)
また、「libssl でリンクを試す」は私が探している答えではないことに注意してください。ここで何が起こっているのかを理解したいのです。私が取り組んでいるコンパイラでこの問題を修正しようとしているので、リンクプロセスがどのように機能するかについて基本的な知識があると想定できます。
編集: libssl にリンクするようにユーザーに指示することに特に満足していない理由は、...、明示的に、、pkg-config --libs curl
などcurl-config --libs
にこの情報が含まれていないためです。したがって、それを要求するとビルドシステムが壊れます。データ (初期化および BSS) セグメントの境界を決定するためのより良いアイデアを誰かが持っている場合は、ぜひ知りたいと思います。
編集 2: 上記のツールチェーンでは、end
(アンダースコアなしで) も定義されているようで、問題は発生しません。ただし、なぜそれが発生するのかについてはまだ困惑しています。