我这里有一些（遗留）代码似乎在setenv上调用LD_LIBRARY_PATH（编译时未知的值，实际上它将从命令行获取），现在我有了将它移植到Windows。我怀疑setenv仅仅是出于历史原因，并且它已经没有实际效果了，我想确认一下。
因此，我的方法是审核环境的所有用途，看看是否有任何受LD_LIBRARY_PATH（或其他）影响的人。所以我认为，除非调用environ变量或某些函数，否则代码对环境不敏感（直接，间接或后续代码）。
我所识别的功能（作为候选人）是：
getenv exec* popen system dlopen和朋友TZ变量的时间函数包含getenv的原因显而易见，因为后续代码可能取决于环境变量的值。包含exec*，popen和system是因为首先（子）程序的链接可能会受到环境的影响，但（子）程序本身可能依赖于环境， dlopen我认为会在LD_LIBRARY_PATH中搜索库（此处也可能是链接库本身在初始化期间或以后访问环境时）。剩下的就是因为我知道TZ和语言环境正在标准库的很多地方使用。
我是否错过了某些功能或代码可能取决于环境的其他情况？当然我意识到这受到了加载的库的影响，但据我所知，只有＆＃34;标准＆＃34;已加载的库加libsqlite3（加libpthread，libdl和libm）。我想SQLite3可能对某些环境变量很敏感，但其中只有LD_LIBRARY_PATH个？
对于此次记录，该程序似乎不包括exec*或dlopen，但我包括它们，因为在另一种情况下它们可能会。
答案 0 :(得分：1)
您应该查看每个功能的文档。 dlopen的内容明确指出它使用LD_LIBRARY_PATH作为搜索列表来查找共享库。
在任何情况下，当您可以指定路径作为dlopen的参数时，强制加载特定库似乎是一种相当笨拙的方法。
除此之外，它是GNU链接器ld用于定位静态库的值。所以不太可能但是可能的是，它被应用程序使用，因为它启动了链接器或使用dlopen的其他进程，它可以通过exec，popen或{{ 1}}例如。鉴于您的代码具有所有这些功能，它很明显地启动了一些外部进程。