问题标签 [gcc5]

我有一个大型项目，其中包含构建所有内容的自定义 Makefile。这是针对 ARM Cortex-M0 的。

其中一个步骤是将 Newlib 编译syscalls.c成syscalls.c.o. 这被转储到一个存档文件newlib.a中，该文件又链接到最终output.elf加载到我设备的闪存上。

如果我按照上述程序，有时“存档没有索引”：

有时（我还没有弄清楚如何确定性地使其中一种发生）我得到一个未定义的引用，即使_init()在syscalls.c.

但是，如果我跳过newlib.a文件并直接链接syscalls.c.o到 final .elf，它会按预期工作。

使用存档可能会导致此问题怎么办？我也尝试重新排序链接器的参数无济于事。

注意（编辑）

我确实注意到了run ranlib to add one指示。但是，这并不适用，因为：

1. 这在我正在构建的其他档案中不是必需的，为什么这里需要它？
2. 该错误不再发生（经过一番摆弄。不确定发生了什么变化）。主要问题是_init未定义。

参考

1. 我正在编译此版本中的其他存档文件，没有任何问题。这里的独特之处在于该存档中只有一个文件，并且它是唯一的仅 C 存档。但是，我不明白这会如何影响事情。

2. 这基本上是我编译syscalls.c和归档.o文件的方式：

   /li>

3. gcc版本

   /li>

4. 简化syscalls.c

   /li>

我的 Dockerfile 使用FROM gcc:5、运行 apt-get update 并通过wget. 我的顶级CMakeLists.txt有set(CMAKE_CXX_STANDARD 11)，但这似乎并不能说服 gcc 使用 C++11 进行编译，因为我收到以下错误：

我尝试添加 with 等的变体set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")，libstdc++但gnuc++11编译器无法识别它们。我也试add_compile_options(-std=c++11)了也没用。我也试过 apt-get upgrade gcc 但这也没有帮助。

我在这里想念什么？

我正在尝试使用boost::thread::try_join_for()函数，但出现以下编译时错误：

“'class boost::thread' 没有名为 'try_join_for' 的成员

我能够使用boost::thread::timed_join()功能。但我不想使用此功能，因为此功能已被弃用。

我目前的升压版本是 1.66.0。之前我有1.61.0，我想可能有bug，所以我更新到1.66.0。但仍然是同样的问题。

我还查看了头文件<boost/thread/detail/thread.hpp>。也许看起来宏BOOST_THREAD_USES_CHRONO没有定义。虽然，我的 IDE (QT) 能够检测到宏已定义，因为如果我将其更改为，#if !defined BOOST_THREAD_USES_CHRONO那么后面的块代码就会褪色。

我的构建命令如下：

./bootstrap.sh --with-toolset=gcc

./bjam -d0 -a 工具集=gcc-自定义地址模型=64 架构=x86 指令集=nocona 变体=释放线程=多链接=静态阶段

我什至可以在构建输出中看到正在构建 chrono 组件。以下是部分输出：

我错过了什么吗？我正在 Linux 上构建。我的编译器版本是 gcc-5.4。

谢谢。

我的 Linux 发行版将我的 GCC 版本升级到了 5.5.0（如果我知道为什么，那该死的）。现在，当我尝试构建包含 的代码时avx512fintrin.h，会出现大量编译器错误：

等等。为什么会发生这种情况，有没有办法（希望不是太特定于发行版）来解决或规避这个问题？

PS - 如果重要，我使用 GNU/Linux Mint 18.3。

我在我的库中使用主题观察者模式的奇怪重复模板模式取得了很好的成功。我使用 gcc 和 Visual Studio 2017 进行编译。这段代码已经在 Windows 和 Linux 机器上使用了几个月。

最近，我决定重构。将 CRTP Subject Observer 移至最小模板，然后将 CUDA 特定部分移至派生类。像这样：

SubjectObserver.hpp:

和 CudaSubjectObserver.hpp：

使用 Visual Studio 2017，可以很好地构建。使用 gcc 5.4.0，我在 CudaObserver 中获得了对 Observer 成员变量和方法的“未定义引用”。喜欢：

通过在 CudaObserver 中明确指定可以很容易地修复它：

但我想更好地了解造成这种情况的原因。显然，如果我通过 -fpermissive 标志，隐式形式会建立吗？这是不好的做法吗？因为我确实欣赏较短的隐式形式。它更容易阅读。

我需要构建一个可移植的共享对象，它是 Linux 上另一个软件的插件。我对该主题进行了一些阅读，得出的结论是，我应该使用相当旧的 glibc（以提供与旧系统的兼容性）构建一个 sysrooted gcc（如果重要，则为 gcc 5.4.0），链接-static-libstdc++并-static-libgcc因此到了一个地步，我有一些东西只取决于主机glibc和其他一些永远存在的小东西。

