什么是core文件

在Linux下遇到程序异常退出或者中止，操作系统通常会把程序当前的工作状况存储在一个名为core的文件中，其中包含了程序运行时的内存、寄存器和堆栈指针等信息，格式为ELF，这个过程叫做coredump，又称作核心转储。

通过工具分析这个文件，我们可以定位到程序异常退出或者终止时相应的堆栈调用等信息。

如何生成core文件

查看coredump是否生效

1
2
3
4

$ ulimit -a
...
-c: core file size (blocks)         0
...

0 表示core文件大小限制为0，不允许写入，所以无法生成core文件，需要修改为正数大小或unlimited才可使coredump生效。

修改core文件大小的限制

取消core文件大小限制：

1
2
3
4
5

ulimit -c unlimited
ulimit -a
...
-c: core file size (blocks)         unlimited
...

也可以对core文件的大小进行有效限制，单位为blocks，一般1 block=512 bytes，设置太小可能导致不会生成文件：

1
2
3
4
5

$ ulimit -c 1024
$ ulimit -a
...
-c: core file size (blocks)         1024
...

上面对core文件的操作仅对当前生效，若需要永久生效，则要将相应操作写入/etc/profile。

设置core文件存储路径

core文件默认存储在程序的工作目录，可以通过命令cat /proc/sys/kernel/core_pattern 查看。

在文件/etc/sysctl.conf末尾加入如下信息，可以指定core文件的存储路径：

1

kernel.core_pattern=/dumpdir/core_%e_%p_%t

控制core文件的文件名中是否添加pid作为扩展：

1

echo "1" > /proc/sys/kernel/core_uses_pid  

/proc/sys/kernel/core_uses_pid这个文件的值若为１，则无论是否配置%p，最后生成的core文件都会添加pid。

通常情况下，重启即可生效。

附core文件命名使用的参数列表：

1
2
3
4
5
6
7

%p - insert pid into filename  # 添加 pid 
%u - insert current uid into filename  # 添加当前 uid 
%g - insert current gid into filename  # 添加当前 gid 
%s - insert signal that caused the coredump into the filename  # 添加导致产生 core 的信号 
%t - insert UNIX time that the coredump occurred into filename  # 添加 core 文件生成时的 unix 时间 
%h - insert hostname where the coredump happened into filename  # 添加主机名 
%e - insert coredumping executable name into filename  # 添加命令名

关闭apport.service服务

Ubuntu 20.04中，执行完上述操作，会发现还是无法在指定目录生成core文件。

查看core文件存储路径：

1
2

$ cat /proc/sys/kernel/core_pattern
|/usr/share/apport/apport %p %s %c %d %P %E

发现core文件存储路径并非自己设置的，而是由管道交给了一个apport的程序，通过查询可知其是Ubuntu官方为了自动收集错误，生成程序崩溃报告的一个服务，即apport.service。

我们可以关闭apport.service这个服务：

1

sudo service apport stop

使用sudo service apport start可以开启这个服务。

如果这个命令无效的话，可以修改/etc/default/apport文件，将enabled改成0。

如上，可以在指定路径生成core文件。

使用core文件调试

可以使用gdb对core文件进行调试：

1
2
3
4
5
6
7
8
9
10
11
12
13

$ gdb a.out
...
(gdb) core-file core
...
(gdb) bt 
...

or

$ gdb a.out core
...
(gdb) bt 
...

编译可执行程序时需要带上-g选项。

如需要在PC上调试嵌入式设备产生的core文件，则需要选取相应平台的gdb工具，并在进入gdb后设置符号文件的位置：

1
2
3
4
5
6
7
8

$ xxx-xxx-gdb a.out
...
(gdb) solib-search-path xxx.so:xxx.so
...
(gdb) core-file core
...
(gdb) bt
...

简介

wav即wave（下文统称为wav）, 该文件格式是由微软开发的用于音频数字存储的标准，可应用于Windows、Linux和MacOS等多种操作系统，文件扩展名为.wav，是waveform的简写。

wav文件结构

在Windows下，大部分多媒体文件都遵循RIFF（Resource Interchange File Format，资源互换文件格式）格式来存储数据。

RIFF文件的基本存储单位称为块（chunk），一个遵循RIFF格式的文件由若干个chunk组成，每个chunk又由块标识、块长度和块数据三部分构成，其基本结构见表1：

**表1** `chunk`基本结构

• 块标识：用于标识块中的数据，由4个ASCII字符组成，如不满4个字符则在右边以空格充填，如：RIFF、LIST、fmt 和data等；
• 块长度：用于标识块数据域中的数据长度，块标识域和块长度域不包括在其中，所以一个chunk的实际长度为该值加8;
• 块数据：存储块数据，若数据长度为奇数，则在最后添加一个NULL；

特别需要注意的是，RIFF格式规定只有块标识为RIFF或LIST的块可以含有子块（subChunk），而其它块只可以包含数据。块标识为RIFF或LIST的块的结构与表1大致相同，只不过其块数据域分为两部分：

• type：由4个ASCII字符组成，代表RIFF文件的类型，如WAVE和AVI ，或者代表LIST块的类型，如avi文件中的列表hdrl和movi；
• data：实际的块内容，包含若干subChunk；

wav文件是非常简单的一种RIFF文件，其本身就是由一个块标识为RIFF的chunk和多个subChunk组成的一个chunk，其组成如下：

• RIFF chunk：主块，必选，块标识为RIFF，说明这是一个RIFF文件，RIFF文件的第一个块标识必须是RIFF；
• Format chunk：子块，必选，块标识为fmt ，用于存储文件的一些参数信息，比如采样率、通道数和编码格式等；
• Fact chunk：子块，可选，块标识为fact，基于压缩编码的wav文件必须含有fact块；
• List chunk：子块，可选，块标识为LIST，用于记录文件版权和创建时间信息；
• Data chunk：子块，必选，块标识为data，用于存储音频数据；

目前业界标准的wav文件仅由RIFF chunk、Format chunk和Data chunk组成：

wav文件头格式

wav文件从数据类型上看，主要由文件头和数据体两部分组成：

• 文件头：由RIFF chunk、Format chunk、List chunk和Fact chunk等组成，用于存储一些文件信息；
• 数据体：由Data chunk组成，用于存储音频数据；

标准格式

标准的wav文件头仅由RIFF chunk和Format chunk组成，长度为44个字节，格式见表2：

**表2** 标准的`wav`文件头格式

通过wav文件头信息，我们可以计算出音频时长:

1

音频时长(s) = Subchunk2 Size / ByteRate

压缩编码格式

wav文件几乎支持所有ACM规范的编码格式，其信息存储在wav文件头偏移20、21两个字节中，常见的压缩编码格式见表3：

**表3** 常见的压缩编码格式

扩展格式

当然，也不是所有的wav文件头都是44个字节的，比如通过FFmpge编码而来的wav文件头通常大于44个字节，目前比较常见的wav文件头长度有44字节、46字节、58字节和98字节。

Format chunk扩展

当wav文件采用非PCM编码即压缩格式时，会扩展Format chunk，在其之后扩充了一个数据结构，见表4：

**表4** 标准Format chunk扩展格式

由此可以得出，如果Subchunk1 Size等于0x10(16)，表示不包含Format chunk扩展，wav文件头长度为44字节；如果大于0x10(16)，则包含Format chunk扩展，扩展长度的最小值为18(16+2)，此时wav文件头大于44字节。

当编码格式代码为0xFFFE时，Format chunk扩展长度为24字节，格式见表5。

**表5** 编码为0xFFFE的Format chunk扩展格式

Fact chunk

采用压缩编码（修订版Rev.3以后出现的编码格式）的wav文件必定有含有Fact chunk，其结构符合标准chunk结构，参见表1。

Fact chunk的块标识符为”fact“，块长度至少为4个字节，目前其只有一个块数据内容，即每个声道采样总数，或采样帧总数。该值等于Subchunk2 Size / BlockAlign。

值得注意的是，在实测中发现，将压缩编码格式文件转换成PCM编码格式后，原Fact chunk仍然存在。

wav文件动态解析库

wav文件格式是一种极其简单的文件格式，如果对其结构足够熟悉，完全可以通过代码正确读写，从而免去引入一些复杂的中间库，降低复杂度，提高工作效率。

这里提供了一个wav文件动态解析库，欢迎使用。

Reference

• WAVE PCM soundfile format
• wav音频文件头动态解析–java语言
• 史上全最的WAV格式详解
• wav文件格式分析与详解

先附上结论：**GCC在不优化时不会内联任何函数，除非指定函数的“always_inline”属性。**
​

测试代码：

1
2
3
4
5
6
7
8
9
10

#include <stdio.h>

inline void say(void) {
    printf("Hello, World\n");
}

int main(void) {
    say();
    return 0;
}

使用-O3优化选项，一切正常：

1
2
3
4

$ gcc -O3 -o test_O3.o -c test.c
$ g++ test_O3.o -o test_O3
$ ./test_O3
Hello, World

使用-O0优化选项，链接时报错，提示找不到内联函数say：

1
2
3
4
5

$ gcc -O0 -o test_O0.o -c test.c
$ g++ test_O0.o -o test_O0
test_O0.o: In function `main':
test.c:(.text+0x5): undefined reference to `say'
collect2: error: ld returned 1 exit status

分别查看文件test_O0.o和test_O3.o：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

$ readelf -s test_O0.o

Symbol table '.symtab' contains 10 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS test.c
     2: 0000000000000000     0 SECTION LOCAL  DEFAULT    1 
     3: 0000000000000000     0 SECTION LOCAL  DEFAULT    3 
     4: 0000000000000000     0 SECTION LOCAL  DEFAULT    4 
     5: 0000000000000000     0 SECTION LOCAL  DEFAULT    6 
     6: 0000000000000000     0 SECTION LOCAL  DEFAULT    7 
     7: 0000000000000000     0 SECTION LOCAL  DEFAULT    5 
     8: 0000000000000000    16 FUNC    GLOBAL DEFAULT    1 main
     9: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND say

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

