There are two projects, in one case of an error I saw 'clang++', in the other I saw nothing. Android.mk and Application.mk almost identical, the compilers are not listed anywhere in these files. I read somewhere that GCC is used by default, but I began to doubt something.
Which NDK compiler is used by default? And which is better GCC or Clang ?
Related
I am trying to follow this guide
to configure VC++ for WxWidgets. I got stuck here.
So for Core wxWidgets libraries to include, I did include wxmsw31u[d]_core.lib and wxbase31u[d].lib under Linker>>Input>>Additional Depenedencies. That is all to it right?
As for Linking with correct runtime library, can someone tell me how that is done? I manage to get here but don't know how to set the indicated settings.
Please help. I really appreciate it.
When you want to debug your app the debugger must know where in the compiled code is each function used. In jargon, the "debugging symbols". Windows puts these symbols in the compiled executable, while Linux uses another, .devfile.
When you compile code (your app or wxWidgets library) you must tell the compiler whether you want a "Debug" version or a "Release" one.
If you want the debugger to be able to step into wxWidgets code, then you must compile wxWidgets in "debug" mode, which will add the character d to the library files built. So, you must add, for example, wxmsw31ud_core.lib to your app dependencies. Notice the d between u and _. Use the file explorer to see all files generated by wxWidgets compilation process.
Perhaps you don't want all this wxWidgets "debug". Then use another wxWidgets compilation route and add wxmsw31u_core.lib instead of the d'd version. Still you can compile your own app in debug mode, but not being able to step through wxWidgets internals.
Now for your app, a) do you want a single executable file also containing wxWidgets code? or b) let your app in a .exe file which uses as needed external .dll files?
a) is called "static linkage" while b) is called "dynamic linkage"
As you can see, there are four combinations of debug/release & static/dynamic. You must choose one "runtime library" to link to your app.
The table in the wiki shows the switch and MSVC lib (select the desired combination in the 'properties' page) to use in your app; and macro definition required to build wxWidgets if you use nmake instead of the already provided configurations in VS.
Take a look at docs\msw\install.txt for more info.
The best advice I give is that you look into "minimal" sample project. Load it into VS and read every option. You can even make a copy, change some file names and use it for your own app.
I recommend using the official instructions instead of the wiki, they're simpler and, if you look at the last paragraph, you can see that you don't even have to link the libraries manually with MSVC.
You also don't need to do anything special to link with the correct version of the CRT, the defaults are just fine.
I'm starting a drone project based on Ardupilot and trying to build Ardupilot project using Qt Creator, following this instructions . I'm working with Ubuntu, BTW.
You've probably find this stupid (cause it probably is), but I'm not able to set up the compiler (in spite of having the instructions):
As suggested, I downloaded the compiler from here, and tried to follow the instructions but after choosing a custom compiler in 'Build & Run', the 'Make path' is driving me crazy and I have no idea of which path is that (in other words, the equivalent to the file 'make.exe' in Windows, see the image attached), since there doesn't seem to be anything similar in the compiler folder and it doesn't seem to refer to the Makefile of the project.
Hope anyone can help me, as you've surely noticed, I'm pretty new to big, real projects and also to Linux itself.
Thanks in advance,
Eduardo
PD:
Instructions provided (both Windows & Linux):
Linux: Which one is the 'Make path'?
The build directory should point to ardupilot/ArduCopter if you are building for Copter
In the example it was pointing to ardupilot
Compiler path: /opt/gcc-arm-none-eabi-4_9-2015q3/bin/arm-none-eabi-gcc
The make file path: /usr/bin/make
First. What version of qt? If it's 5.7 then the 2015 toolkit won't work. If you're new to Linux then you should definitely stay with a prior version of qt 5.7 until someone has compiled a new toolkit that supports a c++11 compiler.
You don't have enough info on what you're doing to give a good answer though.
What do you need the program to do? If it's Qt3d on Arm then you have a big problem only 5.7 will do.
Hope this helps.
So I'm trying to get the first exercise in the OpenGL Superbible 5th edition to run. It should draw a triangle. I've managed to fix all of my dumb typos. Now I'm down to just two error messages, one of which I think is familiar;
1>LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library
1>LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt
I think I stumbled across LNK1123 when I first used C++, and I fixed it by disabling 'Incremental Linking' in the project settings. However, when I try this now, though the program does run and a window does open, no triangle is drawn, and I'm given a list of errors relating to OpenGL tools. And LNK4098 is still there as well.
This is my first project using library imports. Although it was a minefield trying to get it to work, I finally got the graphics libraries GLEW and freeGLUT into my project, by adding them to the project's include path list, and then adding them as existing items to the project. But I suspect that this method has upset the mighty VC++. Could someone please help?
This has nothing to do with OpenGL. This error is basically telling you that you are using the multi-threaded version of Microsoft's C standard library in a project that is already linking to another version of the library.
The interesting thing is that newer versions of MSVC do not have different versions of the C standard library for threaded vs. non-threaded. Thus, your MSVC version is relevant information that is absent from the question.
In any case, the linker warning actually tells you exactly how to resolve the warning. You can add /NODEFAULTLIB:libc to the linker command in your project settings. There is usually an edit-box in the project settings to accomplish this as well, but since its location varies from version to version, adding this to the command-line is simpler.
As for the COFF issue, this is related to the generation of debug symbols in an incremental linking project. /INCREMENTAL:NO should fix this issue. Regarding the cause of it, have you installed different versions of MSVC on this system in the past?
I have a C++ Visual Studio project which I'm trying to compile for x86 and x64 architecture. I've googled and found a lot information how to do it and it seems to work, but it left me deeply confused about what is going on behind the curtains.
Apperently, the only difference in the settings is a switch in the linker command line flags (to be precise, it's the /MACHINE flag).
If that's the case however, then the object files of the compilation must be platform independent - which is somehow the exact opposite of what I always assumed it to be, since object files are supposed to be sequences of machine code which in turn should be platform dependent.
So, my question is: which part(s) of the build process does not behave the way I thought it would?
Thanks for your time and wisdom!
Michael
When compiling for 32-bit x86, Visual Studio uses the compiler \Program Files\Microsoft Visual Studio 10.0\VC\bin\cl.exe. When compiling for 64-bit x86, Visual Studio uses the compiler \Program Files\Microsoft Visual Studio 10.0\VC\bin\amd64\cl.exe. The first compiler produces 32-bit object files, the second produces 64-bit object files. This can be seen by running dumpbin.exe on the object files to see their specified architecture.
The compiler invocation remains the same (more or less) -- what changes is the executable $PATH that is set before building. By pointing the PATH to the 32-bit or 64-bit directory, it sneakily changes the whole set of programs that is run to build your project. You can see this by looking at the Project Properties > Configuration Properties > VC++ Directories > Executable Directories, and clicking on "Edit". In the "Inherited Values" box you'll see the path for the current Configuration and Platform.
Debugging in gdb is not convenient for me so I enjoy the nice debugging interface that code::blocks offers. Now that I have moved my project into an area where those flags are required (the ones in the title, of course), I find that I can't compile on code::blocks anymore :/.
Hi everyone I figured out how to add the -lrt. Since -lrt is passed to the linker and not the compiler you can go to Settings->Compiler and Debugger->linker options then press add and after doing a "locate lrt" I found this cute library "/usr/lib/libaticalrt.so." I added the library in the linker options and now those errors disappeared... Time to try boost!
EDIT: Boost was solved in a similar manner. The library represented by lboost_thread is libboost_thread.so. A locate found it at: "/usr/lib/libboost_thread.so." Adding it in the linker options solved the problem :D