error C2039: 'strdup' : is not a member of '`global namespace'' ...\ACE_wrappers\ace\OS_NS_string.inl 222
...
error C2065: 'O_WRONLY' : undeclared identifier ...\ACE_wrappers\ace\OS_NS_unistd.inl 1057
...
这对我以下的功能和符号产生影响:
strdup getcwd O_WRONLY
putenv swab O_TRUNC
access unlink S_IFDIR
chdir mkdir S_IFREG
rmdir tempnam O_RDONLY
isascii
在我尝试的ACE包含文件中,有一个与strdup
相关的部分,如下所示:
ACE_INLINE char *
ACE_OS::strdup (const char *s)
{
# if (defined (ACE_LACKS_STRDUP) && !defined(ACE_STRDUP_EQUIVALENT)) \
|| defined (ACE_HAS_STRDUP_EMULATION)
return ACE_OS::strdup_emulation (s);
# elif defined (ACE_STRDUP_EQUIVALENT)
return ACE_STRDUP_EQUIVALENT (s);
# elif defined (ACE_HAS_NONCONST_STRDUP)
return ::strdup (const_cast<char *> (s));
#else
return ::strdup (s);
# endif /* (ACE_LACKS_STRDUP && !ACE_STRDUP_EQUIVALENT) || ... */
}
以上和以下有许多类似的部分,涵盖了其他功能,所有这些部分都可以编译通过。
在我的情况下,采用的是最后一种方式,即return ::strdup (s);
。如果我在::strdup
上按F12,VS会将我带到C标准库中string.h
的声明处。
如果我删除命名空间限定符,它就能构建,尽管IntelliSense告诉我它现在是一个递归调用,所以它可能行不通。如果我将命名空间更改为std::
,就会得到大约270个更多的错误,这次来自于几个其他项目。如果我将函数更改为::_strdup
,它就能构建。将string.h
作为第一件事包含进来并没有改变什么。
(Nota bene:“它能构建”指的是“这个特定的编译器错误在那个位置消失了,但显然还留下了关于其他函数的错误。”)
我有点茫然。我注意到许多较大的库要么构建自己的抽象库,要么提供默认情况下不存在的东西,这是ACE和ImageMagick已经冲突的一个点(都在typedef
中使用ssize_t
,但定义不兼容)。由于我们引入了相当多的库(我现在也没有确切的概述),这可能是另一个冲突,由错误的包含顺序和类似的问题引起。这也可以从ACE的相同包含在同一解决方案中的其他项目中工作良好的事实所暗示。
有人有什么想法至少可以在这里寻找吗?带有/showIncludes
的构建日志只有24k行,因此我并没有看到很多模式,除了string.h
在有问题的ACE头文件之前被包含进来。
而且我不想修改库源代码,因为如果我们更新到新版本,它只会再咬我们一口。
<cstring>
,而非<string.h>
。 - ipcstd
中,或者它们是否出现在std
中,只有 可能 出现在全局命名空间中。不过这并没有什么区别。至少我是这样理解的。 - Joey/showIncludes
的构建输出结果差不多难以阅读,但这确实让我找对了方向。 - Joey