使用 libtinfo 依赖项编译的带有 ncurses 的 C 代码

标签 c linux ncurses

我最近在 Linux 上使用 ncurses 用 C 编写了一个扫雷器实现;在我的电脑上一切正常,但如果我尝试将编译后的二进制文件提供给其他人,他们通常会收到错误消息:

加载共享库时出错:libtinfo.so.5:无法打开共享对象文件:没有这样的文件或目录

如果我让他们重新编译代码,一切都很好。通过环顾四周,我发现这是 libtinfo 和 libncurses 之间的分离问题。它可以通过创建一些 simlink 来解决,但只有当用户具有 root 权限时,它才是可行的解决方案。

截至此处(和其他来源),http://www.cyberspice.org.uk/blog/2009/12/24/tinfo-about-dash/ ,这似乎是一个可以通过以不同方式编写代码或以不同方式编译来解决的问题。我宁愿能够以这种方式解决问题,也不愿强制人们建立模拟链接。

是否有任何指向正确方向以了解如何解决我的问题的指示?如果需要,我可以添加任何代码或详细信息,但是发布所有内容 似乎有点矫枉过正,所以请告诉我可以添加哪些内容(如果需要)以更好地理解问题。

我现在唯一要发布的是 makefile:

CC=gcc -std=gnu89 -pedantic -Wall -Wno-unused-but-set-variable
CFLAGS=-c -g
LDFLAGS=-lncurses

NAME=campo_ex
OBJECTS=error.o interface.o utilities.o main.o grid.o

DEBUG_NAME=debug
DEBUG_OBJECTS=error.o interface.o utilities.o debug.o

$(NAME): $(OBJECTS)
    $(CC) -o $(NAME) $(OBJECTS) $(LDFLAGS)

main.o: main.c interface.h grid.h
    $(CC) $(CFLAGS) main.c

debug.o: debug.c interface.h
    $(CC) $(CFLAGS) debug.c

error.o: error.c error.h
    $(CC) $(CFLAGS) error.c

utilities.o: utilities.c utilities.h
    $(CC) $(CFLAGS) utilities.c

interface.o: interface.c interface.h error.h utilities.h
    $(CC) $(CFLAGS) interface.c

grid.o: grid.c grid.h error.h
    $(CC) $(CFLAGS) grid.c

.PHONY: clean
clean:
    @-rm -f $(OBJECTS) $(NAME) $(DEBUG_NAME) $(DEBUG_OBJECTS)

.PHONY: debug
debug: $(DEBUG_OBJECTS)
    $(CC) -o $(DEBUG_NAME) $(DEBUG_OBJECTS) $(LDFLAGS)

最佳答案

在编译后的程序上执行 readelf -d 可能会显示与 libtinfo.so.5 的连接

$ readelf -d /path/to/your/program  | grep NEEDED
[...]
0x0000000000000001 (NEEDED)             Shared library: [libtinfo.so.5]
[...]

这可能是因为您的 libncurses.so 以某种方式将其引入,例如通过包含类似的东西:

INPUT(... -ltinfo)

(或类似的东西。我只能在这里猜测..)

您可以尝试将 -Wl,--as-needed 添加到您的 LDFLAGS 并希望您的程序没有引用来自 libtinfo 的任何符号> 直接这样链接器就不需要为你的程序添加对 libtinfo 的依赖。

LDFLAGS=-Wl,--as-needed -lncurses

使用新的 LDFLAGS 重新编译并使用 readelf -d 再次检查它是否已正确编译和链接。

如果 libncurses 使用来自 libtinfo 的符号但不包含对 libtinfo 的依赖,则使用 --as-needed 可能会出现问题 本身。如果发生这种情况,您的构建将失败并提示 unreferenced symbols 或类似的..

因此,如果这不起作用,您可能需要修复您的 curses 安装或使用您已经提到的(在我看来非常肮脏的)符号链接(symbolic link) hack。或者让用户在他们的系统上编译代码 - 如果您不想共享代码,您也可以只在目标系统上进行链接。

要修复 symlink-need-root-privileges 问题,您还可以将 -Wl,-rpath,'$ORIGIN/../lib' 添加到链接器标志并扩展库搜索你的程序的路径。这使用户能够将您的二进制文件安装到 /home/user/bin/program 并在 /home/user/bin/../lib 中搜索库。所以他们可以在 /home/user/lib 中进行“肮脏的”符号链接(symbolic link)黑客攻击。

仅分发二进制文件时总是有问题。

关于使用 libtinfo 依赖项编译的带有 ncurses 的 C 代码,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/15798291/

相关文章:

c - 使用 CUDA-C 生成索引

c - 编写 C 动态库 [DSOs] 的良好实践(二进制兼容性 + 内存管理)

c - 从内核空间执行用户空间函数

Ncurses shell 转义会丢弃父进程输出

c - Ncurses 鼠标滚轮向上滚动

c - C 中存在高迭代循环的程序不会给我输出..为什么?

c - 主从非阻塞监听器

c - 我应该在C函数的Postgresql中取消对bytea字段的转义吗,如果是的话-怎么做?

linux - 如何将符号链接(symbolic link)文件从 Linux 复制到 Windows,然后再复制回 Linux 但仍将其保留为符号链接(symbolic link)

macOS 上的 Clang 无法从 ncurses 链接 lmenu