Linux,Mono,共享库和未解析的符号 [英] Linux, Mono, shared libs and unresolved symbols

查看:115
本文介绍了Linux,Mono,共享库和未解析的符号的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个垫片库(共享的C ++),该垫片库调用另一个共享库(libexif)中的函数,并为C#提供了一个简单的接口,用于Platform Invoke调用. (也就是说,C#程序使用PInvoke调用我的自定义共享库,而该共享库又调用另一个共享库.)

I have a shim library (shared, C++) which calls functions in another shared library (libexif) and presents a simple interface to C# for Platform Invoke calls. (That is, a C# program uses PInvoke to call my custom shared library which in turn calls another shared library.)

在Windows中,当我的自定义共享库链接和C#应用程序执行时,我的自定义共享库链接到共享库.

In Windows, my custom shared library links to the shared library when my custom library links and when the C# application executes, all symbols are resolved.

在Linux上,链接我的共享库不会链接其他共享库.使用C ++驱动程序,当链接 application 时,我指定了另一个库,这时所有符号都被解析了.但是,当我尝试从C#程序(使用mono编译)调用共享库时,其他共享库中的符号无法解析.我尝试使用MONO_PATH变量指定其他库,但似乎没有什么不同.我也尝试过在DLLimport语句中指定未解析的函数,但这似乎也无济于事.

On Linux, linking my shared library does not link the other shared library. With a C++ driver, I specify the other library when the application is linked and at that time, all symbols are resolved. However, when I try to call my shared library from a C# program (compiled using mono) symbols in the other shared library are not resolved. I've tried using the MONO_PATH variable to specify the other library but it seems not to make a difference. I've also tried specifying the unresolved function in a DLLimport statement, but that seems not to help either.

如何指定一个不被C#代码直接调用的共享库,以便mono/cli在运行时找到它?

How can I specify a shared library that is not directly called by C# code so that mono/cli finds it at run time?

我使用以下命令来构建共享库:

I use the following commands to build the shared library:

g++ -fPIC -g -c -Wall  libexif-wrapper.cpp
g++ -shared -Wl,-soname,libexif-wrapper.so.1     -o libexif-wrapper.so.1.0.1 libexif-wrapper.o -lc
ar rcs libexif-wrapper.a libexif-wrapper.so.1

以及以下命令行来编译我的C#驱动程序:

And the following command line to compile my C# driver:

mcs -unsafe -define:LINUX Test-libexif-wrapper.cs

在执行时,我收到一个错误,指出找不到共享库使用的符号:

On execution I get an error that a symbol used by my shared library is not found:

/usr/bin/cli: symbol lookup error: ../../../C/libexif-wrapper/libexif-wrapper/libexif-wrapper.so.1: undefined symbol: exif_data_new_from_file

(libexif-wrapper是我的共享库,它充当C#应用程序和libexif之间的垫片.)

(libexif-wrapper is my shared library which serves as a shim between the C# application and libexif.)

我一直无法弄清楚该如何解决.任何建议,将不胜感激.

I have not been able to figure out how to solve this. Any suggestions would be appreciated.

要回答这个问题:

您确定未托管 libexif-wrapper可以在 LD_LIBRARY_PATH环境变量?

Are you sure that the unmanaged libexif-wrapper can be found in the LD_LIBRARY_PATH environment variable?

实际上不是.我在DLLImport中精心设计了路径以直接指向它.运行时找到它,因为它在上面的错误消息中报告了它的路径.此外,C#程序不会调用缺少的符号,而是共享库中的函数之一调用了后来找不到的函数. (谢谢-谢谢)

In fact it is not. I have crafted the path in the DLLImport to point directly to it instead. The run time finds it because it reports the path to it in the error message above. Further the missing symbol is not called by the C# program but rather one of the functions in my shared library calls the function that is then not found. (thanks - hank)

推荐答案

在链接包装库之类的文件时应指定依赖项

You should specify the dependency when you link the wrapper library like

g++ -shared -Wl,-soname,libexif-wrapper.so.1 -o libexif-wrapper.so.1.0.1 libexif-wrapper.o -lc -lexif

执行此操作时,动态链接程序会知道libexif-wrapper依赖于libexif,并且可以解析加载时的符号.

When you do that the dynamic linker knows that libexif-wrapper depends on libexif and it can resolve the symbols on load.

这篇关于Linux,Mono,共享库和未解析的符号的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