$ readelf -s test_O3.o

Symbol table '.symtab' contains 13 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS test.c
     2: 0000000000000000     0 SECTION LOCAL  DEFAULT    1 
     3: 0000000000000000     0 SECTION LOCAL  DEFAULT    2 
     4: 0000000000000000     0 SECTION LOCAL  DEFAULT    3 
     5: 0000000000000000     0 SECTION LOCAL  DEFAULT    4 
     6: 0000000000000000     0 SECTION LOCAL  DEFAULT    5 
     7: 0000000000000000     0 SECTION LOCAL  DEFAULT    6 
     8: 0000000000000000     0 SECTION LOCAL  DEFAULT    9 
     9: 0000000000000000     0 SECTION LOCAL  DEFAULT   10 
    10: 0000000000000000     0 SECTION LOCAL  DEFAULT    8 
    11: 0000000000000000    21 FUNC    GLOBAL DEFAULT    6 main
    12: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND puts

可以发现文件test_O0.o中，inline修饰的函数say为未定义状态，说明inline函数并没有展开。
​

指定say函数为“always_inline”属性：

1
2
3
4
5
6
7
8
9
10

#include <stdio.h>

__attribute__((always_inline)) inline void say(void) {
    printf("Hello, World\n");
}

int main(void) {
    say();
    return 0;
}

重新使用-O0优化选项编译运行，一切ok：

1
2
3
4
5

$ gcc -O0 -o test.o -c test.c
$ gcc -O0 -o test_O0_2.o -c test.c
$ g++ test_O0_2.o -o test_O0_2
$ ./test_O0_2
Hello, World

简介

getrusage用于统计系统资源使用情况，即进程执行直到调用该函数时的资源使用情况，如果在不同的时间调用该函数，会得到不同的结果。

目前在Linux和macOS支持该函数。

函数说明

原型

1
2
3
4

#include <sys/time.h>
#include <sys/resource.h>

int getrusage(int who, struct rusage *usage);

sys/time.h：为了得到timeval结构体的声明，这个结构体实际上在bits/time.h中声明。

参数

**who**：资源统计的对象，有如下取值：

• RUSAGE_SELF：返回调用进程的资源使用统计信息，即该进程中所有线程使用的资源总和；
• RUSAGE_CHILDREN：返回调用进程所有已终止且被回收子进程的资源使用统计信息。如果进程有孙子进程或更远的后代进程，且这些后代进程和这些后代进程与调用进程之间的中间进程也已终止且被回收，那么这些后代进程的资源使用统计信息也会被统计；
• RUSAGE_THREAD（Linux 2.6.26起支持）：返回调用线程的资源使用统计信息；

宏定义在sys/resource.h-> bits/resource.h。

**usage**：资源使用统计信息，用如下结构体的形式返回到该指针指向的内存空间：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

struct rusage {
    struct timeval ru_utime; /* user CPU time used */
    struct timeval ru_stime; /* system CPU time used */
    long   ru_maxrss;        /* maximum resident set size */
    long   ru_ixrss;         /* integral shared memory size */
    long   ru_idrss;         /* integral unshared data size */
    long   ru_isrss;         /* integral unshared stack size */
    long   ru_minflt;        /* page reclaims (soft page faults) */
    long   ru_majflt;        /* page faults (hard page faults) */
    long   ru_nswap;         /* swaps */
    long   ru_inblock;       /* block input operations */
    long   ru_oublock;       /* block output operations */
    long   ru_msgsnd;        /* IPC messages sent */
    long   ru_msgrcv;        /* IPC messages received */
    long   ru_nsignals;      /* signals received */
    long   ru_nvcsw;         /* voluntary context switches */
    long   ru_nivcsw;        /* involuntary context switches */
};

结构体struct rusage各个成员释义如下：

• ru_utime：返回进程在用户模式下的执行时间，以timeval结构的形式返回（该结构体在bits/timeval中声明）；
• ru_stime：返回进程在内核模式下的执行时间，以timeval结构的形式返回（该结构体在bits/timeval中声明）；
• ru_maxrss（Linux 2.6.32起支持）：返回rss（实际使用物理内存，包含共享库占用的内存）的大小，单位为KB；当who被指定为RUSAGE_CHILDREN时，返回各子进程rss的大小中最大的一个，而不是进程树中最大的rss；
• ru_ixrss：目前不支持；
• ru_idrss：目前不支持；
• ru_isrss：目前不支持；
• ru_minflt：缺页中断的次数，且处理这些中断不需要进行I/O，不需要进行I/O操作的原因是系统使用reclaiming的方式在物理内存中得到了之前被淘汰但是未被修改的页框。（第一次访问bss段时也会产生这种类型的缺页中断）；
• ru_majflt：缺页中断的次数，且处理这些中断需要进行I/O；
• ru_nswap：目前不支持；
• ru_inblock（Linux 2.6.22起支持）：文件系统需要进行输入操作的次数；
• ru_oublock（Linux 2.6.22起支持）：文件系统需要进行输出操作的次数；
• ru_msgsnd：目前不支持；
• ru_msgrcv：目前不支持；
• ru_nsignals：目前不支持；
• ru_nvcsw（Linux 2.6起支持）：因进程自愿放弃处理器时间片而导致的上下文切换的次数（通常是为了等待请求的资源）；
• ru_nivcsw（Linux 2.6起支持）：因进程时间片使用完毕或被高优先级进程抢断导致的上下文切换的次数；

  其中有些结构体成员目前并不被Linxu支持，但是为了兼容其它系统以及未来扩展，仍被保留了下来，这些结构体成员在函数执行后会被内核默认设置为0。

返回值

成功：0；
失败：-1，并设置errno的值，包含如下两种错误：

• EFAULT：usage指针指向不可访问地址；
• EINVAL：who被指定为无效值；

属性

getrusage函数是线程安全的。
​

示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

#include <stdio.h>

/* include for getrusage */
#ifndef _WIN32
#include <sys/time.h>
#include <sys/resource.h>
#endif

static void print_rusage() {
#ifndef _WIN32
int ret;

struct rusage usage;
    ret = getrusage(RUSAGE_SELF, &usage);
if (0 != ret) {
printf("getrusage failed\n");
goto end;
}

printf("%s: %.3fms\n", "ru_utime", (usage.ru_utime.tv_sec * 1000.0 + usage.ru_utime.tv_usec / 1000.0));
printf("%s: %.3fms\n", "ru_stime", (usage.ru_stime.tv_sec * 1000.0 + usage.ru_stime.tv_usec / 1000.0));
printf("%s: %.3fM\n", "ru_maxrss", (usage.ru_maxrss / 1024.0));
printf("%s: %ld\n", "ru_ixrss", usage.ru_ixrss);
printf("%s: %ld\n", "ru_idrss", usage.ru_idrss);
printf("%s: %ld\n", "ru_isrss", usage.ru_isrss);
printf("%s: %ld\n", "ru_minflt", usage.ru_minflt);
printf("%s: %ld\n", "ru_majflt", usage.ru_majflt);
printf("%s: %ld\n", "ru_nswap", usage.ru_nswap);
printf("%s: %ld\n", "ru_inblock", usage.ru_inblock);
printf("%s: %ld\n", "ru_oublock", usage.ru_oublock);
printf("%s: %ld\n", "ru_msgsnd", usage.ru_msgsnd);
printf("%s: %ld\n", "ru_msgrcv", usage.ru_msgrcv);
printf("%s: %ld\n", "ru_nsignals", usage.ru_nsignals);
printf("%s: %ld\n", "ru_nvcsw", usage.ru_nvcsw);
printf("%s: %ld\n", "ru_nivcsw", usage.ru_nivcsw);

#endif

end:
return;
}

完整代码：https://github.com/AnSwErYWJ/DogFood/blob/master/C/getrusage.c。

RPATH与RUNPATH的区别

年前升级了操作系统后，同样的代码在新系统编译后无法执行，提示找不到依赖库，本文用来记录一下是如何解决这个问题的。

源文件

main.c ：

1
2
3
4
5
6

#include "a.h"

int main() {
a();
return 0;
}

libA.so：

1
2
3
4
5
6

// a.c
#include "b.h"

void a() {
b();
}

1
2

// a.h
void a();

ubuntu 16.04(gcc version 5.4.0)：

1

$ gcc -fPIC -shared a.c -I. -L. -lB -o libA.so

libB.so：

1
2
3
4
5
6

// b.c
#include <stdio.h>

void b() {
printf("Hello, World\n");
}

1
2

// b.h
void b();

ubuntu 16.04(gcc version 5.4.0)：

1

$ gcc -fPIC -shared -I. b.c -o libB.so

**函数调用依赖关系：main -> a -> b**。

复现步骤

1. 分别在 ubuntu 16.04(gcc version 5.4.0) 和 ubuntu 20.04(gcc version 9.3.0) 编译可执行程序：

   1	$ gcc -I. -o main main.c -Wl,--rpath,. -L. -lA -lB

2. 在 ubuntu 16.04(gcc version 5.4.0) 运行成功：

   1 2	$ ./main Hello, World

3. 在 ubuntu 20.04(gcc version 9.3.0) 运行失败：

   1 2	$ ./main ./main: error while loading shared libraries: libB.so: cannot open shared object file: No such file or directory

   错误提示为找不到可执行程序 ./main 依赖的共享库 libB.so 。

问题原因

排除共享库本身问题

首先，由于 libA.so 和 libB.so 是在 ubuntu 16.04(gcc version 5.4.0) 上编译的，所以重新在ubuntu 20.04(gcc version 9.3.0) 上编译 libA.so 和 libB.so，并重复复现步骤，现象相同，说明不是 libA.so 和 libB.so 导致的问题；

