小编naf*_*fmo的帖子

我正在使用Developer Toolset 7 中的编译器为 Red Hat/CentOS 7（在 CentOS 上运行）编译软件 ，当我尝试创建 RPM 时，rpmbuild 失败并显示以下错误：

+ /usr/lib/rpm/find-debuginfo.sh --strict-build-id -m --run-dwz --dwz-low-mem-die-limit 10000000 --dwz-max-die-limit 110000000 /home/peter/src/foo/rpmbuild/BUILD/mypackage-5.4.0_10_243_g2564bd2ee3
extracting debug info from /home/peter/rpmbuild/BUILDROOT/mypackage-5.4.0_10_243_g2564bd2ee3-1.x86_64/path/to/my/bin/binary
eu-strip: error while loading shared libraries: libelf.so.dts.1: cannot open shared object file: No such file or directory

我在使用 Toolset 3 时没有看到这个，基本上我所做的就是将构建脚本中的 3 更改为 7。

编辑：如果我禁用提取调试信息 ( %define debug_package %{nil})，我不会收到错误消息。

对于嵌入式软件项目，我添加了对翻译的支持，并且由于我们正在运行嵌入式Linux，因此我选择使用libc gettext()。我们没有安装任何语言环境定义，因此我仅尝试将LC_MESSAGES语言环境设置为所需的语言环境：

setlocale(LC_MESSAGES, "fake");

（在使用正确的翻译之前，我正在使用名称fake和fake.mo文件进行伪翻译）。

静态链接时此方法工作正常，它返回一个语言环境句柄，bindtextdomain()并且所有朋友都可以正常工作，而我从中获得了“翻译”字符串：

setlocale() returned "fake"
current textdomain is "ewe"
current base directory is "/opt/btech/probe/share/locale/WA"
current LC_MESSAGES locale is "fake"
gettext("Error") ==> "?????"

现在，当我动态编译它时，它不起作用。既不在目标设备上，也不在本地PC上（文件安装方式相同）。该setlocale()调用失败，返回一个NULL指针，并设置errno为ENOENT（找不到文件）。到目前为止，setlocale()我还没有指出bindtextdomain()文件的位置，但是切换调用无济于事。

我做错事了吗，我的工作示例是错误的，真的不应该工作吗？我是否需要语言环境什么我打电话的定义setlocale()上，即使是LC_MESSAGES？

这是测试二进制文件的来源：

#include <libintl.h>
#include <locale.h>
#include <stdio.h>

int main()
{
    const char *l = setlocale(LC_MESSAGES, "fake");

    printf("setlocale() returned \"%s\"\n", l);

    bind_textdomain_codeset("ewe", "UTF-8");
    bindtextdomain("ewe", "/opt/btech/probe/share/locale/WA");
    textdomain("ewe");

    printf("current textdomain is \"%s\"\n", …

我正在编译一个GO应用程序,我想在Google云端平台上传和运行.我正在导入appengine/datastore包,并且遇到了包装的问题.由于我想提供稳定的构建,我希望在源代码树中拥有尽可能多的依赖项,但是当我供应商时,appengine/datastore我遇到了运行问题gcloud app deploy:

OperationError:错误响应:[9]部署包含无法编译的文件:编译失败:2017/09/19 01:07:31 go-app-builder:解析输入失败:包"vendor/google.golang.org/appengine/search"无法导入内部包"google.golang.org/appengine/internal/search"

ERROR: (gcloud.app.deploy) Error Response: [9] Deployment contains files that cannot be compiled: Compile failed:
2017/09/19 01:07:31 go-app-builder: Failed parsing input: package "vendor/google.golang.org/appengine/search" cannot import internal package "google.golang.org/appengine/internal/search"

我可以正常运行dev_appserver.py脚本,应用程序在本地运行顺利,并go test成功编译并运行所有模块测试.

如果我尝试删除任何appengine包的销售,而是使用go get在版本控件之外安装它们,dev_appserver.py不再运行,抱怨重复的包:

rm -rf ../vendor/google.golang.org/appengine
go get google.golang.org/appengine
dev_appserver.py app.yaml
[....]
2017/09/19 10:20:10 go-app-builder: Failed parsing input: package "golang.org/x/net/context" is imported from multiple locations: "/home/peter/src/myproject/go/src/myproject/vendor/golang.org/x/net/context" and "/home/peter/src/myproject/go/src/golang.org/x/net/context"

而gcloud app deploy …

在 $DAYJOB，我正在尝试使用reproducible-builds.org中的提示来实现可重现的构建，以便更轻松地调试已发布的软件，而我们的构建服务器上不再有完整的调试版本。

在 GCC 中使用-ffile-prefix-map=/path/to/build=src选项来避免泄漏内部文件路径确实有助于使一些错误消息更清晰，但在使用 GDB 时确实会产生问题。我位于 /path/to/build/some/binary/ 并在 /path/to/build/lib/cclib/ 中命中断点：

Breakpoint 1, [...]
at src/lib/cclib/eventloop.cc:154
154    src/lib/cclib/eventloop.cc: No such file or directory.
(gdb)

作为解决方法，我可以符号链接src到构建树的根，但是有没有更好的方法来确保 gdb 理解映射？