I'm trying to find info and I don't see it on clang web site.
I'm thinking to try to use it on windows, but I have no clue if it has it's own libc or it uses broken libc from MS?
another question: if i compile code with clang, will I be able to use visual studio as a debugger, e.g. is clang capable of emitting debugging symbols in MS format (this is the reason I don't want to use gcc; and this is something that intel compiler can do, but it uses MS's libc).
In short, I'd like to be able to use visual studio as a debugger, but I need at the same time decent real c compiler with normal lib c.
or, perhaps, there are commercial alternatives. I've read that dinkum sells commercial libc for Win32 and others, but I have no clue what's the price and how to get it.
You have asked two completely different questions. I will answer the one about using Visual Studio as a debugger.
This is not currently possible. Microsoft has not released any documentation or code necessary to produce files in their PDB format, which is what Visual Studio consumes. There has been some reverse engineering efforts, but results of those have not yet made their way into general Open Source tools.
Neither GCC nor Clang are capable of producing PDB files, and hence do not work with Microsoft's debugger. Some of the commercial compilers have support for generating or consuming PDB, but not the Free/Open compilers like GCC and Clang.
You can use other IDEs on Windows which support the DWARF debugging format, used by GCC and Clang. Such compilers include Code::Blocks and Eclipse CDT.
Related
Visual Studio 2017 RC includes much tighter CMake integration, allowing one to skip the intermediate step of generating project/solution files and use CMake effectively as the project file itself. There is sufficient documentation from Microsoft for using these features with regular C++ files, and there is sufficient documentation on this website (example) for making CUDA and Cmake play nicely, when it comes to linking CUDA code to C++ code.
What I can't find information on is how to make CMake, Visual Studio 2017 RC, and CUDA 8.0 all play nicely. This is a difficult problem, because 2017RC has no integration for the CUDA SDK anyways, and I was hoping to use 2017RC so that my C++ interface to the CUDA code could use C++14 and/or C++17. I'm working on the beginning of a large project that will primarily involve writing a static CUDA library that is accessed through C++: so, I'd like to get the CMake to take care of compiling my CUDA sources into a static library, and for it to help with feeding the linking information to Visual Studio. So far, I haven't had any success with using FindCUDA's various features to accomplish this, but I'm assuming that's due to a misunderstanding on my part. I've read through the documentation on separable compilation from Nvidia, but that wasn't helpful for figuring out CMake.
Further, whenever I try to use CMake in VS2017RC, I still end up with the various vcxproj files that CMake likes to spit out. Is this due to an error on my part? How do I edit the build command arguments, or CMakeLists.txt, to get the functionality demonstrated here to work?
The very short (and only at the time of writing) answer is that you can't. CUDA 8 doesn't support VS2017. Only VS2015 is presently supported.
You can always find the compiler/IDE versions which the release version of CUDA supports here
Edit to add that the CUDA 9 release will add official support for VS2017.
All you need to do is set the CUDA_HOST_COMPILER variable to a supported compiler for example the visual studio 2015 compiler.
In my case this is:
C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/amd64/cl.exe
As both runtime libraries are binary compatible you can use the 2015 compiler within CUDA and compile all the rest of the application with the 2017 compiler.
My C++11 project is currently using CMAKE, XCODE, CLANG on OSX. I wish to compile this code on Windows.
Plan is to use the same cmake settings files on windows. Best case would be to use CMAKE to generate VS projects which uses Clang or gcc for C++11 .
Seems to me, that Visual Studio is just not going to fully support C++11 for a while. So we should all try to find a general solution for cross platform C++11.
How would one use CMAKE to generate projects/makefiles which would compile C++11 code on windows?
CMake's Visual Studio generator will always use the cl compiler of Visual C++.
What you request would require writing a new Generator for CMake. That is, the problem cannot be solved by writing a clever CMakeLists.txt, but has to be solved by adding a feature to the CMake core binary itself. I agree that this could be useful once Clang achieves a suitable level of Windows support, but at the point of this writing, it is probably too early for that.
You might want to take a look at the experimental compile-features mechanism for CMake. This is not yet part of CMake 3.0, but is planned to be integrated with one of the next releases. The idea is that you just specify which C++11 features you need and CMake takes care of configuring the compiler accordingly (or gives an error if the compiler does not support the feature at all).
You can create VS projects which use clang by specifying the LLVM toolset when you generate.
http://public.kitware.com/Bug/view.php?id=14863
Eg:
cmake.exe .. -T LLVM-vs2010
That sounds a stupid question, but I'm really curious about how to compile a DLL without using Visual Studio since I'm using Unity3D OS X for now. Is there some way like "tool chain" can do the trick?
Any solution is appreciated except Ask your friend/colleague to compile it for you or buy another computer/install windows/using remote control.
Build a cross tool chain of Mingw. However, be aware that you can not link C++ libraries between compilers, or often even compiler versions. Only DLLs with a C calling interface will work. (They can internally use C++ but must expose a C API.)
Or you could try running Visual Studio in Wine. VS2010 has bronze support in Wine, i.e. the compiler works.
My boss just asked me to integrate his bosses old Fortran code into a project (Java) I'm working on. The code was written in the 90s, so I imagine it'll still compile, so rather than re-write it, I'm hoping I can just call the functions from a .dll. I'm already calling some C .dlls, so I think I've got that part covered.
I've been doing some reading, and most of the articles talk about integrating the Intel Visual Fortran Compiler into Microsoft Visual Studio. We've got a university site license for Visual Studio, but it looks like the Intel Visual Fortran Compiler is in around the $700 range. I don't think my boss will go for that, so I'm looking for another option. I know Microsoft makes a lot of products freely available to students via Project Dreamspark, but I didn't see anything Fortran related.
I'm looking at some cygwin based options right now (g95, I think), but I'm looking for other ideas/options. Any ideas?
I've used the gfortran (g95) compiler with the -shared flag to create DLLs. first compile the .for/.f90 files with:
gfortran -c myfile1.f90
gfortran -c myfile2.f90
then:
gfortran -shared -o mydll.dll myfile1.o myfile2.o
MinGW will let you create a DLL that will work with your MS stuff.
Look for a GCC port to Windows, such as Mingw or GCW. Both those will create .obj files which can be linked to in Visual Studio. Or you could futz around and configure VS to invoke one of those command line compilers into the project. But since the code is relatively static, it might be a nice compile once and forget it task, hopefully.
Don't expect much help from Microsoft on Fortran.
They spent years trying to kill it off in favour of Visual Basic / C.
You could try Silverfrost's compiler.
http://www.silverfrost.com/11/ftn95/ftn95_fortran_95_for_windows.aspx
This is available free ('personal edition' version) and works with Visual Studio.
It's basically a F90/F95 compiler with a selection of later features included.
You did not say if the old boss' code was written in F77 or F90.
But I think that Silverfrost will handle the old code with minimal changes.
If it turns out well for you, there's also an academic version and an enterprise edition to move up to as desired.
The requirements listed in the 3ds Max SDK state that plug-ins for 3ds Max 2011 must be built with Visual C++ 9.0 (Visual Studio 2008).
If I create a DLL with a different version of Visual C++, won't the binary be identical? Is this simply a matter of choosing the right compiler settings?
What problems will I run into if I try to build a plug-in using Visual C++ 2010 (Visual Studio 2010)?
I don't know specifically for 3ds Max, but the usual reason is the C Runtime library. If the host application uses the DLL version of the CRT, then plugins will also need to use the same version.
Otherwise, imagine the case where your plugin creates some memory using malloc(), and passes it to the host application, which uses it and then calls free(). If your plugin and the host application are using different CRTs, the host's call to free() will fail or crash because it wasn't the host's CRT that malloc()ed that block of memory.
The binary won't be identical but the binary interfaces should be, which is what you need.
The reason you can't use VS2010 is because it is not yet production quality. They think you should wait for VS2010 SP1 at a minimum.
You think they are just being obstinate and stubborn, eh? Ruining all your fun. They have reasons. Good ones.
Because of bugs like this:
https://connect.microsoft.com/VisualStudio/feedback/details/565959
I use both visual studio 2008 and 2010 for plugin development.
Only difference I've seen is that the user need the vs c++ runtime version for 2010\2008.
But there might be pitfalls - but I have not encountered any problems with it yet.
C++ doesn't have a standardised binary interface. The compiler "mangles" each symbol name (i.e. each function or static data) to include information about namespaces and signature, so that namespaces, argument overloading, &c. can work. Each compiler is free to decide how to do this. Different MSVS compiler versions do name mangling in different ways, so in general you can't link a C++ library compiled with 2005 and a library compiled with 2008 together: this includes loading a 2008 DLL from a 2005 executable (for example). You can do this if the interface between the libraries is C, as long as the relevant functions are marked with extern "C" to prevent name mangling. And in practice the differences are not always that great: for example, I never had trouble using VS2005 SP1 to compile a library for 3ds Max 9, which supposedly requires VS2005 with no service pack.
Microsoft is trying to fix this incompatibility, so in VS2010 they introduced an option, so VS2010 can produce binaries compatible with VS2005 programs or VS2008 programs (maybe some earlier versions too, I forget). If you have to create a plugin to work with multiple 3ds Max versions, and you don't get caught out by any VS2010 bugs, this is probably a good option. Also, the Intel C++ compiler has a mode where it produces binaries that are compatible with an MSVS version of your choice, which might be a better option for you if it's for hobby use or you can afford the slightly expensive price tag. (They achieve this by copying the way MSVS does name mangling.)