将可执行文件与 dylib 链接时，是install_name_tool使 dylib 路径相对于可执行文件的唯一方法，还是在 clang 的链接步骤中可以这样做？
鉴于以下项目结构：
- Project Root
| compile.sh
- lib_src
| myprint.cpp
| myprint.h
- main_src
| main.cpp
使用这些文件：https://gist.github.com/JohannesMP/8fa140b60b8ffeb2cae0
运行compile.sh（为了简单起见，在这里使用而不是 make 文件）会产生以下文件：
- Project Root
| main (a unix executable linked to myprint.dylib)
| myprint.dylib (a dynamic library that main uses)
./main在项目中使用while 'd运行程序cd工作正常，但尝试从其他任何地方运行它（例如通过简单地双击它）将导致以下错误：
dyld: Library not loaded: myprint.dylib
Referenced from: /Users/Jo/Sandbox/libtest/main
Reason: image not found
Trace/BPT trap: 5
当使用检查 main 时，otool我可以看到这是因为 myprint.dylib 的路径没有根据可执行文件定义： …
我目前正在与 clang++ 作斗争，在网上查看了很长时间后，我决定提出我的问题。我在 OS X 上并通过 Emacs 使用 clang++ （flycheck 使用它来突出显示错误等）。我有一个非常简单的文件，以以下内容开头：
#include <iostream>
该线用红色下划线表示。当我检查 clang 日志时，这就是我所拥有的：
In file included from ./point.hpp:4:
In file included from /usr/local/Cellar/llvm/3.6.2/bin/../include/c++/v1/iostream:37:
/usr/local/Cellar/llvm/3.6.2/bin/../include/c++/v1/__config:23:10: fatal error: 'unistd.h' file not found
#include <unistd.h>
所以，错误来自于iostreaminclude，并且其中iostream有一个#include <unistd.h>clang++ 不喜欢的。
我会立即说，我已经安装了 Xcode 和命令行工具。所以我的unistd.h应该在那里。我的代码也可以编译（通过 g++），所以一切都很好。只是 clang++ 丢失了。
我注意到它会进入我的 llvm 文件夹（我用自制程序安装的）来 fetch iostream，这似乎不对。他应该会进入iostream我的系统，对吗？所以/usr/local/include/c++/iostream。这可能是问题所在吗？如果是这样，我怎样才能告诉它得到正确的结果iostream？
如果这不是问题，我该如何解决我的unistd.h问题？
提前致谢 ！
编辑：通过clang++ -stdlib=libc++ image.cpp命令，我得到这个：
clang++ -stdlib=libc++ image.cpp
In file …-fmodules当使用下面所示的命令进行编译时，以下简单的测试用例文件给了我一个编译时错误，提示来自 Clang 的 github 镜像的“master” 。我想知道这是否是 Clang 的新实验性模块功能的一个错误——可能是标准库模块映射的实现问题——或者我是否做错了什么。-fbuiltin-module-map如果我添加到命令中，错误仍然出现。stdint.h有趣的是，如果我替换为 ，该错误就不再出现cstdint。
#include <stdint.h>
uint64_t foo;
这是我的编译命令，带有错误消息：
anhall@leviathan: /Users/anhall/impersonal/code/llvm-reflexpr/install/bin/clang++ -o module-uint64_t-test.o -c module-uint64_t-test.cpp --std=c++1z -fmodules
module-uint64_t-test.cpp:3:1: error: missing '#include <_types/_uint64_t.h>'; declaration of 'uint64_t' must be imported from module 'Darwin.POSIX._types._uint64_t' before it is
required
uint64_t foo;
^
/usr/include/_types/_uint64_t.h:31:28: note: previous declaration is here
typedef unsigned long long uint64_t;
有关我正在使用的构建的信息：它来自 Matus Chochlik 的 github Clang 镜像的分支；但我设置为与原始 clang git 镜像中“master”的（当时）头相对应的提交（换句话说，它不包括来自 Matus Chochlik 的功能“reflexpr”分支的提交）：
anhall@leviathan: /Users/anhall/impersonal/code/llvm-reflexpr/install/bin/clang++ -v
clang version 4.0.0 …在 Linux (CentOS) 上，我偶尔会-Wl,--unresolved-symbols=ignore-in-object-files在构建仅依赖于某些对象文件的一部分的测试应用程序时使用，即使完整的依赖关系需要包含更多的对象文件。关键是，我知道在设计上，运行测试应用程序时永远不会遇到任何未解析的符号（否则它应该崩溃）。
在 OS X 上，我发现类似的选项-Wl,-undefined,suppress (or warning, dynamic_lookup),-flat_namespace允许我构建二进制文件，但它在运行时失败，抱怨dyld: Symbol not found: ...即使在运行期间从未使用丢失的符号（相同的应用程序在 CentOS 上运行得很好）。
是否还有其他方法可以像在 Linux 上一样强制应用程序运行（直到遇到未解析的符号时崩溃）？
我正在Eli Bendersky的这篇信息丰富（但有点过时）的教程的帮助下学习使用 Python + libclang 解析 C++ 文件。
我的目标是解析 C++ 文件并识别这些文件中存在的函数的函数边界。我期望建立一个这种形式的Python字典：
{<func_name>:(<func_start_loc>, <func_end_loc>), ...}
为此，我能够获取函数名称（用于cursor.spellingAST 节点CursorKind.FUNCTION_DECL）CursorKind.CXX_METHOD和起始位置（使用cursor.location）
我的问题是，如何获得函数位置的结束位置
我注意到 Clang 在以下场景中的一些独特行为：
有一个类foo包含一个私有成员函数模板function_template。foo 还将非嵌套结构bar声明为友元：
struct bar;
class foo {
friend struct ::bar;
template<typename T> void function_template() {}
};
在 bar 内部声明了成员别名模板类型，该类型引用 foo 的成员函数模板的返回类型，如下所示：
struct bar {
template<typename T> using type = decltype(foo().function_template<T>());
}
使用 clang，编译器无法实例化任何模板参数的公共别名模板 bar::type：
#include <typeinfo>
#include <iostream>
int main {
std::cout << typeid(bar::type<int>).name() << std::endl;
// error : 'function_template' is a private member of 'foo'
}
这种行为符合标准吗？MSVC 和 GCC 都执行此实例化。Clang 还执行引用友元类的私有成员的其他别名模板的实例化。
我对别名模板行为的扩展测试可以在这里找到： https://ideone.com/cdB5lZ
我想将回调块从 Objective-C++ 代码传递到 C++ 对象。这非常简单，因为我可以将一个块分配给 std::function。在我的迷你示例中，一切正常，但我仍然不确定这样做是否安全。
#import "ViewController.h"
#include <functional>
std::function<void(void)> f;
@interface T : NSObject
@property (strong) NSString* value;
@end
@implementation T
- (void)dealloc {
NSLog(@"dealloc");
}
@end
@implementation ViewController
- (IBAction)storeBlock:(UIButton *)sender {
T* t = [[T alloc] init];
t.value = @"the captured obj";
f = ^void(void) { NSLog(@"This is the block with %@", t.value); };
}
- (IBAction)useBlock:(UIButton *)sender {
f();
}
- (IBAction)releaseBlock:(UIButton *)sender {
f = nullptr;
}
@end
我了解到这些块存储在堆栈上，如果我想在块创建的范围之外使用它，我必须将其复制到堆（我在示例中没有明确这样做）。我也不确定 ARC 如何处理这种情况。“官方”允许这样做吗？我正在使用 Xcode 9.2。
我正在使用libFuzzer来模糊 API。
该 API 反序列化位数组（由 libFuzzer 提供）
并将它们转换为 C++ 类实例化。
由于序列化格式，libFuzer 能够构造一个序列化对象，告诉反序列化器保留大量数据（这是无法满足的）。
这是通过调用 来完成的std::vector::resize()。向量抛出std::bad_alloc，尽管问题已被捕获并安全缓解，但它会导致模糊器极度滞后（如以下有关OOM 问题的文档中所述）。
为了降低模糊器运行时使用的内存量，我希望设置ulimit -v和调整进程的可用虚拟内存。然而这样做会导致
==27609==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504) bytes at address 2008fff7000 (errno: 12)
==27609==ReserveShadowMemoryRange failed while trying to map 0xdfff0001000 bytes. Perhaps you're using ulimit -v
为什么地址清理程序不能在 ulmit -v 下工作？
我希望可以，这样我就可以更有效地进行模糊测试。
其他信息：
我的构建标志是：
copts = [
"-fsanitize=address,fuzzer",
"-fsanitize-trap=undefined,integer",
"-fsanitize-coverage=trace-pc,trace-cmp,trace-pc-guard",
"-g",
"-O0",
"-fno-omit-frame-pointer",
"-fno-sanitize=vptr",
],
linkopts = [
"-fsanitize=address,fuzzer",
"-fsanitize-trap=undefined,integer",
"-fno-sanitize=vptr",
"-fsanitize-link-c++-runtime",
],
我尝试关闭标志，以便我可以设置 …
# 1 "donothing.cpp" 2编译器是否使用 C 预处理器输出中的linemarkers( ) 来生成汇编器 (.s) 文件？
我希望它们用于产生编译器错误和调试信息。-P那么我可以在尝试遵循宏流程时安全地关闭这些（使用）吗？
我正在学习 C++ 和 C 预处理器。我在许多 C++ 教程中读到，宏通常很难正确编写，并且可能会产生意想不到的结果。这是预处理器输出的示例。C 预处理器：预处理器输出
$ g++ -Wall -std=c++11 -E donothing.cpp
# 1 "donothing.cpp"
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 391 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "donothing.cpp" 2
int main()
{
return 0;
}
$ g++ -Wall -std=c++11 -E donothing.cpp -P
int main()
{
return 0;
}
查看预处理器输出是调试编译器错误的方法吗？c/c++ 开发人员还如何调试他们的宏（因为我预计人们会非常频繁地使用多个 .cpp 文件，并且总是存在编译器错误）？
我正在尝试将我的项目配置为使用 LLVM/clang++ 构建，但始终选择 GCC：
$ /opt/llvm/clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-18.04/bin/clang++ --version
clang version 7.0.1 (tags/RELEASE_701/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/llvm/clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-18.04/bin
$
$ CC=/opt/llvm/clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-18.04/bin/clang++ meson ~/build
The Meson build system
Version: 0.49.1
Source dir: ~/source
Build dir: ~/build
Build type: native build
Project name: test
Project version: 0.1.0
Native C++ compiler: ccache c++ (gcc 6.3.0 "c++ (Debian 6.3.0-18+deb9u1) 6.3.0 20170516")
Build machine cpu family: x86_64
Build machine cpu: x86_64
Message: Compiler: GCC
Dependency threads found: YES
Build targets in project: 2
Found ninja-1.8.2 …