我已经构建了一个像这样的简单程序：
g++ application.cpp -o application.exe
然后执行命令；
ldd application.exe
...
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
...
我想列出libc库的所有符号：
nm /lib/x86_64-linux-gnu/libc.so.6
nm: /lib/x86_64-linux-gnu/libc.so.6: no symbols
nm --defined-only /lib/x86_64-linux-gnu/libc.so.6
nm: /lib/x86_64-linux-gnu/libc.so.6: no symbols
为什么 nm 报告没有符号？如果 libc.so.6 不是库，而是某种指向实际库的链接，那么我如何才能找到实际库？
据我所知，一些数学函数包含在 libc 中，而另一些则包含在 libm 中。我通过实验发现：
$ nm --dynamic --defined-only /lib/x86_64-linux-gnu/libm.so.6 | grep -w abs
$ nm --dynamic --defined-only /lib/x86_64-linux-gnu/libc.so.6 | grep -w abs
T abs
是否有关于 libm 必须提供哪些数学函数的要求？libc 和 libm 是否一起提供 C 标准所需的所有数学函数？
我对这些库有点困惑。我现在在 Ubuntu 上工作，我使用 g++ 5，我看到我的应用程序链接在 libc.so 中。它是 Ubuntu 对 C 标准库的实现吗？它与 glibc 不同吗？
$ ldd application.exe
...
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
...
在编译阶段扩展UB的原因是什么？遇到UB代码时,不是编译和链接二进制文件,而是让二进制文件服从UB？(如果不可能生成二进制文件,那么只需打印一条关于它的错误消息.)
毕竟,我们期望从编译器的最确切的报告汇编即使在源代码中包含UB-代码(几乎每件的源代码可能包含一些UB-代码).
您能给这样的UB-代码一个具体的例子,这确实更有道理,让编译器表现出UB比让生成的二进制表现出UB？
这个问题源于这一点:"未定义的行为"是否扩展到编译时？