分析库查找过程

使用 **LD_DEBUG**，打开链接器的调试功能，分析共享库的查找过程：
ubuntu 16.04(gcc version 5.4.0)：

1
2
3
4
5
6
7
8
9
10
11

$ LD_DEBUG=libs ./main                                                        [16:37:15]
     22331:find library=libA.so [0]; searching
     22331: search path=./tls/x86_64:./tls:./x86_64:.(RPATH from file ./main)
......
     22331:  trying file=./libA.so
......
     22331:find library=libB.so [0]; searching
     22331: search path=./tls/x86_64:./tls:./x86_64:.(RPATH from file ./main)
......
     22331:  trying file=./libB.so
 ......

ubuntu 20.04(gcc version 9.3.0)：

1
2
3
4
5
6
7
8
9
10
11
12

$ LD_DEBUG=libs ./main
     33218:find library=libA.so [0]; searching
     33218: search path=./tls/haswell/x86_64:./tls/haswell:./tls/x86_64:./tls:./haswell/x86_64:./haswell:./x86_64:.(RUNPATH from file ./main)
......
     33218:  trying file=./libA.so
......
     33218:find library=libB.so [0]; searching
     33218: search cache=/etc/ld.so.cache
     33218: search path=/lib/x86_64-linux-gnu/tls/haswell/x86_64:/lib/x86_64-linux-gnu/tls/haswell:/lib/x86_64-linux-gnu/tls/x86_64:/lib/x86_64-linux-gnu/tls:/lib/x86_64-linux-gnu/haswell/x86_64:/lib/x86_64-linux-gnu/haswell:/lib/x86_64-linux-gnu/x86_64:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/tls/haswell/x86_64:/usr/lib/x86_64-linux-gnu/tls/haswell:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls:/usr/lib/x86_64-linux-gnu/haswell/x86_64:/usr/lib/x86_64-linux-gnu/haswell:/usr/lib/x86_64-linux-gnu/x86_64:/usr/lib/x86_64-linux-gnu:/lib/tls/haswell/x86_64:/lib/tls/haswell:/lib/tls/x86_64:/lib/tls:/lib/haswell/x86_64:/lib/haswell:/lib/x86_64:/lib:/usr/lib/tls/haswell/x86_64:/usr/lib/tls/haswell:/usr/lib/tls/x86_64:/usr/lib/tls:/usr/lib/haswell/x86_64:/usr/lib/haswell:/usr/lib/x86_64:/usr/lib(system search path)
......
./main: error while loading shared libraries: libB.so: cannot open shared object file: No such file or directory

结果在 ubuntu 20.04(gcc version 9.3.0) 中， 可以正确查找到 libA.so ，但是无法正确查找到 libB.so 。
libB.so 的查找路径是 system search path ，而非我们在编译时设定的查找时路径 ./ ，导致可执行程序无法加载 libB.so 。

动态链接器对共享库的查找顺序：

1. LD_LIBRARY_PATH、-L 和 -rpath；
2. /etc/ld.so.cache；
3. 默认共享库目录：/usr/lib、/lib；

RPATH与RUNPATH的区别

由上分析可以得出是共享库运行时加载路径非法导致的问题，在排除设置 LD_LIBRARY_PATH 等环境变量的情况下，可以将焦点锁定在使用的链接选项 -rpath 上，查看源文件依赖：
ubuntu 16.04(gcc version 5.4.0)：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

$ readelf -d main
Dynamic section at offset 0xe08 contains 26 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libA.so]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000f (RPATH)              Library rpath: [.]
 
 $ readelf -d libA.so
Dynamic section at offset 0xe08 contains 25 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libB.so]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 
 $ readelf -d libB.so
Dynamic section at offset 0xe18 contains 24 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

ubuntu 20.04(gcc version 9.3.0)：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

$ readelf -d main 
Dynamic section at offset 0x2da8 contains 29 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libA.so]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000001d (RUNPATH)            Library runpath: [.]
 
 $ readelf -d libA.so 
Dynamic section at offset 0xe08 contains 25 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libB.so]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 
 $ readelf -d libB.so 
Dynamic section at offset 0xe18 contains 24 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

发现在 ubuntu 20.04(gcc version 9.3.0) 上 RPATH 变成了 RUNPATH ，说明链接器选项 -rpath 的行为发生了改变。

源文件依赖关系：main -> libA.so -> libB.so；

综上，问题的原因是 ubuntu 20.04(gcc version 9.3.0) 上，链接器选项 -rpath 的行为发生改变，默认配置为 RUNPATH 而不是 RPATH；由于 RUNPATH 不适用于间接依赖的库，所以导致在 ubuntu 20.04(gcc version 9.3.0) 上只能正确查找到 libA.so ，而无法正确查找到 libB.so 。

gcc version >= 7.5.0时，-rpath默认行为即发生改变。

解决方案

LD_LIBRARY_PATH（不推荐）

LD_LIBRARY_PATH 是一个环境变量，作用是临时改变链接器的加载路径，可以存储多个路径，用冒号分隔：

1

$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:./libs

不推荐的原因：

1. 若全局设置 LD_LIBRARY_PATH，会影响其它应用程序的共享库加载过程；
2. 若只在该应用程序启动时局部设置 LD_LIBRARY_PATH，则每次启动都需要设置，步骤过于繁琐；

–disable-new-dtags

可以使用 -Wl,--disable-new-dtags 选项来使链接器保持旧行为，即在 ubuntu 20.04(gcc version 9.3.0) 使用如下命令编译：

1

$ gcc -I. -o main main.c -Wl,--disable-new-dtags,--rpath,. -L. -lA -lB

重新运行并查看依赖：

1
2
3
4
5
6
7
8
9

$ ./main 
Hello, World

$ readelf -d main
Dynamic section at offset 0x2da8 contains 29 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libA.so]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000f (RPATH)              Library rpath: [.]

可执行程序 main 可以正确运行，RUNPATH 也变成了 RPATH，链接器行为与 ubuntu 16.04(gcc version 5.4.0) 保持一致了。

同理，也有 -Wl,--enable-new-dtags 选项来使链接器保持新行为

如下为官方解释：

1
2
3

--enable-new-dtags
--disable-new-dtags
This linker can create the new dynamic tags in ELF. But the older ELF systems may not understand them. If you specify --enable-new-dtags, the new dynamic tags will be created as needed and older dynamic tags will be omitted. If you specify --disable-new-dtags, no new dynamic tags will be created. By default, the new dynamic tags are not created. Note that those options are only available for ELF systems.

参考

• How to set RPATH and RUNPATH with GCC/LD?
• use RPATH but not RUNPATH?

下载与安装

Git下载地址：https://git-scm.com/downloads，安装请参考页面说明。

建议使用版本v1.8及以上。

配置

Git配置分为三个级别：

• --system：系统级，位于 /etc/gitconfig；
• --global：用户级，位于 ~/.gitconfig；
• --local：仓库级，位于 [repo]/.git/config，为默认级别且优先级最高；

用户信息

删除global用户信息，防止不同Git服务之间冲突：

1
2

$ git config --global --unset user.name
$ git config --global --unset user.email

配置用户名：

1
2

$ git config --local user.name "username"
$ git config --local user.email "email"

克隆协议

一般Git服务默认都支持SSH和HTTPS，SSH支持的原生Git协议速度最快，HTTPS除了速度慢以外，还有个最大的麻烦是每次推送都必须输入口令。

SSH

检查本机SSH公钥，若存在，则将id_rsa.pub添加到Git服务的SSH keys：

1

$ ls ~/.ssh

若不存在，则生成：

• 单个Git服务

  1	$ ssh-keygen -t rsa -C "your_email@youremail.com"

• 多个Git服务

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

  $ ssh-keygen -t rsa -C "your_email@youremail.com" -f "git1_id_rsa" $ ssh-keygen -t rsa -C "your_email@youremail.com" -f "git2_id_rsa" $ cp git1_id_rsa* ~/.ssh/ $ cp git2_id_rsa* ~/.ssh/ # 创建配置文件 $ vi ~/.ssh/config # git1 Host git1.com HostName git1.com PreferredAuthentications publickey IdentityFile ~/.ssh/git1_id_rsa # git2 Host git2.com HostName git2.com PreferredAuthentications publickey IdentityFile ~/.ssh/git2_id_rsa

配置完成后，将对应的id_rsa.pub添加到Git服务的SSH keys，再次检查ssh连接情况；若不生效，则重启后再尝试：

1
2

$ ssh -T git@github.com
Hi! You’ve successfully authenticated, but GitHub does not provide shell access.

若出现上述信息，则表示设置成功。

克隆：

1

$ git clone git@git.server:test.git

HTTPS

关闭ssl校验：

1

$ git config --global http.sslverify false

克隆：

1

$ git clone https://git.server/test.git

协议切换

查看当前协议：

1

$ git remote -v

从https切换至ssh：

1

git remote set-url origin git@domain:username/ProjectName.git

从ssh切换至https：

1

git remote set-url origin https://domain/username/ProjectName.git

自定义配置

超时时间

1

$ git config --global credential.helper 'cache --timeout=3600'

保存用户凭证

1

$ git config --global credential.helper store

执行后，下次操作输入的用户名和密码会被保存，后续不必手动输入用户名和密码。若同时使用不同的Git服务，则不推荐使用。

多Git服务

若同时使用不同的Git服务，可以根据目录配置用户信息（需要使用v2.13.0及以上版本）：

• 首先修改用户目录下的 .gitconfig，通过 includeIf 配置不同目录的配置文件：

  1 2 3 4 5 6 7 8

  - [user] - name = weijie.yuan - email = weijie.yuan@gitlab.com + [includeIf "gitdir:~/github/"] + path = .gitconfig-github + [includeIf "gitdir:~/gitlab/"] + path = .gitconfig-gitlab

