なぜfreebsdのlibstdC++にlibc.soへのリンクが必要なのですか？

freebsd libstdC++。ではlibc.soにリンクしていませんが、open、closeなどの関数を呼び出す必要があります。 Linux上で言うように、なぜlddの出力にリストされていないのですか？なぜfreebsdのlibstdC++にlibc.soへのリンクが必要なのですか？

freebsd$ ldd libstdc++.so 
libstdc++.so: 
libm.so.2 => /usr/lib/libm.so.2 (0x21113000) 

linux$ ldd libstdc++.so.6 
linux-vdso.so.1 => (0x00007fff2d316000) 
libm.so.6 => /lib/libm.so.6 (0x00007fdd043e9000) 
libc.so.6 => /lib/libc.so.6 (0x00007fdd04066000) 
/lib64/ld-linux-x86-64.so.2 (0x00007fdd04995000) 
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007fdd03e4f000)

出典

2011-01-19 Spacen Jasset

あなたはどのFreeBSDバージョンでこれを試していますか？ libm.soバージョンからはかなり古いようです。とにかく、少なくともFreeBSD 7.X、8.X、9.X ldd libstdC++。ではlibc.soが出力に表示されます。 – Grrrr

古いですが、FreeBSD 4.11です。これは、libc.soが何とかlibstdC++にリンクされていることを意味しますか？このバージョンでは静的なので？ –

私はそうは思わないが、とにかく問題にはならないと思われる。なぜなら、通常どんなプログラムもlibcにリンクされており、libstdC++がlibcからどのシンボルを使用していたとしても、それらを解決することができたからである。 – Grrrr

open()、close()機能がlibcからではありません。彼らはFreeBSDのネイティブAPIです

出典

2011-03-15 06:26:00 ybunny

ここでネイティブが何を意味するのか分かりません。しかし、LinuxとFreeBSDのどちらの場合でも、open（）ユーザ・コールは何とかカーネルを呼び出さなければならないと仮定します.linuxの場合は、libcでもsyscall経由でもディスパッチを中断してもかまいません。 –

なぜfreebsdのlibstdC++にlibc.soへのリンクが必要なのですか？

答えて

関連する問題