I am currently working on a masters project and I am desperately trying to compile some C++ code on my mac (macOS High Sierra 10.13.3 using Xcode) so I can develop the program at home. The Program is a set of files used for performing integrals on a bunch of different data... it uses headers from the boost library and also alglib. This all works fine on Windows machines running visual studios.
The issue I have is that when I include boost (which was installed via homebrew to usr/local/) into the search paths in the project build settings I get all sorts of semantic and linker issues.
I have searched this for a while and tried to implement a few potential fixes. I have tried:
Compiling with different C++ dialects and and standard libraries (libc++ and libstdc++).
Uninstalling/reinstalling boost.
Removing suggested header files and libraries from 'usr/local' suggested by brew doctor.
and implementing all sorts of other random permutations of settings that I felt could be issued.
The number of errors and warnings may change using different build settings however semantic issues persist and I am running out of ideas for how to proceed. It is really important I get this working and any insight would be appreciated.
From my reading about and attempting to troubleshoot I get the idea that it is some kind of linking issue between the boost library and the standard c++ libraries, but I have little experience with semantic issues as in the past I have been lucky enough that things just worked! Perhaps my MacBook may just have too much going on and needs some housecleaning to stop confusing the compiler, but regardless if anyone can help me fix this issue I would be eternally grateful!
I understand I haven't provided much detail here but if any information would be useful I'm happy to send screenshots.
link to errors image
In C++03 ifstream did not have a constructor that accepts std::string.
Such a constructor was added in C++11. The same holds for std::stod: it exists since C++11.
So you have to compile with -std=c++11 option.
I would like to try to use the Core Guidelines checker tool on a C++11/14 project, under VS2015.
In my code I use many libraries from Boost which trigger a lot of warning. I am not concerned by those warnings, since Boost is doing a lot of very clever work and the libraries were not written with the aim of conforming to the Guidelines, which they mostly predate.
But with such a flood of warnings I am unable to find out the real issues (at least according to the tool) in my code.
Is there a way to suppress all the warnings for third party code? Maybe there is some attribute before and after #including boost headers?
I have read this page from the Visual C++ Team blog but I have been unable to find it.
There's an undocumented environment variable, CAExcludePath, that filters warnings from files in that path. I usually run with %CAExcludePath% set to %Include%.
You can also use it from MSBuild, see here for an example (with mixed success): Suppress warnings for external headers in VS2017 Code Analysis
MSVC is working on something similar to GCC's system headers that should be a more comprehensive solution to this problem.
Currently, in VS, the feature to suppress warnings from third-party libraries are still experimental but certainly coming.
VS 2017 version 15.6 Preview 1 comes with a feature to suppress warnings from third-party libraries. In the following article, they use "external headers" as a term to refer to the headers from third-party libraries.
https://blogs.msdn.microsoft.com/vcblog/2017/12/13/broken-warnings-theory/
The above article basically says that
specify external headers
specify warning level for external headers
to suppress warnings from them. For example, if we have external headers in some_lib_dir directory and want to compile our code in my_prog.cpp which depends on the external headers, the following command should do the job.
cl.exe /experimental:external /external:I some_lib_dir /external:W0 /W4 my_prog.cpp
Note that /experimental:external is required because this is still an experimental feature, and the details of this feature may change in the future.
Anyway, we need to wait for the future release of Visual Studio.
I'm using (Apple) LLVM 4.1 within Xcode 4.5 (but I saw the same thing in an earlier beta).
I have it targeting C++11 and am using libc++ (the new, C++11 enabled, LLVM version of the std library).
In a debug build, if I try to step over code that calls into a std library function (e.g. a std::vector constructor) the debugger stops in the std lib implementation and if I try to step out it steps even deeper!
It can take several (sometimes 10 or more) step-outs before I get back to my own code (and I never wanted to step in in this first place).
There always seems to be a _LIBCPP_DEBUG macro in view, as well as _LIBCPP_INLINE_VISIBILITY - but these seem to be everywhere so I'm not sure it's a correlation. It does seem plausible that it has something to do with the way inlining is working, though.
I've not been able to find any examples of anyone else with this problem - yet, for me, it has persisted across several betas - into the release - and through a complete reinstall of the OS.
Has anyone else even seen this? - but better still knows what's going on?
lldb in Xcode 4.5 doesn't handle stepping over inlined functions. The libc++ standard library has many functions that are always inlined, even when built at -O0, which makes this a problem. It looks like Jim Ingham worked on this about a month ago, e.g. see the first patch http://llvm.org/viewvc/llvm-project?view=rev&revision=163044 and several follow-on patches over the following week or two, but of course those aren't in a released version of lldb yet. You can build and use a command line version of lldb from the public site, http://lldb.llvm.org/ (see in particular http://lldb.llvm.org/build.html ), the only tricky bit is to remember to follow the code signing instructions in lldb/docs/code-signing.txt.
I've seen this too, and not only with libc++, also with libstdc++ (the GNU C++ standard library, used by GCC and by clang in C++03-mode). I've always figured it's due to inlining, which I guess sometimes happens in debug builds too.
I have been using the gcc compiler with code::blocks ide, and have noticed there are some things missing in the commctrl.h which are:
PBS_MARQUEE and PBM_SETMARQUEE to set a progress bar to marquee animation style.
LVS_EX_DOUBLEBUFFER for a double buffer on a list view...
there are probably a lot more missing, but these are the ones i've noticed, and i need them!
i have downloaded the latest mingw libraries and they are still not in, the only place i can find them is in visual studios headers, but i don't want to use that
is there any way i can get them in gcc?
GCC does not do a good job of supporting Windows. This is a prime example of why. It's an excellent compiler. and on Unix boxes there's nothing else I'd ever use, because it's an excellent compiler, but...
MinGW simply does not include a few of the Windows headers, and for those that they do, they aren't always as up to date as the ones in the Windows SDK.
Finally, in order to support some bits of COM, GCC would need to be able to parse IDL, is not typically used on non-Windows systems is not currently supported by GCC.
Visual C++ Express (as well as it's compiler included in the Windows SDK) is free. What is your aversion to it?
The best way would be to contact either mingw.org or mingw-w64, which is a fork also supporting x64 targets. The latter are known to respond quickly and friendly to "missing features" requests. you can contact them on either the mailing list or forums or IRC (see link).
.... Scratch that. It seems my copy of the mingw-w64 commctrl.h header include these macros. I don't know if they work as expected, but give it a try. Downloads are linked on the page I linked to above. I would recommend personal builds by Sezero for completeness and ease of use. You should be able to replace your mingw folder with the one from the archive (make sure the gcc.exe et al match up).
Do you have the correct _WIN32_WINNT macro defined? It looks like they all need _WIN32_WINNT >= 0x0501.
I have an annoying problem which I might be able to somehow circumvent, but on the other hand would much rather be on top of it and understand what exactly is going on, since it looks like this stuff is really here to stay.
Here's the story: I have a simple OpenGL app which works fine: never a major problem in compiling, linking, or running it. Now I decided to try to move some of the more intensive calculations into a worker thread, in order to possibly make the GUI even more responsive — using Boost.Thread, of course.
In short, if I add the following fragment in the beginning of my .cpp file:
#include <boost/thread/thread.hpp>
void dummyThreadFun() { while (1); }
boost::thread p(dummyThreadFun);
, then I start getting "This application has failed to start because MSVCP90.dll was not found" when trying to launch the Debug build. (Release mode works ok.)
Now looking at the executable using the Dependency Walker, who also does not find this DLL (which is expected I guess), I could see that we are looking for it in order to be able to call the following functions:
?max#?$numeric_limits#K#std##SAKXZ
?max#?$numeric_limits#_J#std##SA_JXZ
?min#?$numeric_limits#K#std##SAKXZ
?min#?$numeric_limits#_J#std##SA_JXZ
Next, I tried to convert every instance of min and max to use macros instead, but probably couldn't find all references to them, as this did not help. (I'm using some external libraries for which I don't have the source code available. But even if I could do this — I don't think it's the right way really.)
So, my questions — I guess — are:
Why do we look for a non-debug DLL even though working with the debug build?
What is the correct way to fix the problem? Or even a quick-and-dirty one?
I had this first in a pretty much vanilla installation of Visual Studio 2008. Then tried installing the Feature Pack and SP1, but they didn't help either. Of course also tried to Rebuild several times.
I am using prebuilt binaries for Boost (v1.36.0). This is not the first time I use Boost in this project, but it may be the first time that I use a part that is based on a separate source.
Disabling incremental linking doesn't help. The fact that the program is OpenGL doesn't seem to be relevant either — I got a similar issue when adding the same three lines of code into a simple console program (but there it was complaining about MSVCR90.dll and _mkdir, and when I replaced the latter with boost::create_directory, the problem went away!!). And it's really just removing or adding those three lines that makes the program run ok, or not run at all, respectively.
I can't say I understand Side-by-Side (don't even know if this is related but that's what I assume for now), and to be honest, I am not super-interested either — as long as I can just build, debug and deploy my app...
Edit 1: While trying to build a stripped-down example that anyway reproduces the problem, I have discovered that the issue has to do with the Spread Toolkit, the use of which is a factor common to all my programs having this problem. (However, I never had this before starting to link in the Boost stuff.)
I have now come up with a minimal program that lets me reproduce the issue. It consists of two compilation units, A.cpp and B.cpp.
A.cpp:
#include "sp.h"
int main(int argc, char* argv[])
{
mailbox mbox = -1;
SP_join(mbox, "foo");
return 0;
}
B.cpp:
#include <boost/filesystem.hpp>
Some observations:
If I comment out the line SP_join of A.cpp, the problem goes away.
If I comment out the single line of B.cpp, the problem goes away.
If I move or copy B.cpp's single line to the beginning or end of A.cpp, the problem goes away.
(In scenarios 2 and 3, the program crashes when calling SP_join, but that's just because the mailbox is not valid... this has nothing to do with the issue at hand.)
In addition, Spread's core library is linked in, and that's surely part of the answer to my question #1, since there's no debug build of that lib in my system.
Currently, I'm trying to come up with something that'd make it possible to reproduce the issue in another environment. (Even though I will be quite surprised if it actually can be repeated outside my premises...)
Edit 2: Ok, so here we now have a package using which I was able to reproduce the issue on an almost vanilla installation of WinXP32 + VS2008 + Boost 1.36.0 (still pre-built binaries from BoostPro Computing).
The culprit is surely the Spread lib, my build of which somehow requires a rather archaic version of STLPort for MSVC 6! Nevertheless, I still find the symptoms relatively amusing. Also, it would be nice to hear if you can actually reproduce the issue — including scenarios 1-3 above. The package is quite small, and it should contain all the necessary pieces.
As it turns out, the issue did not really have anything to do with Boost.Thread specifically, as this example now uses the Boost Filesystem library. Additionally, it now complains about MSVCR90.dll, not P as previously.
Boost.Thread has quite a few possible build combinations in order to try and cater for all the differences in linking scenarios possible with MSVC. Firstly, you can either link statically to Boost.Thread, or link to Boost.Thread in a separate DLL. You can then link to the DLL version of the MSVC runtime, or the static library runtime. Finally, you can link to the debug runtime or the release runtime.
The Boost.Thread headers try and auto-detect the build scenario using the predefined macros that the compiler generates. In order to link against the version that uses the debug runtime you need to have _DEBUG defined. This is automatically defined by the /MD and /MDd compiler switches, so it should be OK, but your problem description suggests otherwise.
Where did you get the pre-built binaries from? Are you explicitly selecting a library in your project settings, or are you letting the auto-link mechanism select the appropriate .lib file?
I believe I have had this same problem with Boost in the past. From my understanding it happens because the Boost headers use a preprocessor instruction to link against the proper lib. If your debug and release libraries are in the same folder and have different names the "auto-link" feature will not work properly.
What I have done is define BOOST_ALL_NO_LIB for my project(which prevents the headers from "auto linking") and then use the VC project settings to link against the correct libraries.
Looks like other people have answered the Boost side of the issue. Here's a bit of background info on the MSVC side of things, that may save further headache.
There are 4 versions of the C (and C++) runtimes possible:
/MT: libcmt.lib (C), libcpmt.lib (C++)
/MTd: libcmtd.lib, libcpmtd.lib
/MD: msvcrt.lib, msvcprt.lib
/MDd: msvcrtd.lib, msvcprtd.lib
The DLL versions still require linking to that static lib (which somehow does all of the setup to link to the DLL at runtime - I don't know the details). Notice in all cases debug version has the d suffix. The C runtime uses the c infix, and the C++ runtime uses the cp infix. See the pattern? In any application, you should only ever link to the libraries in one of those rows.
Sometimes (as in your case), you find yourself linking to someone else's static library that is configured to use the wrong version of the C or C++ runtimes (via the awfully annoying #pragma comment(lib)). You can detect this by turning your linker verbosity way up, but it's a real PITA to hunt for. The "kill a rodent with a bazooka" solution is to use the /nodefaultlib:... linker setting to rule out the 6 C and C++ libraries that you know you don't need. I've used this in the past without problem, but I'm not positive it'll always work... maybe someone will come out of the woodwork telling me how this "solution" may cause your program to eat babies on Tuesday afternoons.
This is a classic link error. It looks like you're linking to a Boost DLL that itself links to the wrong C++ runtime (there's also this page, do a text search for "threads"). It also looks like the boost::posix::time library links to the correct DLL.
Unfortunately, I'm not finding the page that discusses how to pick the correctly-built Boost DLL (although I did find a three-year-old email that seems to point to BOOST_THREAD_USE_DLL and BOOST_THREAD_USE_LIB).
Looking at your answer again, it appears you're using pre-built binaries. The DLL you're not able to link to is part of the TR1 feature pack (second question on that page). That feature pack is available on Microsoft's website. Or you'll need a different binary to link against. Apparently the boost::posix::time library links against the unpatched C++ runtime.
Since you've already applied the feature pack, I think the next step I would take would be to build Boost by hand. That's the path I've always taken, and it's very simple: download the BJam binary, and run the Boost Build script in the library source. That's it.
Now this got even a bit more interesting... If I just add this somewhere in the source:
boost::posix_time::ptime pt = boost::posix_time::microsec_clock::universal_time();
(together with the corresponding #include stuff), then it again works ok. So this is one quick and not even too dirty solution, but hey — what's going on here, really?
From memory various parts of the boost libraries need you to define some preprocessor flags in order to be able to compile correctly. Stuff like BOOST_THREAD_USE_DLL and so on.
The BOOST_THREAD_USE_DLL won't be what's causing this particular error, but it may be expecting you to define _DEBUG or something like that. I remember a few years ago in our boost C++ projects we had quite a few extra BOOST_XYZ preprocessor definitions declared in the visual studio compiler options (or makefile)
Check the config.hpp file in the boost thread directory. When you pull in the ptime stuff it's possibly including a different config.hpp file, which may then define those preprocessor things differently.