为何编译自定义库需链接ownlib.a，而系统库仅需头文件？

核心差异根源：编译器对系统库的默认支持 vs 自定义库的手动依赖声明 #

1. 系统标准库的“隐形”链接机制

系统自带的标准库（比如包含strlen的libc）是GCC等编译器默认自动处理的：

• 自动链接：GCC在编译链接阶段会默认把libc.a（静态）或libc.so（动态）加入链接列表，不需要你手动指定。
• 默认搜索路径：系统库文件存放在编译器默认识别的路径（如/usr/lib），编译器会自动去这些路径查找库文件。
• 头文件仅作声明：<string.h>只是提供了strlen的函数声明，告诉编译器这个函数的参数、返回值类型，避免编译阶段的语法错误；而函数的实现早已由编译器自动从系统库中引入。

2. 自定义静态库的手动依赖要求

你的ownlib.a属于自定义库，编译器没有内置对它的支持：

• 无默认链接：编译器不知道这个库的存在，必须明确告诉它要链接这个库文件。
• 无默认搜索路径：自定义库文件通常在当前目录或自定义路径，不在编译器的默认搜索列表里，所以必须直接指定库文件路径，或者用-L参数告诉编译器搜索路径。
• 头文件≠库文件：ownlib.h同样只是提供ft_strlen的声明，让编译main.c时不会报错“未知函数”，但函数的二进制实现只存在于ownlib.a中。链接阶段需要把main.o和ownlib.a中的ft_strlen.o合并成可执行文件，所以必须显式指定库文件。

对应你的场景解释 #

当你执行gcc main.c -o program.out时，编译阶段（生成main.o）因为有ownlib.h的声明能通过，但到了链接阶段，编译器找不到ft_strlen的实现代码，所以抛出“未定义引用”的错误（你看到的“找不到标识符”本质是链接错误）。

而加上ownlib.a后，gcc main.c ownlib.a -o program.out会让编译器把ownlib.a中的ft_strlen.o和main.o合并，补上缺失的函数实现，最终生成可执行文件。

附你提供的相关代码 #

Makefile

LIBNAME = ownlib.a

HEADERNAME = ownlib.h

SRCS = ft_strlen.c

OBJS        = $(SRCS:.c=.o)

CC      = gcc

CFLAGS      = -Wall -Wextra -Werror

AR      = ar

ARFLAGS     = -rcs

$(LIBNAME): $(OBJS) $(HEADERNAME)
    @$(AR) $(ARFLAGS) $(LIBNAME) $(OBJS)

all: $(LIBNAME)

clean:
    $(RM) $(OBJS)

fclean: clean
    $(RM) $(LIBNAME)

re: fclean all

%.o: %.c $(HEADERNAME)
    @${CC} ${CFLAGS} -c $< -o ${<:.c=.o}
   

.PHONY: all clean fclean re

ft_strlen.c

#include "ownlib.h"

size_t  ft_strlen(const char *str)
{
    int     i;

    i = 0;
    while (str[i] != '\0')
            i++;
    return (i);
}

main.c

#include <stdio.h>
#include "ownlib.h"

int     main(void)
{
    char    *str;
    
    str = "How many characters";
    
    printf("%i", ft_strlen(str));

    return (0);
}

内容的提问来源于stack exchange，提问作者Deepblack