• 根据配置的 path，分别创建 .gitconfig-github 文件和 .gitconfig-gitlab 文件：

  1 2 3 4 5 6 7 8 9

  $ vi .gitconfig-github [user] name = weijie.yuan email = weijie.yuan@github.com $ vi .gitconfig-gitlab [user] name = weijie.yuan email = weijie.yuan@gitlab.com

  includeIf 配置有如下规则：

• 家目录下的 .gitconfig ，includeIf 后面的 path 最后需要 / 结尾；

• 家目录下的 .gitconfig ，原有的 user 部分需要删除；

• 家目录下的 .gitconfig ，includeIf中配置的各个目录，不能是包含关系；

文本编辑器

Linux or MacOS：

1

$ git config --global core.editor vim

Windows：

1

> git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"

文本比较合并工具

查看支持的工具集合（推荐使用meld）：

1

$ git difftool --tool-help

Linux or MacOS：

1
2

$ git config --global diff.tool meld
$ git config --global merge.tool meld

Windows：

1
2
3
4
5

> git config --global diff.tool meld
> git config --global merge.tool meld
> git config --global difftool.bc3.path 'C:\Program Files (x86)\Meld\Meld.exe'
> git config --global mergetool.meld.path 'C:\Program Files (x86)\Meld\Meld.exe'
> git config --global difftool.meld.path 'C:\Program Files (x86)\Meld\Meld.exe'

显示颜色

1

$ git config --global color.ui.true

操作别名

示例，将checkout设置为别名co：

1

$ git config --global alias checkout co 

查看所有配置

1
2
3

$ git config --local --list
$ git config --global --list
$ git config --system --list

基础操作

工作流

工作区就是你的本地仓库目录，不过其中的.git目录不属于工作区，而是版本库，里面存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。

查看状态：

1

$ git status

添加修改到暂存区：

1
2
3

$ git add <filename> 
$ git add .  # 添加当前目录所有修改过的文件  
$ git add *  # 递归地添加执行命令时所在的目录中的所有文件

提交修改到版本库：

1
2

$ git commit -m "commit message"
$ git commit -am "commit message" # am：将添加和提交合并为一步，但只对本来就存在的文件有效

commit message的填写可以参考写好 Git Commit 信息的 7 个建议。

现在来解释一下前面的添加和提交操作：

1. git add：把文件修改添加到暂存区；
2. git commit：把暂存区的所有内容提交到当前分支，即版本库；

版本历史记录

查看当前仓库所有文件的版本历史记录：

1

$ git log

查看每个文件的版本历史记录：

1

$ git log <filename>

查看包含指定关键字的版本历史记录：

1

$ git log --grep="keywords"

查看指定时间段的版本历史记录，如下示例时间段为2020.9.23全天：

1

$ git log --after="2020-9-23 00:00:00" --before="2020-9-23 23:59:59"

暂存

当你需要切换分支时，若当前工作区还有些修改没有完成、又不适合提交的，操作切换分支是会提示出错的，这时就需要将这些修改暂存起来：

1

$ git stash save "message"

查看:

1

$ git stash list

恢复:

1
2
3

$ git stash pop [--index] [stash@{num}]　
  or
$ git stash apply [--index] [stash@{num}]　# 不删除已恢复的进度.

--index表示不仅恢复工作区,还会恢复暂存区；num是你要恢复的操作的序列号,默认恢复最新进度。

删除进度:

1
2

$ git stash drop [stash@{num}] # 删除指定进度
$ git stash clear # 删除所有

撤销与回退

查看当前仓库状态：

1

$ git status

查看文件更改：

1
2

$ git difftool <filename>
$ git mergetool <filename>

查看提交历史：

1
2

$ git log
$ git log --pretty=oneline #只保留commit id 和 commit message

撤销工作区Tracked files的修改：

1

$ git checkout -- <filename>

撤销工作区Untracked files的修改：

• n：查看将会删除的文件，防止误删；
• f：Untracked的文件；
• d：Untracked的目录；
• x：包含gitignore的Untracked文件和目录一并删掉，慎用！；

1

git clean -nfd

只回退暂存区(git add)，不删除工作空间代码：

1

$ git reset HEAD <filename> # 无filename则默认回退全部 

回退版本区(git commit)和暂存区(git add)，不删除工作空间代码：

1
2

$ git reset --mixed HEAD^ # --mixed为默认参数
$ git reset HEAD^

回退版本区(git commit)，但是不回退暂存区(git add)，不删除工作空间代码：

1

$ git reset --soft HEAD^

回退版本区(git commit)和暂存区(git add)，并删除工作空间代码(不包括Untracked files)，执行后直接恢复到指定<commit-id>状态：

1

$ git reset --hard <commit-id>

HEAD表示当前版本，HEAD^表示上个版本，HEAD^^表示上上个版本，上100个版本可以表示为HEAD~100以此类推。

回退版本后，若需要返回原来的版本，会发现找不到未来的commit id，则需要查看操作命令历史进行查找：

1

$ git reflog

从版本库删除文件：

1

$ git rm <filename>

若你的代码已经push到线上，则推荐使用下面这个命令回滚：

1

$ git revert <commit-id>

revert是用一次新的commit来回滚之前的commit，更安全;reset则是直接删除指定的commit，若直接push会导致冲突。

使用帮助

查看帮助：

1

$ git --help

仓库管理

推送本地修改到远程仓库

1

$ git push -u origin <feature-branch-name>

-u选项可以将本地分支与远程分支关联,下次git pull操作时可以不带参数.具体参见这里。

添加本地仓库到远程

1
2
3

$ cd repo
$ git init
$ git remote add origin git@github.com:USERNAME/repo.git

origin就是一个名字，是git为你默认创建的指向这个远程代码库的标签。

获取远程仓库

1

$ git clone git@github.com:USERNAME/repo.git

查看远程仓库

1
2
3

$ git remote -v
origin git@github.com:USERNAME/repo.git (push)
origin git@github.com:USERNAME/repo.git (fetch)

关联远程仓库

1

$ git remote add upstream git@github.com:USERNAME/repo.git

同步远程仓库的更新

1
2
3
4
5
6
7
8
9
10

$ git remote -v
origin  git@github.com:USERNAME/repo.git (push)
origin  git@github.com:USERNAME/repo.git (fetch)
upstream  git@github.com:USERNAME/repo.git  (push)
upstream  git@github.com:USERNAME/repo.git (fetch)

$ git fetch upstream 
$ git difftool <branch-name> upstream/master
$ git merge upstream/master
$ git mergetool

仓库引用（子仓库）

Git包含submodule和subtree两种引用方式，官方推荐使用subtree替代submodule：

submodule

添加子模块

1

$ git submodule add git@github.com:USERNAME/repo.git <submodule-path>

执行成功后，暂存区会有两个修改：.gitmodules和命令中<submodule-path>指定的路径。

提交更新：

1
2

$ git commit
$ git push

使用子模块

克隆使用了子模块的项目后，默认其子模块目录为空，需要在项目根目录执行如下命令单独下载：

1
2
3
4
5
6

$ git submodule update --init --recursive

or

$ git submodule init
$ git submodule update

更新子模块

子模块仓库更新后，使用子模块的项目必须手动更新才能同步最新的提交：

1
2

$ cd <submodule-path>
$ git pull

完成后返回项目根目录，可以看到子模块有待提交的更新，执行提交即可：

1
2
3

$ git add .
$ git commit
$ git push

删除子模块

删除子模块目录及源码：

1

$  rm -rf <submodule-path>

删除项目根目录下.gitmodules文件中待删除的子模块相关条目：

1

$ vi .gitmodules 

删除版本库下的子模块目录，每个子模块对应一个目录，只删除对应的子模块目录即可：

1

rm -rf .git/module/<submodule-path>

删除子模块缓存：

1

git rm --cached <submodule-path>

提交更新：

1
2
3

$ git add .
$ git commit
$ git push

subtree

1
2
3
4
5
6
7
8
9

# 第一次初始化
$ git remote add -f <remote-subtree-repository-name> <remote-subtree-repository-url>
$ git subtree add --prefix=<local-subtree-directory> <remote-subtree-repository> <remote-subtree-branch-name> --squash

# 同步subtree的更新
$ git subtree pull --prefix=<local-subtree-directory> <remote-subtree-repository> <remote-subtree-branch-name> --squash

# 推送到远程subtree库
$ git subtree push --prefix=<local-subtree-directory> <remote-subtree-repository> <remote-subtree-branch-name>

清理仓库

清理本地无效的远程追踪分支

1
2
3

$ git pull # 拉取更新
$ git remote prune origin --dry-run # 列出所有可以从本地仓库中删除的远程追踪分支
$ git remote prune origin # 清理本地无效的远程追踪分支

清理无用的分支和标签

1
2

$ git branch -d <branch-name>
$ git tag -d <tag-name>

清理大文件

• 查看仓库占用空间：

  1 2	$ git count-objects -v $ du -sh .git

• 寻找大文件ID：

  1	$ git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -10

  输出的第一列是文件ID，第二列表示文件（blob）或目录（tree），第三列是文件大小，此处筛选了最大的10条。

• 根据文件ID映射文件名：

  1	$ git rev-list --objects --all | grep "$(git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -10 | awk '{print$1}')"

• 根据文件名，从所有提交中删除文件：

  1	$ git filter-branch --force --index-filter 'git rm -rf --cached --ignore-unmatch [FileName]' --prune-empty --tag-name-filter cat -- --all

• 删除缓存下来的ref和git操作记录：

  1 2	$ git for-each-ref --format='delete %(refname)' refs/original | git update-ref --stdin $ git reflog expire --expire=now --all

• 清理.git目录并推送到远程：

  1 2	$ git gc --prune=now $ git push -f --all

  在执行push操作时，git会自动执行一次gc操作，不过只有loose object达到一定数量后才会真正调用，建议手动执行。

