gcc在mac OS X上默认使用C链接数学库？

从这个问题：

我知道C数学库（libm）与C标准库（libc）是分开的，默认情况下不链接

但是当我在mac osx 10.11.1上使用

gcc filename.c

而不使用

-lm

编译下面的代码时 :

我想知道mac上是否存在一些库结构差异

还是gcc 5.2.0的新功能

非常感谢

更新：

$ ls -l /usr/lib/libm.dylib
lrwxr-xr-x  1 root  wheel  15  3 Jun 01:39 /usr/lib/libm.dylib@ -> libSystem.dylib

我用以下命令更改了代码：

    double in = 0;
    scanf("%lf", &in);
    double x = sqrt(in);

而且它仍然不需要

-lm

我用

otool-vVt

分解代码：

(__TEXT,__text) section
_main:
0000000100000eed    pushq   %rbp
0000000100000eee    movq    %rsp, %rbp
0000000100000ef1    subq    $0x10, %rsp
0000000100000ef5    pxor    %xmm0, %xmm0
0000000100000ef9    movsd   %xmm0, -0x10(%rbp)
0000000100000efe    leaq    -0x10(%rbp), %rax
0000000100000f02    movq    %rax, %rsi
0000000100000f05    leaq    0x82(%rip), %rdi        ## literal pool for: "%lf"
0000000100000f0c    movl    $0x0, %eax
0000000100000f11    callq   0x100000f54             ## symbol stub for: _scanf
0000000100000f16    movq    -0x10(%rbp), %rax
0000000100000f1a    movd    %rax, %xmm0
0000000100000f1f    callq   0x100000f5a             ## symbol stub for: _sqrt
0000000100000f24    movd    %xmm0, %rax
0000000100000f29    movq    %rax, -0x8(%rbp)
0000000100000f2d    movq    -0x8(%rbp), %rax
0000000100000f31    movd    %rax, %xmm0
0000000100000f36    leaq    0x55(%rip), %rdi        ## literal pool for: "The square root of 2.0 is %f\n"
0000000100000f3d    movl    $0x1, %eax
0000000100000f42    callq   0x100000f4e             ## symbol stub for: _printf
0000000100000f47    movl    $0x0, %eax
0000000100000f4c    leave
0000000100000f4d    retq

似乎调用了

sqrt

。那么为什么mac上的情况会有所不同呢

更新：

我在这个问题上得出结论：

上面说，在OSX上，数学库是libSystem的一部分：

$ ls -l /usr/lib/libm.dylib
lrwxr-xr-x  1 root  wheel  15  3 Jun 01:39 /usr/lib/libm.dylib@ -> libSystem.dylib

---

sqrt

是作为内置编译器提供的，因此不需要指向该库的链接（事实上，这样做仍然是一种很好的做法，因此它可以在其他地方编译）

Per:

除非指定了

-fno-builtin

（或为单个功能指定了

-fno-builtin-function

），否则ISO C90功能[包括

sqrt的长列表

]均被视为内置功能。所有这些函数都有相应的版本，前缀为

\uuuu内置

如果您使用
-fno-builtin
编译，我预计在链接阶段会出现故障。
sqrt
是作为内置编译器提供的，因此不需要指向库的链接（事实上，这样做仍然是很好的做法，因此它可以在其他地方编译）

Per:

除非指定了
-fno-builtin
（或为单个功能指定了
-fno-builtin-function
），否则ISO C90功能[包括
sqrt的长列表
]均被视为内置功能。所有这些函数都有相应的版本，前缀为
\uuuu内置

如果您使用
-fno-builtin
编译，我预计链接阶段会失败。
OSX上没有单独的数学库。虽然许多系统将标准C math.h头中的函数放在单独的数学库中，但OSX并没有这样做，它是libSystem库的一部分，该库始终链接在中

除此之外，如果编译器可以在编译时执行计算，它可能会优化掉任何此类调用。
OSX上没有单独的数学库。虽然许多系统将标准C math.h头中的函数放在单独的数学库中，但OSX并没有这样做，它是libSystem库的一部分，该库始终链接在中

除此之外，如果编译器可以在编译时执行计算，它可能会优化掉任何此类调用。
也许编译器知道什么是
sqrt（2.0）
（我知道），因此它不必调用库。@Boperson可能这是真正的原因。你们知道C数学库中一些编译器无法优化的函数吗？我想试试。谢谢！如果值在编译时不知道，它将不得不调用函数，就像它来自某个输入。@BoPersson它似乎不起作用……也许编译器知道
sqrt（2.0）
是什么（我知道），所以它不必调用库。@BoPersson也许这是真正的原因。你们知道C数学库中一些编译器无法优化的函数吗？我想试试。谢谢！如果值在编译时未知，它将不得不调用该函数，比如它来自某个输入。@BoPersson它似乎不起作用……所以它是由OS X系统而不是gcc编译器引起的？或者C数学库中的
sqrt（）
函数实际上没有被调用？我怎么才能知道呢？谢谢：PSo是由于OSX系统而不是gcc编译器引起的？或者C数学库中的
sqrt（）
函数实际上没有被调用？我怎么才能知道呢？谢谢：我刚才很累。添加
-fno-builtin
后仍然没有失败。我刚才很累。添加
-fno builtin
后仍然没有故障。
$ ls -l /usr/lib/libm.dylib
lrwxr-xr-x  1 root  wheel  15  3 Jun 01:39 /usr/lib/libm.dylib@ -> libSystem.dylib