在使用C ++在Linux中构build模块时遇到了一个棘手的“未定义引用”错误。 我将在高层描述它，并在必要时发布代码（这是专有的，所以发布它需要更改一些名称）。 一些细节： 模块A（一个库）有一个类，我们将称之为Bar的方法称为Foo。 模块A构build得很好，使用nm来查看目标文件显示构造函数和Bar都被定义（它们显示为“T”）。 模块B（一个库）包含一个使用模块A的类，引用了Foo :: Foo，Foo ::〜Foo和Foo :: Bar。 它的makefile包括-L / path / to / Foo和-lFoo。 这个模块也构build得很好。 但是，当我在模块B的目标文件上运行nm时，对模块Foo :: Foo，Foo ::〜Foo和Foo :: Bar的调用未定义（它们显示为“U”）。 为什么它构build超越了我。 模块C–其输出是一个可执行文件 – 包含对模块B的引用。当我尝试构build模块C时，它向我叫喊从模块B到模块A的Foo和Bar方法的未定义引用。 为什么模块B构build如果引用是不确定的？ 为什么错误只有在我们进入模块C时才报告？ 编辑： 我应该提到模块C的makefile也有-L / path / to / Foo和-lFoo，但仍然失败。 任何我应该尝试的任何高级猜测？ 我有一种感觉，我将不得不张贴一些代码…
我可以使用dlopen（）和RTLD_NOW来延迟加载共享库。 但是，一旦库dynamic加载，仍然需要使用dlsym来单独加载每个符号。 由于我的库包含大量的API，所以我不想为它们调用dlsym。 有没有办法使API的工作方式与正常的加载时间链接相同（只需调用API而不需要dlsym）？
所以testing平台在Linux 32位上。 我用这个方法使用gcc生成一个quickSort的obj文件： gcc -S quickSort.c 生成的quickSort.o是一个可重定位的ELF： #file quickSort.o quickSort.o：ELF 32位LSB可重新定位，英特尔80386，版本1（SYSV），未剥离 然后我使用objdump来拆卸它： objdump -d quickSort.o 并查看生成的asm文件，我对此感到困惑： 51: b8 00 00 00 00 mov $0x0,%eax 56: 89 04 24 mov %eax,(%esp) 59: e8 fc ff ff ff call 5a <main+0x5a> 5e: c7 44 24 3c 00 00 00 movl $0x0,0x3c(%esp) 上面的代码是调用printf函数并打印出一个string，如果我编译quicksort.c到quicksort.s，它应该是这样的： movl $.LC0, %eax movl %eax, […]
我想在我的应用程序中有代码覆盖，所以在premake.lua我添加了以下内容： if options["coverage"] then tinsert(package.buildoptions, {"-fprofile-arcs", "-ftest-coverage"}) tinsert(package.links, "gcov") end 然后我运行以下命令： premake –coverage –target gnu ; make 这不工作，直到我join以下内容： if options["coverage"] then tinsert(package.buildoptions, {"-fprofile-arcs", "-ftest-coverage"}) tinsert(package.linkoptions, {"-fprofile-arcs"}) tinsert(package.links, "gcov") end 这是互联网上提出的一个解决scheme。 我的问题是，我发现这个-fprofile-arcs链接器标志0文档…它是做什么的？ 它在哪里logging？
我想将/opt/vertica/lib64到系统库path中，所以我执行以下步骤： （1）将/opt/vertica/lib64到/etc/ld.so.conf ，并运行ldconfig ， （2）检查： bash# ldconfig -p | grep vertica libverticaodbc.so (libc6,x86-64) => /opt/vertica/lib64/libverticaodbc.so …… 但是当我运行“ ld -lverticaodbc –verbose ”命令时： ================================================== attempt to open /usr/x86_64-redhat-linux/lib64/libverticaodbc.so failed attempt to open /usr/x86_64-redhat-linux/lib64/libverticaodbc.a failed attempt to open /usr/local/lib64/libverticaodbc.so failed attempt to open /usr/local/lib64/libverticaodbc.a failed attempt to open /lib64/libverticaodbc.so failed attempt to open /lib64/libverticaodbc.a failed attempt to open […]
我在Linux上看到了一个奇怪的链接问题，它使用了一个跨平台的库项目，它使用CMake从同一个源码树创build一个OS X Framework和一个Linux共享库。 该项目的跨平台方面在过去（两年前左右）运行良好，但从那以后，我们专门在OS X上进行了开发工作。暂时放弃Linux的原因是开发人员短缺：所有那些仍然使用OS X的人 – 没有任何技术上的原因，在Linux上build立多年的源码。 有一个潜在的相关例外（稍后会有更多的例外），同时我们的来源也没有根本性的变化。 当然，Linux已经进步了，当然，当我们回到那里的时候，当然也有一些小的障碍。 像新版本的编译器抱怨过去没有抱怨过的事情（可疑的转换，void Voodoo等等）。 这些问题在短期内得到解决。 整个源代码树现在在Mint 17.1上再次编译，并带有一些绝对无害的剩余警告。 但是，连接失败了一个相当奇怪的信息： Linking CXX shared library lib<ourLibName>.so CMakeFiles/<file1>.co:1:1: error: stray '\177' in program CMakeFiles/<file1>.co:1:1: error: stray '\2' in program CMakeFiles/<file2>.co:1:1: error: stray '\213' in program (and so on, thousands of times, with seemingly random values in the quotes for all the […]
从我收集的信息中可以看出，共享库的默认可见性符号的符号名称查找以呼吸优先的顺序遍历共享库依赖关系树，可执行程序是此search树的根。 所有由一个DT_NEEDED列表链接的库都在这个树的同一层。 因此，当查找符号“foo”时，在我看来，它的查找总是在运行时被绑定到相同的库或可执行文件。 dynamic链接器是否利用这个function，并且有一个“全局符号表”（可能与链接映射表有关），它知道什么符号属于什么共享库，一旦符号第一次被查找，并把地址符号被另一个共享库第二次查找的时候，那个库中的符号出现了吗？ 或者将这个符号永远抬头，好像这是第一次查找？
我试图使用一个名为krpc的库。 它按照说明与cmake一起安装。 https://krpc.github.io/krpc/cpp/client.html#using-the-library 这是testing程序： #include <iostream> #include <krpc.hpp> #include <krpc/services/krpc.hpp> int main() { krpc::Client conn = krpc::connect(); krpc::services::KRPC krpc(&conn); std::cout << "Connected to kRPC server version " << krpc.get_status().version() << std::endl; } 编译： g++ main.cpp -std=c++11 -lkrpc -lprotobuf ldd返回:(find其他库） ldd a.out libkrpc-0.3.7.so => not found 该库从./krpc-cpp-0.3.7安装，其中包含libkrpc.so.0.3.7。 我该如何正确安装库？ 我试着改变.so的名字。 并使软链接到/ ust / lib。 然后重新运行ldconfig。
我正在构build一个依赖于静态库A的可执行文件，该静态库又依赖于静态库B.当我构build我的应用程序时，是否还需要在构build脚本中链接到B？ 更具体地说，我需要做-la -lb ，还是只需要通过-la连接就足够了？
我一直在试图将一个项目从Xcode移到Linux（现在是Ubuntu x86，但是希望静态链接的可执行文件可以在x86 CentOS机器上运行？我希望我希望？）。 我有整个项目编译，但它在链接阶段失败 – 它给我所有由IPP定义的函数的未定义的引用。 这可能是一个非常小而愚蠢的事情，但是现在我已经打了几天头了，而我却无法完成它的工作。 这里是编译语句（我也有一个生成相同的错误的生成文件）： g ++ -static /opt/intel/ipp/6.0.1.071/ia32/lib/libippiemerged.a /opt/intel/ipp/6.0.1.071/ia32/lib/libippimerged.a /opt/intel/ipp/6.0.1.071/ ia32 / lib / libippsemerged.a /opt/intel/ipp/6.0.1.071/ia32/lib/libippsmerged.a /opt/intel/ipp/6.0.1.071/ia32/lib/libippcore.a -pthread -I / opt / intel / ipp / 6.0.1.071 / ia32 / include -I tools / include -o main main.cpp pick_peak.cpp get_starting_segments.cpp get_segment_timing_differences.cpp recast_and_normalize_wave_file.cpp rhythm_score.cpp pitch_score.cpp pitch_curve.cpp tools / source / LocalBuffer.cpp tools […]