• 重新查看仓库占用空间，发现较清理前变小很多：

  1 2	$ git count-objects -v $ du -sh .git

清理大型二进制文件

由于Git在存储二进制文件时效率不高，所以需要借助第三方组件。

分支管理

查看分支

查看所有分支：

1

$ git branch -a

有*标记的是当前分支。

查看某个<commit id>属于哪个分支:

1

$ git branch -a --contains <commit id>

创建分支

在本地创建分支：

1

$ git branch <newbranch> # 创建

在本地创建分支并切换：

1

$ git checkout -b <newbranch> # 创建并切换

从标签创建分支：

1
2

$ git branch <newbranch> <tagname>
$ git checkout <newbranch> # 切换到新建分支

获取远程分支到本地并创建本地分支：

1

$ git checkout -b <local-branch> <remote-branch>

推送新建本地分支到远程：

1
2
3

$ git push -u origin <remote-branch-name>
  or
$ git push --set-upstream origin <remote-branch-name>

创建空白分支

创建一个分支，该分支会包含父分支的所有文件，但不会指向任何历史提交：

1

$ git checkout --orphan <newbranch>

删除所有文件：

1

$ git rm -rf .

提交分支：

1
2
3
4

$ echo '# new branch' >> README.md
$ git add README.md
$ git commit
$ git push origin <remote-branch-name>

删除分支

删除本地分支：

1

$ git branch -d <branch>

若当前分支因为有修改未提交或其它情况不能删除，请使用-D选项强制删除。

清理无用的本地分支：

1

$ git remote prune origin

通常在remote上的分支被删除后，更新本地分支列表时使用。

删除远程分支(三种方法)：

1
2
3

$ git push origin --delete <remote-branch-name>
$ git push origin -d <remote-branch-name>
$ git push origin :<remote-branch-name>

更新分支

获取远程分支到本地已有分支：

1

$ git branch --set-upstream <local-branch> origin/branch

同步当前分支的所有更新，使用git pull并不保险：

1
2
3
4
5
6
7
8

# 下载最新的代码到远程跟踪分支, 即origin/<branch-name>
$ git fetch origin <branch-name> 
# 查看更新内容
$ git difftool <branch-name> origin/<branch-name>
# 尝试合并远程跟踪分支的代码到本地分支 
$ git merge origin/<branch-name>
# 借助mergetool解决冲突              
$ git mergetool                               

同步其它分支的所有更新，本例拉取master分支更新：

1
2
3
4

$ git fetch origin master
$ git difftool <branch-name> origin/master
$ git merge origin/master
$ git mergetool

同步其它分支的部分更新，即同步某几次提交：

1
2
3
4
5
6
7
8

# 同步提交A
$ git cherry-pick <commit id A> 
# 同步提交A和B
$ git cherry-pick <commit id A> <commit id B> 
# 同步提交A到B的所有提交（不包括A），提交A必须早于提交B，否则命令将失败，但不会报错
$ git cherry-pick <commit id A>..<commit id B> 
# 同步提交A到B的所有提交（包括A），提交A必须早于提交B，否则命令将失败，但不会报错
$ git cherry-pick <commit id A>^..<commit id B> 

标签管理

查看标签

1

$ git tag

创建标签

1
2

$ git tag -a <tagname> -m "tag message" # 创建标签在当前最新提交的commit上
$ git tag -a <tagname> -m "tag message" <commit id> # 创建标签在指定的commit上

若创建标签基于的commit被删除，标签不会被影响，依旧存在。

推送标签

推送标签到远程服务器：

1
2

$ git push origin <tagname> # 推送一个本地标签
$ git push origin --tags # 推送全部未推送过的本地标签

删除标签

1
2

$ git tag -d <tagname> # 删除一个本地标签
$ git push origin :refs/tags/<tagname> # 删除一个远程标签

进阶技巧

忽略特殊文件

当你的仓库中有一些文件，类似密码或者数据库文件不需要提交但又必须放在仓库目录下，每次git status都会提示Untracked，看着让人很不爽，提供两种方法解决这个问题。

本地忽略

在代码仓库目录创建一个.gitignore文件，编写规则如下：

1
2
3

tmp/  # 忽略tmp文件夹下所有内容
*.ini # 忽略所有ini文件
!data/ #忽略除了data文件夹的所有内容

.gitignore模版

全局忽略

在用户目录创建一个.gitignore_global文件，编写规则同.gitignore，并修改~/.gitconfig：

1
2

[core]
excludesfile = ~/.gitignore_global

如果添加的忽略对象已经Tracked，纳入了版本管理中，则需要在代码仓库中先把本地缓存删除,改变成Untracked状态:

1

$ git rm -r --cached .

重写历史（慎用！）

修改历史提交（变基）

1
2

$ git rebase -i [git-hash| head~n]
$ git push -f # 不强制 push 会多一条 merge 提交信息

其中git-hash是你要开始进行rebase的commit的hash，而head~n则是从HEAD向前推n个commit

修改最近一次提交信息

1

$ git commit --amend

修改提交记录中的用户信息

修改最近一次提交的用户信息：

1

$ git commit --amend --author="GIT_AUTHOR_NAME <GIT_AUTHOR_EMAIL>"

全局修改用户信息：

1
2
3
4
5
6
7
8
9

$ git filter-branch --commit-filter '
        if [ "$GIT_AUTHOR_EMAIL" = "xxx@localhost" ];
        then
                GIT_AUTHOR_NAME="xxx";
                GIT_AUTHOR_EMAIL="xxx@example.com";
                git commit-tree "$@";
        else
                git commit-tree "$@";
        fi' HEAD --all

Reference

• 廖雪峰老师的git教程
• 常用Git命令清单
• Git-Book
• Git-Reference
• Git push与pull的默认行为
• Git飞行规则(Flight Rules)
• 理解Git Submodules
• git中submodule子模块的添加、使用和删除
• 寻找并删除 Git 记录中的大文件

这里提供了一份简历模版，可供参考。

保证内容真实性

写简历必须要保证内容的真实性，这是候选人个人诚信的体现，无论在简历中如何自夸，最终会在面试过程中也会露怯；同时现在大部分企业在招聘时，都会进行背调，所以请务必保证简历内容包括面试过程的真实性，实事求是，“知之为知之，不知为不知”。

项目描述不是流水账

对于技术人员来说，项目经历是简历的主体，也是简历中最需要突出的部分，项目中涉及的技能和成果等，是对求职者能力最具说服力的证明。

据说，谷歌要求求职者描述项目经历时，必须提供下面三个信息：

• 做了什么产品
• 用到了什么技术
• 取得了什么结果（量化）

这里我认为还可以增加一个信息，即在项目中的角色：

• 独立完成开发
• 协作开发，为主导开发，或辅助开发
• 团队领导者，团队规模为多少人

比如，”在 xx 产品中，主导开发了 xx 功能，使用了 xx 技术，解决了 xx 问题，带来了 xx 增长或收入”。

特别需要注意的是，取得的结果一定要量化，如功能被多少人使用、性能提升多少倍、节约了多少成本、带来了多少收益等等

除此之外，还请注意下面几点：

• 挑选近 3~5 年内的项目，除非特别有价值，否则不要描述过于旧的项目；
• 将项目分类，每类挑选 2~3 个核心的项目详细描述，其余可一笔带过；
• 量化项目结果时，注重实际收益，如用户增长、经济收益等；

筛选专业技能

我遇到过很多刚毕业或毕业不久的求职者，简历中的专业技能十分齐全，但是面试过程中却发现大多的技能，仅仅是接触过或者在学校学过，这会给人感觉“你什么都会一点，但是什么都不精通”，这样做的伤害大于帮助。

所以，请筛选你的专业技能，建议可以按照熟练程度进行分类：

• 了解：有使用过该技能做过一点东西，清楚其使用场景、能够解决的问题；若面试官提及，能够接上话；
• 熟悉：经常性使用该技能、以该技能为主进行研发，对其原理有初步了解；若面试官提及，能够有来有回的聊起来；
• 精通（慎用）：熟练使用该技能，对其原理理解透彻；若面试官提及，能够直接碾压他！

最后，与专业无关的技能切勿出现在简历中，那这些内容对企业没用，缺乏针对性，只会浪费简历空间，如在校上过的课程、得过的奖学金、当过学生会干部，会计证、驾驶证、英语四六级考试等。

具有岗位相关性

企业招聘的目的，是希望找到能够帮助它干活或解决问题的人，仅仅通过一份简历，它也没有把握什么样的人匹配这个岗位，所以它只能假设如果你掌握了这个岗位所需要的某几种核心专业技能，你就是初步合格的候选人。

所以简历应该针对每个应聘的岗位，突出该岗位所需要的项目经历和专业技能，来证明你可以胜任这份工作。

页数不超过三页

简历是求职者用来向企业传递信息的，一般来说企业招聘人员在筛选简历时，阅读简历的时间不会超过半分钟，如果看不到想要的点，就会直接 pass；所以一定要突出重点内容，不要写得密密麻麻，堆砌各种无关的信息，这样只会增加简历的阅读难度，让招聘人员抓不到重点，对于技术人员来说，重点就是你的项目经历以及专业技能。

避免错别字和语法错误

简历中应该避免出现错别字、语法错误等低级错误，这很有可能会给企业留下不严谨、做事马虎的印象；同时技术名词大小写也应该遵循业内规范，保持专业性。

如果对自己不放心，可以在发送简历之前，请朋友检查一遍简历。

自我评价

一般简历中，都会要求候选人进行自我评价，请注意不要描述自己的工作态度，如积极进取、工作努力等，这是默认应该做到的，不是加分项。
自我评价可以针对如下四点进行：

• 学习能力
• 沟通能力
• 协作能力
• 执行能力

优化细节

优化企业招聘人员在阅读简历时的体验，使你的简历比别人读起来更舒服，自然简历通过的机会也会更高，可以关注以下细节：

