XCode with boost "Semantic Issue - undeclared identifier va_start"

Question

C++locale.h
->Semantic Issue
-->Use of undeclared identifier 'va_start'
->Semantic Issue
-->Use of undeclared identifier 'va_end'

First time using boost, downloaded it using ports and created a command line project in XCode. Header Search Path: /usr/include/**

There is nothing in the code yet, just the main function that comes with the default proj.

Just don't know what to do, never expected this to happen.

EDIT1:

First occurrence:

#ifndef _GLIBCXX_CSTDARG
#define _GLIBCXX_CSTDARG 1

#pragma GCC system_header

#include <bits/c++config.h>
#include <stdarg.h>

// Adhere to section 17.4.1.2 clause 5 of ISO 14882:1998
#ifndef va_end
#define va_end(ap) va_end (ap)
#endif

_GLIBCXX_BEGIN_NAMESPACE(std)

  using ::va_list;

_GLIBCXX_END_NAMESPACE

#endif

It's a file without extension in \usr\include\c++\4.2.1 and i just realized that this file has nothing to do with boost, there is something nasty happening here.

EDIT2: After fixing the include dir to /opt/local/include/** new errors appeared:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/c++/v1/type_traits:214:46:
Use of undeclared identifier 'nullptr_t'; did you mean 'nullptr'?

There are other errors, all related to these files in the folder sr/lib/c++/v1/ why is that? These file seems to be some core functionality, they can't be broke.

Here is a pic of the errors, maybe ou guys see something

EDIT3: Changing the compiler from Apple LLVM to GCC LLVM reduces the errors to only one: "vspintf is not a member of 'std'" in c++locale.h. Ok, now I'm completely lost.

Solution 1

First, you're may not be #includeing the right headers.

For example, if you don't #include <cstddef>, you can't use std::nullptr_t; attempting to do so will give you:

Semantic issue: Use of undeclared identifier 'nullptr_t'. Did you mean 'nullptr'?

Often, pulling in one header happens to implicitly pull in various other headers, so things work even when they shouldn't. libstdc++ does this a lot more than libc++, and the former is the default library for llvm-g++ ("GCC LLVM"), the latter for clang ("Apple LLVM"), which means a lot of errors will seem to go away when you switch to "GCC LLVM" (or just stick with "Apple LLVM" and switch your library), but your code is still wrong.

Another possibility is that you're trying to compile C++11 in C++03 mode. For example, when you #include <cstddef> in C++03 mode, it shouldn't define nullptr_t. It might do so anyway—and it might do so with llvm-g++ and/or libstdc++, but not with clang and/or libc++. But your code (or, in this case, your project) is still wrong and should be fixed.

If you can show us the actual (stripped-down) code that generates these errors, and tell us exactly what settings you changed from the default "Command Line Tool, C++" project you created in Xcode (assuming that's what you created), it should be possible to be more specific.

To get a minimal program working with boost, assuming you've got Xcode, MacPorts, and MacPorts boost installed properly, all you have to do is this:

• Create a new Command Line Tool, C++.
• Click on the project, then under Search Paths, go to Header Search Paths, and edit it to add /opt/local/include.
• Modify main.cpp to look like the following:

main.cpp

#include <iostream>
#include <boost/uuid/uuid.hpp>

int main(int argc, const char * argv[])
{
    boost::uuids::uuid u1 = {
        0x12, 0x34, 0x56, 0x78,
        0x90, 0xab, 0xcd, 0xef,
        0x12, 0x34, 0x56, 0x78,
        0x90, 0xab, 0xcd, 0xef };
    boost::uuids::uuid u2 = {
        0x12, 0x34, 0x56, 0x78,
        0x90, 0xab, 0xcd, 0xef,
        0x12, 0x34, 0x56, 0x78,
        0x90, 0xab, 0xcd, 0xef };
    std::cout << (u1 == u2) << "\n";
    return 0;
}

I picked boost::uuid because it's a dead-simple library, but the same should work for compiling any part of boost.

Some parts of boost also require you to link in a library. For that, you'll also need to add /opt/local/lib to Library Search Paths before you can use most of the usual techniques for adding libraries to a project.

Note that if you're up to date, you can make this even shorter, because with Xcode 4.5, the defaults will be Apple LLVM Compiler 4.1, GNU++11 dialect, and libc++ with C++11 support library. But I made sure my code was C++03-compatible so it works with the defaults in almost any version of Xcode (I tested with 3.2), since you never told us what version you were using.

Solution 2

I had the same issue, I've installed Boost with homebrew and when I add the 'Header Search Path' (/usr/local/Cellar/boost/1.54.0/include with the recursive option) in XCode the build throw those errors.

To fix it I changed the recursive option to non-recursive on the 'Header Search Path' and it worked.

Solution 3

I had this problem and solved it. In XCode on osx mavericks had to add /opt/local/libs/ to the library search path (non-recursive). I then added /opt/local/include/ to the header search path (also non-recursive).

Solution 4

You need to #include <stdarg.h> in order to use the va_start macros et al. If those errors are happening in a header file, then that header file should include <stdarg.h>; if it doesn't, you can work around it by including it yourself before you include the problematic header (but you should also report the issue to the library developers, if possible).

Solution 5

From the latest comment, I think I know the problem.

Header Search Path: /usr/include/**

Just created another fresh XCode command line tool app. There is no errors at all when building the Hello World, but just adding the Header Search Path breaks the compilation with the above stated error, there is no reference to boost in my code yet, just added the search path.

Where did you get the search path /usr/include/**?

MacPorts installs everything to /opt/local, not /usr, so you want /opt/local/include (or /opt/local/include/** or /opt/local/include/boost); adding /usr/include/** isn't going to help at all with Boost.

However, it may break your code even before you get to Boost.

What's in /usr/include is Xcode's Command Line Tools. If you don't have these, you've got an incomplete and unusable set of headers; if you do, you've got a set of headers that conflicts with SDK-based builds.

The answer is to not add /usr/include/** to your search path.

Or, if you really need to add it (but really, you don't), change the Base SDK to "Current OS X" instead of "Latest OS X", which means you'll be getting your default headers out of /usr/include instead of, e.g., /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/include, and of course adding a path that's already there won't lead to any conflicts.

View more solutions

Comments

[Paulo Henrique]

I've edited the question with the file were the occurrence first happens, it looks like it already has stdarg.h included

[Paulo Henrique]

The situation changed, I've bee misguided to put what macports downloaded and installed in /usr by a page which I could not found right now. But now I have new erros, all of them "Semantic", I'll update the question with the proper error and file.

[Paulo Henrique]

If you could share a XCode Project working with boost, I would be so glad.

[abarnert]

Well, my boost is installed by Homebrew rather than MacPorts, so you'd have to edit Header Search Paths from /usr/local/include to /opt/local/include. And, since that's the only thing I changed from the defaults, you can just as easily start with a default.

[abarnert]

See my other answer for step by step instructions.

[Paulo Henrique]

I've re-downloaded boost with homebrew, it seems homebrew put boost in /usr/local/include, any problem? Xcode and ML are updating right now, after they update I'll create a brand new project, add boost to the header search path and upload it so you can take a look.

[abarnert]

Should be no problem, especially since that's what I'm using myself; just use /usr/local in place of /opt/local any place it appears above. (Unless you have both Homebrew and MacPorts installed, which is generally a bad idea. If you have problems, you may want to temporarily hide MacPorts by, e.g., sudo mv /opt/local /opt/local-bak.)

[koen]

I just ran into the same problem, and got all these errors when using Boost in my Xcode project. After trial and error I found that the Header and Library paths should be non-recursive. Once I did that, it all compiled without errors.

[masonk]

I installed Boost with the Boost.Build package. It installs into /usr/local/lib and /usr/local/include/boost by default. On the advice of this answer, I added /usr/local/include/boost to my header search path, instead of /usr/local/include, and most of the errors went away. The remaining error is probably unrelated.

[Samet DEDE]

Changing recursive to non-recursive solved my issue on Mavericks

[Todd]

Yes, the recursive to non-recursive was my problem.

[mgrandi]

This does not work with xcode 5.1 =( still the same errors, any ideas?

[Rudi]

Thanks, this helped for me.