为什么g ++仍然需要-latomic [英] Why does g++ still require -latomic
问题描述
在C ++标准2014年11月的工作草案的 29.5原子类型中，它指出：
In 29.5 Atomic types of the C++ Standard November 2014 working draft it states:
- 有一个通用类模板原子。模板参数T的类型应该是可复制的（3.9）。 [注意：不能静态初始化的类型参数可能很难使用。 - end note]
So - as far as I can tell - this:
#include <atomic>
struct Message {
unsigned long int a;
unsigned long int b;
};
std::atomic<Message> sharedState;
int main() {
Message tmp{1,2};
sharedState.store(tmp);
Message tmp2=sharedState.load();
}
应该是完全有效的标准c ++ 14（以及c ++ 11 ）代码。但是，如果我不手动链接 libatomic ，请使用命令
should be perfectly valid standard c++14 (and also c++11) code. However, if I don't link libatomic manually, the command
g++ -std=c++14 <filename>
至少在Fedora 22（gcc 5.1）上出现以下链接错误：
gives - at least on Fedora 22 (gcc 5.1) - the following linking error:
/tmp/ccdiWWQi.o: In function `std::atomic<Message>::store(Message, std::memory_order)':
main.cpp:(.text._ZNSt6atomicI7MessageE5storeES0_St12memory_order[_ZNSt6atomicI7MessageE5storeES0_St12memory_order]+0x3f): undefined reference to `__atomic_store_16'
/tmp/ccdiWWQi.o: In function `std::atomic<Message>::load(std::memory_order) const':
main.cpp:(.text._ZNKSt6atomicI7MessageE4loadESt12memory_order[_ZNKSt6atomicI7MessageE4loadESt12memory_order]+0x1c): undefined reference to `__atomic_load_16'
collect2: error: ld returned 1 exit status
如果我写
g++ -std=c++14 -latomic <filename>
一切正常。
我知道，标准不说的编译器标志，或者必须包括库什么，但到目前为止，我认为，任何标准的一致性，单个文件的代码可以通过第一个命令编译。
everything is fine. I know that the standard doesn't say anything about compiler flags or libraries that have to be included, but so far I thought that any standard conformant, single file code can be compiled via the first command.
那么为什么不适用于我的示例代码？是否有一个合理的，为什么 -latomic 仍然是必要的，或者是它只是一些没有被编译维护者解决，但？
So why doesn't that apply to my example code? Is there a rational why -latomic is still necessary, or is it just something that hasn't been addressed by the compiler maintainers, yet?
推荐答案
相关阅读对GCC如何以及为什么不对<库调用在某些情况下，海湾合作委员会的主页;原子方式> 首先
Relevant reading on the GCC homepage on how and why GCC makes library calls in certain cases regarding <atomic> in the first place.
GCC和libstdc ++只是失去耦合。 libatomic 是图书馆的领域，而不是编译器 - 你可以用不同的库使用GCC（可能为<提供必要的定义;原子> 在其主要的正确，或以不同的名称），所以GCC不能仅仅假设的 -latomic 。
GCC and libstdc++ are only losely coupled. libatomic is the domain of the library, not the compiler -- and you can use GCC with a different library (which might provide the necessary definitions for <atomic> in its main proper, or under a different name), so GCC cannot just assume -latomic.
另外：
GCC 4.7不包含库实现，因为API尚未稳固建立。
GCC 4.7 does not include a library implementation as the API has not been firmly established.
同一页面声称GCC 4.8应提供这样的图书馆实施，但计划是战争的第一受害者。我猜想 -latomic 仍然需要的原因可以在附近找到。
The same page claims that GCC 4.8 shall provide such a library implementation, but plans are the first victims of war. I'd guess the reason for -latomic still being necessary can be found in that vicinity.
。
...到目前为止，我认为任何标准一致的单个文件代码都可以通过第一个命令进行编译。
...so far I thought that any standard conformant, single file code can be compiled via the first command.
... -lm 已经存在了一段时间，如果你使用数学
...-lm has been around for quite some time if you're using math functions.
这篇关于为什么g ++仍然需要-latomic的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
