静态库中的类别在运行时无法识别

Question

我正在Linux上构建一个可执行("工具")。使用include $(GNUSTEP_MAKEFILES)/tool.make.

它被链接到一个静态库，这个库也是用GNUstep构建的。库
包含Categories。

可执行文件构建良好，但在运行时出现错误，无法识别在静态库的Category:

中定义的
方法

Uncaught exception NSInvalidArgumentException, reason:  
ClassNameOfClassTheCategoryExtends(instance) does not recognize  
nameOfMethodInCategory

我试图通过将-ObjC传递到可执行文件的GNUmakefile中的链接器标志(也
尝试-all_load)来解决这个问题:

ADDITIONAL_LDFLAGS = -ObjC -all_load

但是clang似乎忽略了这一点。以下是
make install messages=yes debug=yes

的相关输出

clang: warning: argument unused during compilation: '-ObjC'  
[-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-all_load'  
[-Wunused-command-line-argument]

看起来ADDITIONAL_LDFLAGS使用编译、链接。

使用这个会得到相同的结果:

LDFLAGS := $(LDFLAGS) -ObjC

可执行文件GNUmakefile包括以下内容:

include $(GNUSTEP_MAKEFILES)/common.make
# My make 
include $(GNUSTEP_MAKEFILES)/tool.make

结果命令行输出为:

$ make install messages=yes debug=yes
This is gnustep-make 2.9.0. Type 'gmake print-gnustep-make-help' for help.
Running in gnustep-make version 2 strict mode.
Making all for tool NameOfExcecutable...
clang -ObjC     -fuse-ld=/usr/bin/ld.gold  -pthread -fexceptions -rdynamic -fobjc-runtime=gnustep-2.0 -fblocks  -o obj/NameOfExcecutable 
./obj/NameOfExcecutable.obj/main.m.o ./obj/NameOfExcecutable.obj/MyClass.m.o ./obj/NameOfExcecutable.obj/StreamRunLoop.m.o ./obj/NameOfExcecutable.obj/Connector.m.o ./obj/NameOfExcecutable.obj/HTTPClient.m.o 
-L/home/user/GNUstep/Library/Libraries -L/usr/GNUstep/Local/Library/Libraries -L/usr/GNUstep/System/Library/Libraries     -lgnustep-base -ldispatch -l/path/to/libOwnLib1.a -l/path/to/libOwnLib2.a -l/path/to/libOwnHavingTheCategories.a -l/path/to/libOwnLib4.a -l/path/to/libOwnLib5.a -luuid -lz -lpthread -ldl   -lpthread -lobjc   -lm
clang: warning: argument unused during compilation: '-ObjC' [-Wunused-command-line-argument]

问题:

我做错了什么

或

我该如何解决这个问题?

Answer 1

在深入研究链接器不知道-ObjC标志(我们习惯在Xcode中使用)的问题后，它看起来像:

• 只有ld.ld64知道这个标志
• ld。ld64是macos的"链接器"(名称过于通用)。(来自LLDB.org)
因此
• 不能用于Linux链接器

为了解决这个问题，我们首先停止使用GNUstep的makefiles
禁用所有GNUstep的魔法，了解发生了什么，并编写了我们自己的makefiles

强制link/load所有.o文件的实际修复是显式地将--whole-archive传递给链接器:

-Wl,-whole-archive path/to/static/lib/containing/categories/libOwnLib1.a -Wl,-no-whole-archive