• 在各类联系方式后面，注明最优联系时间，以免错过面试邀约；
• 若手机为外地号码，最好注明；
• 简历使用 markdown 编写，转换成 pdf 格式发出，可以避免样式丢失或格式不兼容；

写在最后

重中之重，还是需要提高自己的能力，正所谓 “酒香不怕巷子深“。

Reference

• 8 Hacks For Your Next Tech Resume
• 如何写一份有效的技术简历？

问题

1

dlopen failed: empty/missing DT_HASH in "libxxx.so" (built with --hash-style=gnu?)

最近，稳定性监控平台，被这一行错误日志霸榜，刚看到时也一脸懵逼，下面我们来逐步分析。

名词解释

首先需要查阅一下相关文档，了解一下其中的”新朋友”。

• DT_HASH

  1	ELF 中的一个 Sections，保存了一个用于查找符号的散列表，用于支持符号表的访问，能够提高符号搜索速度。

• --hash-style=style(以下解释摘自 man ld)

  1	Set the type of linker's hash table(s). style can be either "sysv" for classic ELF ".hash" section, "gnu" for new style GNU ".gnu.hash" section or "both" for both the classic ELF ".hash" and new style GNU ".gnu.hash" hash tables. The default is "sysv".

实验

通过查阅 --hash-style=style 参数，发现 style 支持三种配置：sysv、gnu和both，废话不多说，先试一把。

• gcc -Wl,--hash-style=sysv

  1 2	$ readelf -S libxxx.so | grep "hash" [ 4] .hash HASH 0000000000003120 00003120

• gcc -Wl,--hash-style=gnu

  1 2	$ readelf -S libxxx.so | grep "hash" [ 4] .gnu.hash GNU_HASH 0000000000003120 00003120

• gcc -Wl,--hash-style=both

  1 2 3

  $ readelf -S libxxx.so | grep "hash" [ 4] .gnu.hash GNU_HASH 0000000000003120 00003120 [ 5] .hash HASH 00000000000035f8 000035f8

-Wl 用于编译器向链接器传递参数。

如上，发现使用不同的配置，Sections Name 不同。

.gnu.hash 段​，提​供了​与 hash 段​相​同​的​功​能​；但​是与 hash 相比，增加了某些限制（附加规则），​导致了不兼容，带​来​了​ 50% 的​动​态​链​接​性​能​提​升​，具体参见 https://blogs.oracle.com/solaris/gnu-hash-elf-sections-v2。

分析

结合实验结果，我先翻译一下问题中的那一行错误日志：

1

动态库加载失败，libxxx.so 中 DT_HASH 为空或者丢失，是不是用了 --hash-style=gnu 编译?

结合上表，若 --hash-style=gnu，那么 Section Name 就是 .gnu.hash 了，当然找不到.hash 了。

再查阅一下 Makefile 配置，发现并没有相关配置，怀疑是编译器的默认配置：

1
2

$ gcc -dumpspecs | grep "hash"
... --hash-style=gnu ...

-dumpspecs 参数可以打印编译器的内置规范。

果不其然，默认的 --hash-style 配置为了 gnu。

结论

输出的动态库的 --hash-style 为 gnu，而目标系统并不能正确读取 --hash-style 为 gnu 的动态库，导致了如上的错误。

解决方案

配置 --hash-style 为 both：

1

LDFLAGS += -Wl,--hash-style=both

参考

• Only one –hash-style in embedded Linux. Why?
• Binaries built on RHEL5 or FC6 do not work on RHEL4 or FC5!
• Android NDK UnsatisfiedLinkError: “dlopen failed: empty/missing DT_HASH”
• Trouble understanding gcc linker options

Homebrew

简介

Homebrew是OS X上类似于apt-get和yum的软件包管理器，软件源依托于Github之上，所以在国内的网络环境之下，常常会出现使用Homebrew安装软件时，如brew install sshfs，经常会长时间卡在Updating Homebrew...。

OS X 10.9开始支持

安装

首先安装依赖Xcode命令行工具：

1

$ xcode-select --install

然后安装Homebrew：

1

$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

卸载

1
2

$ ruby -e "$(curl -fsSL $https://raw.githubusercontent.com/Homebrew/install/master/uninstall)"
$ sudo rm -rf /usr/local/

解决软件源更新慢问题

取消更新

当安装过程中，卡在Updating Homebrew...时，我们可以按住control + c，来取消本次更新；之后命令行会显示^C，表示取消成功，后面会继续安装工作。

这个方法是临时，仅在本次安装生效。

关闭自动更新

Homebrew的软件源更新，是在每次安装时自动执行的，可以通过配置进行关闭。

zsh终端方式：

1
2

$ echo 'export HOMEBREW_NO_AUTO_UPDATE=true' >> ~/.zshrc
$ source ~/.zshrc

bash终端方式：

1
2

$ echo 'export HOMEBREW_NO_AUTO_UPDATE=true' >> ~/.bash_profile
$ source ~/.bash_profile

这个方法是永久的，每次安装都会生效，但弊端是无法获取最新的软件。

替换软件源

这里推荐中科大的镜像源，亲测可用。

替换homebrew源

1
2

$ cd "$(brew --repo)"
$ git remote set-url origin https://mirrors.ustc.edu.cn/brew.git

还原官方源：

1
2

$ cd "$(brew --repo)"
$ git remote set-url origin https://github.com/Homebrew/brew.git

替换homebrew-core源(核心软件仓库)

1
2

$ cd "$(brew --repo)/Library/Taps/homebrew/homebrew-core"
$ git remote set-url origin https://mirrors.ustc.edu.cn/homebrew-core.git

还原官方源：

1
2

$ cd "$(brew --repo)/Library/Taps/homebrew/homebrew-core"
$ git remote set-url origin https://github.com/Homebrew/homebrew-core.git

替换homebrew-cask源(macOS应用)

1
2

$ cd "$(brew --repo)"/Library/Taps/homebrew/homebrew-cask 
$ git remote set-url origin https://mirrors.ustc.edu.cn/homebrew-cask.git

若提示找不到"$(brew --repo)"/Library/Taps/homebrew/homebrew-cask，则：

1
2

$ cd "$(brew --repo)"/Library/Taps/homebrew/
$ git clone https://mirrors.ustc.edu.cn/homebrew-cask.git

还原官方源：

1
2

$ cd "$(brew --repo)"/Library/Taps/homebrew/homebrew-cask  
$ git remote set-url origin https://github.com/Homebrew/homebrew-cask

brew cask安装软件，会自动创建软链接到Application目录，这样在Launchpad中也能查看到安装的软件，方便启动软件

替换homebrew bottles源(预编译二进制软件包)

zsh终端方式：

1
2

$ echo 'export HOMEBREW_BOTTLE_DOMAIN=https://mirrors.ustc.edu.cn/homebrew-bottles' >> ~/.zshrc
$ source ~/.zshrc

bash终端方式：

1
2

$ echo 'export HOMEBREW_BOTTLE_DOMAIN=https://mirrors.ustc.edu.cn/homebrew-bottles' >> ~/.bash_profile
$ source ~/.bash_profile

还原官方源：进入如上终端配置文件，并删除HOMEBREW_BOTTLE_DOMAIN改行配置，并
source终端配置文件，使之生效。

常见错误

• Error: Another active Homebrew update process is already in progress.
  解决方法：rm -rf /usr/local/var/homebrew/locks

附

Homebrew常用命令

• 查看Homebrew版本：

  1

  $ brew -v

• Homebrew帮助信息：

  1	$ brew [cask] -h

• 更新Homebrew：

  1	$ brew update

• 更新Homebrew cask：

  1	$ brew cask upgrade

• 安装软件：

  1	$ brew [cask] install <packageName>

• 卸载软件：

  1	$ brew [cask] uninstall <packageName>

• 查询可用软件：

  1	$ brew search <packageName>

• 查看已安装软件：

  1	$ brew [cask] list

• 查看软件信息：

  1	$ brew [cask] info <packageName>

确认shell版本方式

1

$ echo $SHELL

输出/bin/zsh为zsh终端，输出/bin/bash为bash终端。

错误一

从web端查看仓库大小，大约1.5G左右，首先直接执行git clone，报错如下：

1
2
3
4
5
6

remote: Counting objects: 10994, done.
remote: Compressing objects: 100% (3085/3085), done.
error: RPC failed; curl 56 GnuTLS recv error (-110): The TLS connection was non-properly terminated.
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

增大postBuffer

在增大postBuffer的同时，关闭ssl认证：

1
2

$ git config --global http.postBuffer 2048000000 # 设置为2G
$ git config --global http.sslVerify false # 关闭sslVerify

设置成功后，重新clone，错误依旧。

使用openssl替换gunssl

1.安装相关依赖环境：

1

$ sudo apt-get install build-essential fakeroot dpkg-dev libcurl4-openssl-dev

2.获取git源码：

1

$ sudo apt-get source git

若出现如下错误：

1

E: You must put some 'source' URIs in your sources.list

则需要将设置->Software & Updates->Ubuntu Software->Source code勾选：

若出现如下错误：

1

couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied) [duplicate]

则需要更改权限：

1

sudo chown _apt /var/lib/update-notifier/package-data-downloads/partial/

3.安装git的依赖

1

$ sudo apt-get build-dep git

4.进入git目录，重新编译：

1
2
3
4

$ cd git-2.7.4/
$ vim ./debian/control # 将libcurl4-gnutls-dev修改为libcurl4-openssl-dev
$ vim ./debian/rules # 整行删除TEST=test
$ sudo dpkg-buildpackage -rfakeroot -b -uc -us -j4 # 编译

5.回到上一级目录，安装编译好的安装包：

1
2

$ cd ..
$ sudo dpkg -i git_2.7.4-0ubuntuxxx_amd64.deb # 安装包名字可能有所不同

