问题来自链接器,ld
而不是 gcc(因此出现退出状态消息)。通常 ld 要求按顺序指定对象和库user
supplier
,其中user
是使用库函数supplier
的对象并且是提供它的对象。
当你test.c
被编译成一个对象时,编译器声明 fmod 是一个未定义的引用
$ gcc -c test.c
$ nm test.o
U fmod
0000000000000000 T main
(nm 列出了目标文件引用的所有函数)
链接器将未定义的引用更改为已定义的引用,查找引用以查看它们是否在其他文件中提供。
$ gcc -lm test.o
$ nm a.out
0000000000600e30 d _DYNAMIC
0000000000600fe8 d _GLOBAL_OFFSET_TABLE_
00000000004006a8 R _IO_stdin_used
w _Jv_RegisterClasses
0000000000600e10 d __CTOR_END__
...
0000000000601018 D __dso_handle
w __gmon_start__
...
U __libc_start_main@@GLIBC_2.2.5
0000000000601020 A _edata
0000000000601030 A _end
0000000000400698 T _fini
0000000000400448 T _init
0000000000400490 T _start
00000000004004bc t call_gmon_start
0000000000601020 b completed.7382
0000000000601010 W data_start
0000000000601028 b dtor_idx.7384
U fmod@@GLIBC_2.2.5
0000000000400550 t frame_dummy
0000000000400574 T main
其中大部分是指在 main 之前和之后运行以设置环境的 libc 函数。您可以看到 fmod 现在指向 glibc,它将由共享库系统解析。
我的系统默认设置为使用共享库。如果我改为强制静态链接,我会得到您看到的订单依赖项
$ gcc -static -lm test.o
test.o: In function `main':
test.c:(.text+0x40): undefined reference to `fmod'
collect2: ld returned 1 exit status
稍后-lm
在链接器命令中,after test.o
,允许它成功链接。检查符号 fmod 现在应该被解析为实际地址,确实是
$ gcc -static test.o -lm
$ nm a.out | grep fmod
0000000000400480 T __fmod
0000000000402b80 T __ieee754_fmod
0000000000400480 W fmod