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 typedef
ing 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.
"a number of standard C functions and symbols are not defined"
strdup
is not a standard C function. It is defined in POSIX, but not in C or C++. Quoting MSDN:
These POSIX functions are deprecated beginning in Visual C++ 2005. Use the ISO C++ conformant _strdup, _wcsdup, _mbsdup instead.
It appears to me that none of the symbols you list are standard C functions.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With