兼具可执行性与共享对象属性的二进制文件创建方案及跨可执行文件函数加载、Java加载可行性问询

先梳理下你遇到的场景：你有两个C文件foo.c和bar.c，单独编译可执行或共享库都能正常工作，但尝试把可执行文件当共享库链接、直接运行共享库时遇到了问题。接下来针对你的三个问题逐一解答：

1. 是否能创建同时具备可执行性与有效共享对象属性的单一文件？ #

答案是可以，利用ELF格式的特性，我们可以编译出一个既是可执行程序、又能作为共享库被链接的文件。

ELF文件的头部有一个e_type字段，通常可执行文件标记为ET_EXEC，共享库标记为ET_DYN，但ET_DYN类型的文件如果指定了入口点，也能被直接执行。编译时通过链接器参数同时指定-shared（生成共享库格式）和-e main（设置入口点为main函数）就能实现：

gcc -shared -fPIC -Wl,-e,main foo.c -o foo_multi.bin

测试这个文件：

• 直接运行：./foo_multi.bin，会输出A1B，和普通可执行文件完全一致；
• 当作共享库链接给bar.c：

  # 可以直接指定文件链接，或者重命名为libfoo_multi.so后用-l参数
  gcc bar.c ./foo_multi.bin -o bar_multi.out
  

  运行bar_multi.out会输出A2B，说明它能正常作为共享库被调用。

不过要注意两个细节：

• 这种双属性文件在部分老系统或严格的链接器环境下可能存在兼容性问题，但Android和现代Linux环境基本都支持；
• 确保你的目标函数（比如Main）是全局可见的，-fPIC已经保证了位置无关性，默认符号会自动导出，无需额外操作。

2. 若无法实现上述需求，是否能用dlopen技巧从bar.out加载foo.out的函数？ #

当然可以！可执行文件本质也是ELF格式，只要它的全局符号被导出，就能用动态加载API打开并提取函数。

具体步骤： #

1. 编译foo.out时，添加-rdynamic参数强制导出所有全局符号：

   gcc -fPIC -rdynamic foo.c -o foo.out
   

2. 修改bar.c，用dlopen系列API加载foo.out里的Main函数：

   #include <stdio.h>
   #include <dlfcn.h>
   
   int main() {
       // 打开foo.out可执行文件
       void* handle = dlopen("./foo.out", RTLD_LAZY);
       if (!handle) {
           fprintf(stderr, "dlopen failed: %s\n", dlerror());
           return 1;
       }
   
       // 获取Main函数的地址
       typedef int (*MainFunc)(int);
       MainFunc main_func = (MainFunc)dlsym(handle, "Main");
       const char* err = dlerror();
       if (err) {
           fprintf(stderr, "dlsym failed: %s\n", err);
           dlclose(handle);
           return 1;
       }
   
       // 调用目标函数
       int ret = main_func(2);
       printf("\n");
       dlclose(handle);
       return ret;
   }
   

3. 编译bar.c时需要链接动态加载库dl：

   gcc bar.c -ldl -o bar_dl.out
   

运行bar_dl.out就能输出A2B，成功从可执行文件中加载并调用了目标函数。

3. 是否可通过Java的System.loadLibrary加载该可执行文件？ #

可以，但需要调整C代码和编译方式，让可执行文件符合JNI共享库的要求（且无需修改Java侧代码）。

核心要求： #

• 文件必须是ET_DYN类型的ELF（即共享库格式），同时保留可执行入口；
• 必须包含JNI_OnLoad函数（Java加载库时会自动调用这个函数完成初始化）；
• 文件命名要符合Java规则：比如libnative.so（对应System.loadLibrary("native")）；
• 代码需要包含Java侧声明的native方法实现（如果是Android GUI应用，还要对应Android的JNI方法签名）。

示例修改： #

修改foo.c，添加JNI相关代码，同时保留原有的可执行逻辑：

#include <stdio.h>
#include <jni.h>

// 原有的业务函数
int Main(int a) { printf("A%dB",a); return 0; }

// 可执行入口，满足Termux运行需求
int main() { return Main(1); }

// JNI初始化函数，Java加载库时自动调用
JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM* vm, void* reserved) {
    JNIEnv* env;
    if ((*vm)->GetEnv(vm, (void**)&env, JNI_VERSION_1_6) != JNI_OK) {
        return JNI_ERR;
    }
    // 这里可以注册Java侧需要的native方法，需匹配Java类的全路径和方法名
    return JNI_VERSION_1_6;
}

// 假设Java侧声明了native方法：public native void callMain(int a);
JNIEXPORT void JNICALL Java_com_example_MyActivity_callMain(JNIEnv* env, jobject thiz, jint a) {
    Main(a);
}

编译成兼具可执行性和共享库属性的文件：

gcc -shared -fPIC -Wl,-e,main foo.c -o libnative.so

这样操作后：

• 直接运行./libnative.so会输出A1B，满足Termux环境下的运行需求；
• 把它放到Android项目对应ABI的目录下，Java侧调用System.loadLibrary("native")就能成功加载，并且可以通过callMain方法触发Main函数，满足Android GUI应用的需求。

注意：Android平台需要确保编译的ABI（比如arm64-v8a、armeabi-v7a）与目标设备匹配，可通过交叉编译工具链的-target参数指定。

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