Question

We have a fairly large C++ project which I am now in the process of moving to VS2010 and also updating a few libs along the way. So far everything builds just fine now, except I get (to me) quite weird errors where apparently a number of (edit: non-)standard C functions and symbols are not defined:

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
...

This affects the following functions and symbols for me:

strdup      getcwd      O_WRONLY
putenv      swab        O_TRUNC
access      unlink      S_IFDIR
chdir       mkdir       S_IFREG
rmdir       tempnam     O_RDONLY
isascii

One part in the include file from ACE I experimented with was the strdup part which looks like this:

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) || ... */
}

There are loads of similar sections for other functions above and below, all of which compile just fine.

The path taken in my case is the last one, i.e. return ::strdup (s);. If I hit F12 on the ::strdup VS takes me to the declaration in string.h of the C standard library.

If I remove the namespace qualifier it builds, although IntelliSense tells me that it’s now a recursive call so it probably won’t work. If I change the namespace to std:: I get around 270 more errors, this time from several other projects. If I change the function to ::_strdup it builds. Including string.h as the very frst thing changes nothing.

(Nota bene: “it builds” refers to “this particular compiler error disappears at that location, but it still leaves the errors about the other functions, obviously.)

I’m a little at a loss here. I noticed that many larger libraries either build their own abstraction over the standard library or provide things that are not there by default and that was a point where ACE and ImageMagick already clashed (in both typedefing ssize_t but with incompatible definitions). Since we pull in quite a few libraries (I don’t have an exact overview either, right now) this could well be another clash, caused by the wrong include order and similar things. This is also hinted at by the fact that the same includes from ACE apparantly work fine in other projects in the same solution.

Anyone have an idea what I could look for here at least? The build log with /showIncludes is just 24k lines so I don’t exactly see many patterns there, except that string.h gets included way before the problematic ACE header.

And I wouldn’t want to modify the library source code as that will only bite us again if we update to a newer version.

Answer 1

With Mark B’s comment which prompted me to look at 12 MiB of Preprocessor output I was able to solve it. In string.h the snippet where strdup is defined looks like this:

#if     !__STDC__

...

_Check_return_ _CRT_NONSTDC_DEPRECATE(_strdup) _CRTIMP char * __cdecl strdup(_In_opt_z_ const char * _Src);

It so happened that this single project defines the __STDC__ symbol which causes a lot of non-standard-C-but-still-in-the-C-standard-library (thanks, Rob_φ for nitpicking but not solving the issue) functions to disappear completely.

I know they’re deprecated, I got plenty of warnings that tell me so. But as noted, I’m not maintaining project-specific patches to 3rd-party libraries we use just to have the same fun all over again if we ever update them.