执行完成如上步骤后，重新clone，发现依旧报错，请看错误二。

错误二

1
2
3
4
5
6

remote: Counting objects: 10994, done.
remote: Compressing objects: 100% (3085/3085), done.
error: RPC failed; curl 18 transfer closed with outstanding read data remaining
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

重新确认postBuffer，配置确实生效了：

1
2
3
4
5

$ cat ~/.gitconfig

[http]
sslVerify = false
postBuffer = 2048000000

浅层clone

晕，实在搞不定了，采取极端方法，首先clone一层：

1

$ git clone --depth=1 http://xxx.git

浅层clone成功后，再完整拉取：

1
2
3

$ git fetch --unshallow # 拉取完整当前分支
$ git remote set-branches origin '*' # 追踪所有远程分支
$ git fetch -v # 拉取所有远程分支

至此，终于成功地clone了一个完整的仓库。

本次的实验场景为i386:x86-64 GNU/Linux，测试音频为nhxc.wav，测试程序为bin2obj.c。

查看该平台的ELF文件相关信息

生成目标文件

1

$ gcc -c bin2obj.c -o bin2obj.o

查看该平台ELF文件相关信息

1
2
3
4
5
6
7

$ objdump -x bin2obj.o

bin2obj.o:     file format elf64-x86-64
bin2obj.o
architecture: i386:x86-64, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x0000000000000000

由上可知，文件格式为elf64-x86-64，CPU架构为architecture。

转换

首先通过objcopy --help选项查看相关参数的意义:

1
2
3
4
5
6

$ objcopy --help
-I --input-target <bfdname>      Assume input file is in format <bfdname>
-O --output-target <bfdname>     Create an output file in format <bfdname>
-B --binary-architecture <arch>  Set output arch, when input is arch-less
......
objcopy: supported targets: elf64-x86-64 elf32-i386 elf32-iamcu elf32-x86-64 a.out-i386-linux pei-i386 pei-x86-64 elf64-l1om elf64-k1om elf64-little elf64-big elf32-little elf32-big pe-x86-64 pe-bigobj-x86-64 pe-i386 plugin srec symbolsrec verilog tekhex binary ihex

由上可知，-I选项指定输入文件的格式，-O指定输出文件的格式，在supported targets中选择对应的格式；-B是指定目标文件的架构i386:x86-64，即上文objdump -x命令查询的architecture。

转换：

1

$ objcopy -I binary -O elf64-x86-64 -B i386:x86-64 nhxc.wav audio.o

查看转换后生成的目标文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

$ objdump -x audio.o

audio.o:     file format elf64-x86-64
audio.o
architecture: i386:x86-64, flags 0x00000010:
HAS_SYMS
start address 0x0000000000000000

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .data         0000fab0  0000000000000000  0000000000000000  00000040  2**0
                  CONTENTS, ALLOC, LOAD, DATA
SYMBOL TABLE:
0000000000000000 l    d  .data0000000000000000 .data
0000000000000000 g       .data0000000000000000 _binary_nhxc_wav_start
000000000000fab0 g       .data0000000000000000 _binary_nhxc_wav_end
000000000000fab0 g       *ABS*0000000000000000 _binary_nhxc_wav_size

可以看到file format、architecture信息与bin2obj.o的相同，_binary_nhxc_wav_start指向音频内容的起始地址，_binary_nhxc_wav_end指向音频内容的结尾地址，_binary_nhxc_wav_size指向文件大小的存储地址。

_binary_*_start/end/size，*是二进制文件的文件名及后缀名。

测试

bin2obj.c：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

#include <stdio.h>
#include <elf.h>

extern _binary_nhxc_wav_start;
extern _binary_nhxc_wav_end;
extern _binary_nhxc_wav_size;

int main() {
printf("binary to object:\n");
    
printf("elf head: %ld\n", sizeof(Elf64_Ehdr));
    printf("_binary_nhxc_wav_size: %p\n_binary_nhxc_wav_end: %p\n_binary_nhxc_wav_size: %p\n", &_binary_nhxc_wav_start, &_binary_nhxc_wav_end,  &_binary_nhxc_wav_size);

    unsigned char * audio_buf = (unsigned char *)&_binary_nhxc_wav_start;
    unsigned long size = (unsigned long)&_binary_nhxc_wav_size;

FILE *fp = fopen("./out.wav", "wb");
if (!fp) {
fprintf(stderr, "fopen failed!\n");
return -1;
}

fwrite(audio_buf, size, 1, fp);

fclose(fp);

return 0;
}

通过_binary_nhxc_wav_start和_binary_nhxc_wav_size两个符号，读取音频文件。

编译并运行：

1
2
3
4
5
6
7
8

$ gcc -c bin2obj.c -o bin2obj.o
$ g++ bin2obj.o audio.o -o bin2obj
$ ./bin2obj
binary to object:
elf head: 64
_binary_nhxc_wav_size: 0x601040
_binary_nhxc_wav_end: 0x610af0
_binary_nhxc_wav_size: 0xfab0

比对写入的文件out.wav与原始文件nhxc.wav，完全一致：

1
2

155e62d81e84fa7493fefe82223bcc2a  nhxc.wav
155e62d81e84fa7493fefe82223bcc2a  out.wav

查看audio.o：

1
2
3
4
5
6

$ hexdump -C audio.o | head -n 5
00000000  7f 45 4c 46 02 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
00000010  01 00 3e 00 01 00 00 00  00 00 00 00 00 00 00 00  |..>.............|
00000020  00 00 00 00 00 00 00 00  d0 fb 00 00 00 00 00 00  |................|
00000030  00 00 00 00 40 00 00 00  00 00 40 00 05 00 02 00  |....@.....@.....|
00000040  52 49 46 46 a8 fa 00 00  57 41 56 45 66 6d 74 20  |RIFF....WAVEfmt |

如程序输出，ELF文件头部信息结构体为64字节，而转换生成的目标文件中，音频内容始于0x40字节偏移（wav头始于RIFF，可以参考wav文件解析），而0x40正是十进制的64。

Reference

• 《程序员的自我修养——链接、装载与库》P68

函数说明

1
2
3
4

#include <string.h>

char *strtok(char *str, const char *delim);
char *strtok_r(char *str, const char *delim, char **saveptr);

说明

• strtok以包含在delim中的字符为分割符，将str分割成一个个子串；若str为空值NULL，则函数内部保存的静态指针（指向上一次分割位置后一个字节）在下一次调用中将作为起始位置。
• strtok_r功能同strtok，不过其将strtok函数内部保存的指针显示化，通过saveptr输入，以saveptr作为分割的起始位置。

参数

• str: 待分割的源字符串
• delim: 分割符字符集合
• saveptr: 一个指向char *的指针变量，保存分割时的上下文

返回值

• 若未提取到子串，返回值为指向源字符串首地址的指针，可以完整打印源字符串
• 若提取到子串，返回值为提取出的子串的指针，这个指针指向的是子串在源字符串中的起始位置，因为子串末尾的下一个字符在提取前为分割符，提取后被修改成了'/0’，所以可以成功打印子串的内容
• 若在成功提取到子串后，没有可以被分割的子串，返回NULL

示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14

#include <stdio.h>
#include <string.h>

int main(void) {
  char str[12] = "hello,world\0";
  char *token = strtok(str, ",");

  while (token != NULL) {
    printf("%s\n", token);
    token = strtok(NULL, ",");
  }
   
  return 0;
}

使用注意事项

不会生成新的字符串，只是在源字符串上做了修改，源字符串会发生变化

1
2
3
4

char str[12] = "hello,world\0";
printf("str before strtok: %s\n", str);
char *token = strtok(str, ",");
printf("str after strtok: %s\n", str);

1
2

$ str before strtok: hello,world
$ str after strtok: hello

如上实验，str的值，在对其做strtok操作之后，发生了变化，分割符之后的内容不见了。事实上，strtok函数是根据输入的分割符（即,），找到其首次出现的位置（即world之前的,），将其修改为'/0’。

第一个参数不可为字符串常量

因为strtok函数会修改源字符串，所以第一个参数不可为字符串常量，不然程序会抛出异常。

若在第一次提取子串后，继续对源字符串进行提取，应在其后的调用中将第一个参数置为空值NULL

1
2
3
4
5
6

char str[12] = "hello,world\0";
char *token = strtok(str, ",");   
while (token != NULL) {
    printf("%s\n", token);
    token = strtok(NULL, ",");
}

1
2

$ hello
$ world

在第一次提取子串时，strtok用一个指针指向了分割符的下一位，即’w’所在的位置，后续的提取给strtok的第一个参数传递了空值NULL，strtok会从上一次调用隐式保存的位置，继续分割字符串。

第二个参数是分割符的集合，支持多个分割符

1
2
3

char str[12] = "hello,world\0";
char *token = strtok(str, ",l");
printf("%s\n", token);

1

$ he

由上可见，strtok函数在分割字符串时，不是完整匹配第二个参数传入的分割符，而是使用包含在分割符集合中的字符进行匹配。

若首字符为分割符，则会被忽略

1
2
3

char str[13] = ",hello,world\0";
char *token = strtok(str, ",");
printf("%s\n", token);

1

$ hello

如上所示，若首字符为分割符，strtok采用了比常规处理更快的方式，直接跳过了首字符。

strtok为不可重入函数，使用strtok_r更灵活和安全

strtok函数在内部使用了静态变量，即用静态指针保存了下一次调用的起始位置，对调用者不可见；strtok_r则将strtok内部隐式保存的指针，以参数的形式由调用者进行传递、保存甚至是修改，使函数更具灵活性和安全性；此外，在windows也有分割字符串安全函数strtok_s。

源码

strtok.c:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

