Yan*_*hon 1 c warnings gcc-warning
是的，这个问题已经被问过很多次了，我一直在寻找和阅读论坛和帖子，但答案都与这个无关（或者看起来如此）。所以，我有这个主文件：
\n\n-- sgbd_server.c --
\n\n#include "sgbd_server.h"\n\n/**\n * Open server pipe and return handle. -1 = error\n */\nint open_server_pipe() {\n return pipe_open(FIFO_NAME, O_RDONLY, S_CON_COLOR);\n}\n\n/**\n * Close server pipe\n */\nvoid close_server_pipe(int fd) {\n pipe_close(fd, FIFO_NAME, S_CON_COLOR);\n}\n\n\nint main(int argc, char *argv[]) {\n int pipe_fd;\n pipe_fd = open_server_pipe();\n\n if (pipe_fd == -1) {\n perror("Cannot open pipe");\n }\n\n close_server_pipe(pipe_fd); \n\n exit(EXIT_SUCCESS);\n}\n然后是头文件：
\n\n-- sgbd_server.h --
\n\n#include "common.h"\n\n#define FIFO_NAME "./sgbd_server_pipe"\n#define BUFFER_SIZE PIPE_BUF\n\n#define S_CON_COLOR 1 /* C_COLOR_RED */\n--通用.h --
\n\n#include <unistd.h>\n#include <stdlib.h>\n#include <stdio.h>\n#include <string.h>\n#include <fcntl.h>\n#include <limits.h>\n#include <sys/types.h>\n#include <sys/stat.h>\n\n#include "console.h"\n\n#define CLIENT_FIFO_PREFIX = "./sgbd_client_"\n\nint pipe_open(char *f, int mode, int color);\n\nvoid pipe_close(int pipe_fd, char *f, int color);\npipe_open和pipe_close中定义的两个函数pipe.c和 基本上返回0和void。最后一个文件在 Make 文件中单独编译。
我不是制作 Make 文件的专家，但为了这个问题，这里是：
\n\nSERVER = sgbd_server\nCLIENT = sgbd_client\n\nCC = gcc\nC_FLAGS = -Wall -I.\nLINKER = gcc\nL_FLAGS = -Wall -l pthread -Wall -I.\n\nRM = rm -f\n\n\nclient: sgbd_client.o pipe.o console.o\n @echo -n "Building client... "\n @$(LINKER) $(L_FLAGS) -o $(CLIENT) sgbd_client.o pipe.o console.o\n @echo "Complete!\\n"\n\nserver: sgbd_server.o pipe.o console.o\n @echo -n "Building server... "\n @$(LINKER) $(L_FLAGS) -o $(SERVER) sgbd_server.o pipe.o console.o\n @echo "Complete!\\n"\n\nsgbd_client.o: sgbd_client.c\n @echo -n "Refreshing client sources... "\n @$(CC) $(C_FLAGS) -c sgbd_client.c\n @echo "Done!"\n\nsgbd_server.o: sgbd_server.c common.h\n @echo -n "Refreshing server sources..."\n @$(CC) $(C_FLAGS) -c sgbd_server.c common.h\n @echo "Done!"\n\npipe.o: pipe.c\n @echo -n "Refreshing pipe sources..."\n @$(CC) $(C_FLAGS) -c pipe.c\n @echo "Done!"\n\nconsole.o: console.c\n @echo -n "Refreshing console sources..."\n @$(CC) $(C_FLAGS) -c console.c\n @echo "Done!"\n\nclean:\n @echo -n "Cleaning up executables and object files... "\n @$(RM) $(SERVER) $(CLIENT) *.o\n @echo "Ok\\n"\n**注意** ：该文件console.c并实现了一些控制控制台上 I/O 的功能，没什么花哨的。正如你所看到的，它也是单独编译的。
现在，当我打字时make client，一切都很好，鸟儿正在签名，等等。但是当我打字时make server，它会吐出来
sgbd_server.c: In function \xe2\x80\x98open_server_pipe\xe2\x80\x99:\nsgbd_server.c:7: warning: implicit declaration of function \xe2\x80\x98pipe_open\xe2\x80\x99\nsgbd_server.c: In function \xe2\x80\x98close_server_pipe\xe2\x80\x99:\nsgbd_server.c:14: warning: implicit declaration of function \xe2\x80\x98pipe_close\xe2\x80\x99\n我正在 Linux amd64 上运行 GCC，如果它有什么区别的话（我对此表示怀疑）。
\n\n现在，为什么它会警告我呢？这两个函数在 中声明common.h，它包含在sgbd_server.h... 我在这里缺少什么？
感谢您的时间！
\n\n**更新**
\n\n谢谢大家的建议。我确实尝试查找我的包含路径中的其他位置是否有一个文件会common.h以某种方式被包含...虽然我未能找到任何会在编译过程中滑倒的文件而不是本地common.h（sig），但我发现了一些.ghc文件坐在我的源文件夹中。由于它们没有被清理make clean，我手动删除了这些文件。你猜怎么了？没有警告。这些文件是什么以及为什么创建它们？
common.h首先，我认为在 makefile 中提供给编译器不是一个好主意：
@$(CC) $(C_FLAGS) -c sgbd_server.c common.h
这会更好，因为：
@$(CC) $(C_FLAGS) -c sgbd_server.c
头文件通常仅包含一个#include. 您似乎告诉编译器尝试编译common.h为独立的 C 文件。这是客户端和服务器编译命令之间的差异之一，您应该修复它。
我唯一可以建议的是，您可能无法获得您认为获得的头文件。首先输入以下行：
#error Urk! in common.h
在你的顶部common.h并确保构建在那里失败。
如果不是，则该文件来自其他地方。您可能还想对您的文件执行相同的操作sgbd_server.h。
根据您的编辑：
我在源文件夹中发现了一些 .ghc 文件。由于 make clean 没有清理它们，所以我手动删除了这些文件。你猜怎么了？没有警告。这些文件是什么以及为什么创建它们？
假设ghc是一个拼写错误，您的意思gch是由 生成的预编译头gcc，至少部分是为了加快编译过程。与其在构建过程中多次处理头文件（每个包含头文件的源文件处理一次），不如预编译一次并使用预编译版本，效率要高得多。
我认为这很可能是由于您common.h在创建服务器时将其包含在编译器命令行中而导致的。默认情况下，直接给出的头文件gcc将转换为预编译头文件，并在此之后优先使用。为了测试这一点，我创建了一个qq.h文件并执行gcc qq.h并弹出qq.h.gch。
鉴于删除它们解决了您的问题，这些文件很可能以某种方式导致了您的问题（可能是预编译头的存在比真实头更旧，或者完全是其他东西）。您的编译行很有可能：
@$(CC) $(C_FLAGS) -c sgbd_server.c common.h
首先编译服务器程序，包括旧的预编译头，然后从新的头文件中创建新的预编译头。
这可能就是为什么更改common.h没有（立即）效果的原因。您必须make ; touch common.h ; make确保在服务器程序中使用较新的预编译头文件。
是否想要追溯到根本原因并获得正确的解释是一个品味问题 - 有一种思想流派认为，有时您应该只记录如何修复它，而不必太担心，以免陷入困境现实本身的本质。
当然不是我，我是那种会试图将问题追溯到导致问题的单个亚原子粒子的性格类型，但有时实用主义要求我放手:-)