C ++ не может найти нестандартные функции C в глобальном пространстве имен

У нас есть довольно большой проект C ++, который я сейчас перехожу на VS2010, а также обновляю несколько библиотек. Пока все строится просто отлично, за исключением того, что я получаю (для меня) довольно странные ошибки, где, по-видимому, ряд (редактировать: не) стандартные функции и символы C не определены:

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);, Если я нажму F12 на ::strdup VS принимает меня к декларации в string.h стандартной библиотеки C.

Если я удаляю классификатор пространства имен, который он создает, хотя IntelliSense говорит мне, что теперь это рекурсивный вызов, поэтому он, вероятно, не будет работать. Если я изменю пространство имен на std:: Я получаю около 270 Больше ошибки, на этот раз из нескольких других проектов. Если я изменю функцию на ::_strdup это строит. В том числе string.h как самая первая вещь ничего не меняет.

(Примечание: «он собирает» относится к «эта конкретная ошибка компилятора исчезает в этом месте, но, тем не менее, она оставляет ошибки о других функциях, очевидно.)

Я немного растерялся здесь. Я заметил, что многие более крупные библиотеки либо строят свою собственную абстракцию над стандартной библиотекой, либо предоставляют вещи, которых нет по умолчанию, и это было той точкой, где ACE и ImageMagick уже конфликтовали (в обоих typedefИНГ ssize_t но с несовместимыми определениями). Поскольку мы задействуем довольно много библиотек (сейчас у меня нет точного обзора), это может быть еще одно столкновение, вызванное неправильным порядком включения и подобными вещами. На это также намекает тот факт, что то же самое из ACE явно работает нормально в Другой проекты в том же решении.

У кого-нибудь есть идея, что я мог бы искать здесь, по крайней мере? Журнал сборки с /showIncludes это всего лишь 24 тыс. строк, поэтому я не вижу там много паттернов, кроме string.h включается задолго до проблемного заголовка ACE.

И я не хотел бы изменять исходный код библиотеки, так как он снова укусит нас, если мы обновимся до более новой версии.