Linux C ++错误：未定义对“ dlopen”的引用

我使用C ++（Eclipse）在Linux中工作，并且想要使用一个库。Eclipse向我显示了一个错误：

undefined reference to 'dlopen' 

你知道解决方案吗？

这是我的代码：

#include <stdlib.h>
#include <stdio.h>
#include <dlfcn.h>

int main(int argc, char **argv) {
    void *handle;
    double (*desk)(char*);
    char *error;

    handle = dlopen ("/lib/CEDD_LIB.so.6", RTLD_LAZY);
    if (!handle) {
        fputs (dlerror(), stderr);
        exit(1);
    }

    desk= dlsym(handle, "Apply");

    if ((error = dlerror()) != NULL)  {
        fputs(error, stderr);
        exit(1);
    }

    dlclose(handle);
}

您必须针对libdl进行链接，添加

-ldl

到您的链接器选项

@Masci是正确的，但是如果您使用的是C（和gcc编译器），请考虑到这是行不通的：

gcc -ldl dlopentest.c

但这确实是：

gcc dlopentest.c -ldl

花了我一点时间来找出...

主题很老，但是今天我在编译cegui 0.7.1（openVibe先决条件）时遇到了同样的问题。

对我有用的是设置：LDFLAGS="-Wl,--no-as-needed" 在Makefile中。

我也曾尝试-ldl过LDFLAGS但无济于事。

这不起作用：

gcc -ldl dlopentest.c

但这确实是：

gcc dlopentest.c -ldl

那肯定是一个令人讨厌的“功能”

在编写Heredoc语法时，我一直在努力，发现了一些有趣的事实。使用CC=Clang，这有效：

$CC -ldl -x c -o app.exe - << EOF
#include <dlfcn.h>
#include <stdio.h>
int main(void)
{
  if(dlopen("libc.so.6", RTLD_LAZY | RTLD_GLOBAL))
    printf("libc.so.6 loading succeeded\n");
  else
    printf("libc.so.6 loading failed\n");
  return 0;
}
EOF

./app.exe

以及所有这些：

• $CC -ldl -x c -o app.exe - << EOF
• $CC -x c -ldl -o app.exe - << EOF
• $CC -x c -o app.exe -ldl - << EOF
• $CC -x c -o app.exe - -ldl << EOF

但是，使用时CC=gcc，只有最后一个变体有效；-ldl之后-（stdin参数符号）。

您可以尝试添加此

LIBS=-ldl CFLAGS=-fno-strict-aliasing

到配置选项

我使用CMake编译项目时，发现了相同的问题。

此处描述的解决方案就像一个超级按钮一样工作，只需将$ {CMAKE_DL_LIBS}添加到target_link_libraries（）调用中

您需要为makefile做这样的事情：

LDFLAGS='-ldl'
make install

这会将链接器标志从make传递到链接器。生成文件是自动生成的都没关系。

我什至遇到了同样的问题 -ldl。

除了该选项之外，还需要将源文件放置在库之前，请参见对dlopen的未定义引用。

为了使用dl函数，您需要对链接器使用-ldl标志。

如何在日食中做到？

按项目 -> 属性 -> C / C ++构建 -> 设置 -> GCC C ++链接器 ->
库 ->在“库（-l）”框中，按“ +”号 ->编写“ dl ”（不带引号）->按OK- >清理并重建项目。

 $gcc -o program program.c -l <library_to_resolve_program.c's_unresolved_symbols>

很好地说明了为什么-l dl的位置很重要

但是在$ man gcc的文档中也有一个非常简洁的解释

   -llibrary
   -l library
       Search the library named library when linking.  (The second
       alternative with the library as a separate argument is only for POSIX
       compliance and is not recommended.)

       It makes a difference where in the command you write this option; the
       linker searches and processes libraries and object files in the order
       they are specified.  Thus, foo.o -lz bar.o searches library z after
       file foo.o but before bar.o.  If bar.o refers to functions in z,
       those functions may not be loaded.