现在，我做了所有这些，现在我遇到了一个奇怪的崩溃 - 分段错误发生在代码调用的地方std::thread，而 gdb 实际上显示堆栈帧在里面libstdc++.so.6（不应该在哪里，ldd我的共享对象也有不列出libstdc++.so）。崩溃时的堆栈顶部是：

所以，我做了一些阅读，然后使用nm发现我的共享对象具有所有的std::thread东西，如 ctor、dtor、swap、.... 定义为弱符号（如果加载插件的主机使用动态符号，我假设这会导致冲突libstdc++然后我的电话被路由到那里，所有的地狱都松了，对吗？）。

我对谷歌搜索和阅读的进一步尝试并没有给我一个答案，我该如何控制它，因为强制将std::thread这些东西解析为libstdc++我的 sysrooted gcc 中的静态内容？

此外，我制作了一个小型可执行文件，它只dlopen在我的共享对象上执行，然后调用一个内部构造线程的方法 - 如果可执行文件也是用-static-libstdc++一切正常构建的，如果没有，就会发生崩溃。所以我假设我关于std::thread解析给主机的弱符号的理论libstdc++是正确的，但是如何解决这个问题呢？

我需要扩展std::basic_string以处理路径字符串和不同的operator+：

在https://godbolt.org/z/jhcWoh我有这些错误：

x86 MSVC 19 2015 U3：

x86-64 gcc 5.4（带--std=c++11）：

我知道至少有一种解决方法。

但到底发生了什么？荒谬的是，我还必须再次超载以避免超载碰撞混乱？

更新：通过从所有的所有类型的参数中删除const和修复。似乎可以解决。single referencebasic_stringoperator+

上一个问题：std::string 类继承和繁琐的 c++ 重载解析

在上一个问题之后的步骤中，我尝试测试operator+原始字符串指针："aaa" + path_string{ "bbb" }. 并发现它没有调用相应的path_string类友函数。

我试图添加不模板重载operator+ (2)，但它也没有工作。但我发现模板化的(3)确实有效。

3 个编译器的输出：gcc 5.4、clang 3.8.0、msvc 2015 (19.00.23506)

-333/bbb-

https://rextester.com/BOFUS59590

正如我所记得的，C++ 标准澄清了这一点，因为只有当没有一个非模板化函数与参数完全匹配时，才需要查找模板化函数。但是(2)操作符必须完全匹配，但是为什么它甚至没有被调用呢？

如果 remove(3)则将(1)调用而不是(2)which is match than (1)。

这里发生了什么？

PS：我认为这与上一个问题中的const+single reference类似。

我是 fftw 库的新手。我最近从这里下载了一个简单的 mpi-fftw 代码。当我在 Ubuntu 18.04 上编译代码时，我对 libfftw3_mpi.a 中的 mpi 函数有一些未定义的引用

我正在使用旧版本gcc-5进行编译。

我尝试在带有 gcc-8 的 mac 上运行相同的东西，但我没有遇到问题。所以我在 Ubuntu 上使用更新版本的 gcc 运行了同样的事情，但仍然遇到同样的问题。

当我编译它时，输出如下

我使用的是 Ubuntu 16.04.5 和 GCC 版本 5.4.0。

我在玩sizeof()运营商，写了下面的代码：

我尝试使用gcc -o ... ...命令进行编译并期待：

但我收到以下错误：

当我%ld改用它时，它按预期工作。为什么sizeof()不合作%d？（为什么是' long unsigned int'而不是' int'？）

编辑：我知道有很多关于 sizeof() 运算符输出的问题（如评论中所建议的那样）。但是，他们没有回答为什么 using%d不起作用（即没有给出任何结果）的问题。我知道这不是正确的格式，但是每当我们使用char类型变量时，我们都%d可以得到等效int的结果，简而言之，uint8_t、uint16_t、uint32_t 也是如此（通常用于等于或小于 32 位的类型）。以下代码有效：

结果是：

现在我发现这%d不适用于需要存储大于 32 位的任何变量。在考虑了这个问题之后，我对 的实现依赖性有了一些想法size_t，也许在我的系统中它是unsigned long（%ld也给出了结果证明了这一点）。所以也许如果size_t在unsigned int我的系统中我会得到一个结果，是真的吗？

从上面的代码可以看出，%c将最后 8 位解码int为一个字符，为什么%d不这样做（即按原样解码size_t变量内容的最后 32 位int？我相信如果它会这样做我们可以对于足够小的数字得到相同的结果，这就是我最初问这个问题时的意思）。