我如何以编程方式确定我的C ++运行时库在哪里？ [英] How can I programatically determine where my C++ runtime libraries are?

问题描述

我使用hax在CentOS 6上构建C ++ 11，并在CentOS 6上构建，然后部署在任意CentOS 6目标上（任何C ++相关的开箱即用C ++ 03构建） GCC 4.3）^{（ ref ）}。

为了实现这个目标，我将发布我的所有第三方库以及g ++运行库，以及 rpath 我的可执行文件，以便更新的库可以在适当的地方找到。对于运行时，按我的数量计算，我需要运送 libstdc ++ 和 libgcc_s 。但我需要知道他们在我的构建系统上的位置，以便我可以将它们打包。

我可以通过一些简洁的方式查询他们的位置在我的包装脚本中？

（如果最好的方法太尴尬，我会静态链接它们，但我想避免如果我可以像我的项目中包含多个可执行文件一样，并且如果我要静态链接所有的东西，我相信我会冒GPL整个项目的风险，例如通过静态链接MySQL C API通过我的C ++ MySQL包装库。可以做两者的混合，我想，尽管一些消息来源警告这个 ......）

对于奖励积分，我是否需要添加任何内容到$ libssl 中， libcrypto ， libm ， libpthread ， libc ， librt ， libz 和 ld-linux- x86-64 ？

如果我理解正确，您已经构建了二进制文件，并且只想获取运行时库列表以将它们与二进制文件打包在一起？您可以尝试使用 ldd ，例如：

 > ldd / usr / bin / ls 
 linux-vdso.so.1（0x00007ffe76dd2000）
 libselinux.so.1 => /lib64/libselinux.so.1（0x00007fc97131f000）
 libcap.so.2 => /lib64/libcap.so.2（0x00007fc97111a000）
 libacl.so.1 => /lib64/libacl.so.1（0x00007fc970f10000）
 libc.so.6 => /lib64/libc.so.6（0x00007fc970b68000）
 libpcre.so.1 => /usr/lib64/libpcre.so.1（0x00007fc970902000）
 libdl.so.2 => /lib64/libdl.so.2（0x00007fc9706fd000）
 /lib64/ld-linux-x86-64.so.2（0x000055c4ba4ed000）
 libattr.so.1 => /lib64/libattr.so.1（0x00007fc9704f8000）
 libpthread.so.0 => /lib64/libpthread.so.0（0x00007fc9702db000）
  

这样你将会看到所有需要的库，当然，那些通过dlopen（）使用的。

I'm building C++11 with GCC 4.8 on CentOS 6 using "hax", then deploying on arbitrary CentOS 6 targets (on which anything C++-related out of the box will have been built as C++03 with GCC 4.3) ^(ref).

To make this work, I'm going to ship all of my third-party libs as well as the g++ runtimes, and rpath my executables so the newer libs are assuredly found in the proper place. For the runtimes, by my count I need to ship libstdc++ and libgcc_s. But I need to know where they are on my build system so that I can package them up.

Is there some neat way I can query for their location from within my packaging script?

(If the best approach is too awkward I'll just link them statically, but I'd like to avoid that if I can as my project includes several executables. Also if I were to statically link everything I believe I'd run the risk of GPL-ing my whole project, e.g. by statically linking the MySQL C API via my C++ MySQL wrapper lib. Could do a mixture of both, I suppose, though some sources warn against this…)

For bonus points, do I need to add anything to this list, out of libssl, libcrypto, libm, libpthread, libc, librt, libz and ld-linux-x86-64?

解决方案

If I understand correctly, you have already built your binaries and just want to get a list of runtime libraries to package them along with binaries? You can try using ldd for this, like:

> ldd /usr/bin/ls
    linux-vdso.so.1 (0x00007ffe76dd2000)
    libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fc97131f000)
    libcap.so.2 => /lib64/libcap.so.2 (0x00007fc97111a000)
    libacl.so.1 => /lib64/libacl.so.1 (0x00007fc970f10000)
    libc.so.6 => /lib64/libc.so.6 (0x00007fc970b68000)
    libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00007fc970902000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007fc9706fd000)
    /lib64/ld-linux-x86-64.so.2 (0x000055c4ba4ed000)
    libattr.so.1 => /lib64/libattr.so.1 (0x00007fc9704f8000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc9702db000)

This way you will see all libraries needed except, of course, the ones that are used via dlopen().

这篇关于我如何以编程方式确定我的C ++运行时库在哪里？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！