通常，运行./configure --host=xxx就足够了。但是，有时它是非常细微的错误的来源-./configure并非总是抱怨（并且失败），如果某些事情不是100％正确的话。
例如，我不止一次想到只是对某些功能进行了猜测，而且您可以想像，有时这种猜测是不正确的，并且发现了错误（奇怪的行为）以后。
在这种情况下，我可以通过调查configure，写下错误猜测的变量，在实际硬件上检查其正确值，将其放入config.cache文件中并使用{{ 1}}。
我的问题是，在真实的硬件上实际生成整个 --config-cache并将其复制到构建计算机的安全性如何？
显然，已安装的库必须相同，但是其他可能的问题又如何呢？例如，如果在其他位置安装了某些工具（grep，python等）怎么办？还是完全不见了？ config.cache是否可以处理（将其无效值更新为有效/已检查值）？
到目前为止，似乎./configure中唯一需要更新的是config.cache和ac_cv_env_host_alias_set，然后setac_cv_env_host_alias_value愉快地继续。
答案 0 :(得分：1)
我的问题是，实际生成整个config.cache有多安全？ 在真实的硬件上并将其复制到构建计算机上？
不是很安全。尽管configure确定并缓存的某些内容是目标系统属性，但我希望其中许多都是 build-system 属性，例如交叉编译工具链和交叉库的详细信息，正在使用。您无法通过在预期的主机系统上运行configure来可靠地确定这些事情。令您惊讶的是，您在这方面所做的努力没有遇到比您描述的更多的麻烦。这可能是交叉开发环境的良好标志，该环境已针对其目标进行了精心构建和配置。
显然，已安装的库必须相同
这可能是您的提案中最少的问题之一。
但是那又怎么样 其他可能的问题-例如，如果某些工具（grep， python等）是否安装在其他地方？否则会丢失 一共？
是的，如果构建需要那些工具或类似的工具，那么这些细节就是我所讨论的构建系统属性。
./configure是否可以处理此问题（将其无效值更新为 有效/选中一个）？
不。 configure依赖于缓存文件，其要点是它不会重新检查缓存的结果。您很可能会为自己维护的项目手动设置此类操作，但这对于第三方代码来说不太可行，尤其是在构建多个程序包的情况下。
我认为最重要的是交叉编译具有挑战性。即使可能需要在虚拟环境中而不是在物理环境中进行本地编译，也应尽可能选择本机编译。而且，如果您可以在目标环境中成功运行项目的configure脚本，那么您可能拥有一个本地开发环境，足以满足这种本地构建的需求。