/* Copyright (C) 1991-2018 Free Software Foundation, Inc.
   This file is part of the GNU C Library.

   The GNU C Library is free software; you can redistribute it and/or
   modify it under the terms of the GNU Lesser General Public
   License as published by the Free Software Foundation; either
   version 2.1 of the License, or (at your option) any later version.

   The GNU C Library is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
   Lesser General Public License for more details.

   You should have received a copy of the GNU Lesser General Public
   License along with the GNU C Library; if not, see
   <http://www.gnu.org/licenses/>.  */

#include <string.h>


/* Parse S into tokens separated by characters in DELIM.
   If S is NULL, the last string strtok() was called with is
   used.  For example:
char s[] = "-abc-=-def";
x = strtok(s, "-");// x = "abc"
x = strtok(NULL, "-=");// x = "def"
x = strtok(NULL, "=");// x = NULL
// s = "abc\0=-def\0"
*/
char *
strtok (char *s, const char *delim)
{
  static char *olds;
  return __strtok_r (s, delim, &olds);
}

strtok_r.c:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79

/* Reentrant string tokenizer.  Generic version.
   Copyright (C) 1991-2018 Free Software Foundation, Inc.
   This file is part of the GNU C Library.

   The GNU C Library is free software; you can redistribute it and/or
   modify it under the terms of the GNU Lesser General Public
   License as published by the Free Software Foundation; either
   version 2.1 of the License, or (at your option) any later version.

   The GNU C Library is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
   Lesser General Public License for more details.

   You should have received a copy of the GNU Lesser General Public
   License along with the GNU C Library; if not, see
   <http://www.gnu.org/licenses/>.  */

#ifdef HAVE_CONFIG_H
# include <config.h>
#endif

#include <string.h>

#ifndef _LIBC
/* Get specification.  */
# include "strtok_r.h"
# define __strtok_r strtok_r
#endif

/* Parse S into tokens separated by characters in DELIM.
   If S is NULL, the saved pointer in SAVE_PTR is used as
   the next starting point.  For example:
char s[] = "-abc-=-def";
char *sp;
x = strtok_r(s, "-", &sp);// x = "abc", sp = "=-def"
x = strtok_r(NULL, "-=", &sp);// x = "def", sp = NULL
x = strtok_r(NULL, "=", &sp);// x = NULL
// s = "abc\0-def\0"
*/
char *
__strtok_r (char *s, const char *delim, char **save_ptr)
{
  char *end;

  if (s == NULL)
    s = *save_ptr;

  if (*s == '\0')
    {
      *save_ptr = s;
      return NULL;
    }

  /* Scan leading delimiters.  */
  s += strspn (s, delim);
  if (*s == '\0')
    {
      *save_ptr = s;
      return NULL;
    }

  /* Find the end of the token.  */
  end = s + strcspn (s, delim);
  if (*end == '\0')
    {
      *save_ptr = end;
      return s;
    }

  /* Terminate the token and make *SAVE_PTR point past it.  */
  *end = '\0';
  *save_ptr = end + 1;
  return s;
}
#ifdef weak_alias
libc_hidden_def (__strtok_r)
weak_alias (__strtok_r, strtok_r)
#endif

Reference

• C语言线程安全:不可重入函数汇总

sysroot为何物

做过交叉编译的同学们，一定对下面这个错误十分熟悉吧：

1
2

/cross-compiling/ld: cannot find crt1.o: No such file or directory
/cross-compiling/ld: cannot find crti.o: No such file or directory

在我们的pc上，这两个文件一般在/usr/lib或者/usr/lib32中，通过gcc -print-search-dirs可以看到这两个路径默认就在库的搜索路径中，所以在pc上编译程序时不存在链接器找不到crt1.o和crti.o的问题。

crt1.o负责应用程序的启动，其中包含了程序的入口函数_start以及两个未定义的符号__libc_start_main和main，由_start负责调用__libc_start_main初始化libc，然后调用我们源代码中定义的main函数，crti.o负责辅助启动这些代码。

下面我们使用交叉编译工具链来查看库的搜索路径/cross-compiling/gcc -print-search-dirs，发现crt1.o和crti.o的所在目录并不在库的搜索路径中，所以会出现上述的问题。

下面就需要sysroot出场了。
sysroot被称为逻辑根目录，只在链接过程中起作用，作为交叉编译工具链搜索库文件的根路径，如配置--sysroot=dir，则dir作为逻辑根目录，链接器将在dir/usr/lib中搜索库文件。

只有链接器开启了–with-sysroot选项，–sysroot=director才生效

Reference

• crti.o file missing
• crt1.o, crti.o, crtbegin.o, crtend.o, crtn.o

准备

hello.c:

1
2
3
4
5

#include <stdio.h>

__attribute__ ((visibility ("default"))) void hello() {
printf("Hello World!\n");
}

hello.h:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

#ifndef __HELLO__H
#define __HELLO__H

#ifdef __cplusplus
extern "C" {
#endif

void hello();

#ifdef __cplusplus
}
#endif

#endif

bye.c:

1
2
3
4
5

#include <stdio.h>

void bye() {
printf("Bye Bye!\n");
}

bye.h:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

#ifndef __BYE__H
#define __BYE__H

#ifdef __cplusplus
extern "C" {
#endif

void bye();

#ifdef __cplusplus
}
#endif

#endif

编译

编译时使用-fvisibility=hidden,可以默认将符号隐藏;需要对外的符号使用__attribute__ ((visibility ("default")))修饰即可:

1
2

$ gcc -fvisibility=hidden -I. -c hello.c -o hello.o
$ gcc -fvisibility=hidden -I. -c bye.c -o bye.o

其中hello()未被隐藏,bye()是被隐藏的.

链接

将生成的两个.o文件重定位到libt.o中:

1

$ ld -r hello.o bye.o -o libt.o

去除无用的符号

1

$ strip --strip-unneeded libt.o

隐藏的符号本地化(我也不知道中文怎么翻译了)

1

$ objcopy --localize-hidden libt.o libt_hidden.o

打包成静态库

1

$ ar crv libt.a libt_hidden.o

验证

调用未被隐藏的hello()

test1.c:

1
2
3
4
5
6

#include "hello.h"

int main(void) {
    hello();
    return 0;
}

编译并运行

1
2
3

$ gcc -I. test1.c -L. -lt -o test
$ ./test
Hello World!

调用隐藏的bye()

test2.c

1
2
3
4
5
6

#include "bye.h"

int main(void) {
    bye();
    return 0;
}

编译并运行

1
2
3
4
5

$ gcc -I. test2.c -L. -lt -o test
$ ./test
/tmp/ccdaJT7s.o: In function `main':
test2.c:(.text+0xa): undefined reference to `bye'
collect2: error: ld returned 1 exit status

配置git

笔者使用的是v2.1.0，推荐大家使用v1.8以上的版本。 查看git版本：

1

$ git --version

配置命令git config分为三个级别：

1
2
3

--system : 系统级,位于 /etc/gitconfig .
--global : 用户级,位于 ~/.gitconfig .
--local : 仓库级,位于 repo/.git/config ,default并且优先级最高.

首先需要删除global用户信息,防止不同git软件之间的冲突：

1
2

$ git config --global --unset user.name
$ git config --global --unset user.email

设置用户信息.若同时使用gitlab和github,推荐配置local用户信息：

1
2

$ git config --local user.name "username"
$ git config --local user.email "email"

git支持https和ssh等协议.https除了速度慢以外，还有个最大的麻烦是每次推送都必须输入口令，而ssh支持的原生git协议速度最快。
检查本机SSH公钥:

1

$ ls ~/.ssh

若存在,则将id_rsa.pub添加到github的SSH keys中。若不存在,则生成:

1

$ ssh-keygen -t rsa -C "your_email@youremail.com" 

当ssh配置完成后，再次检查ssh连接情况：

1
2

$ ssh -T git@github.com
Hi! You’ve successfully authenticated, but GitHub does not provide shell access.

若出现上述信息，则表示设置成功。
若使用https访问, 则进行如下配置,并且设置超时时间避免重复输入密码：

1
2

$ git config --global http.sslverify false
$ git config --global credential.helper 'cache --timeout=3600'

设置可视化diff和merge工具, linux系统上推荐使用meld或者diffuse：

1
2

$ git config --global diff.tool meld
$ git config --global merge.tool meld

保存用户名,密码, 避免每次pull/push操作都需要手动输入：

1
2

$ git config --global credential.helper store
# 执行上免的命令后, 下次操作输入的密码会被保存

设置颜色,利于使用：

1

$ git config --global color.ui.true

设置别名：

1

$ git config --global alias checkout co 

上面的命令将checkout设置为别名co。

最后,查看一下所有的设置：

1
2
3

$ git config --local --list
$ git config --global --list
$ git config --system --list

工作流

工作区就是你的本地仓库文件夹,不过其中的.git目录不属于工作区,而是版本库。里面存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。
现在来解释一下前面的添加和提交操作：

1. git add把文件添加进去，实际上就是把文件修改添加到暂存区；
2. git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。
   因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以，现在，git commit就是往master分支上提交更改。

基本操作

获取远程仓库：

1

$ git clone git@github.com:USERNAME/repo.git

将本地的仓库添加到远程：

1
2
3

$ cd repo
$ git init
$ git remote add origin git@github.com:USERNAME/repo.git

origin就是一个名字，是git为你默认创建的指向这个远程代码库的标签。

添加修改:

1
2
3

$ git add <filename> 
$ git add .  # 添加当前目录所有修改过的文件  
$ git add *  # 递归地添加执行命令时所在的目录中的所有文件

提交修改:

1
2

$ git commit -m "commit message"
$ git commit -am "commit message"

commit message的填写可以参考写好 Git Commit 信息的 7 个建议。
am将添加和提交合并为一步,但只对本来就存在的文件有效。

推送修改：

1

$ git push -u origin <feature-branch-name>

-u选项可以将本地分支与远程分支关联,下次git pull操作时可以不带参数.具体参见这里。

查看远程仓库：