I have a Visual Studio 2012 solution containing several projects, some in C and some in Fortran (using Intel Composer XE 2013). I frequently call from the Fortran code into the C code using the iso_c_binding utility, but I've noticed that I cannot debug the C code effectively. While debugging the Fortran code, I can view the contents of variables just fine, but if I step into the C code, suddenly they lose their sanity. Most variables just claim to be undefined; anything passed to the function will contain incorrect values (but it still does differentiate between pointers and objects/POD).
I can still step through the code; it seems to mostly follow the expected sequence of execution, but sometimes it does jump around a bit, which I'm familiar with from debugging compiler-optimized code on Linux with gdb.
I have a separate solution that also has C and Fortran projects. Both call into the same C project from the first solution, and in both cases, I can again debug successfully until I step into the C project from the first solution, at which point I have the same problems.
What am I doing wrong?
This is the standard bat signal for debugging code that was optimized. You'll need to rearrange you build settings so your Fortran code links to the non-optimized Debug build of the C code.
There are no breadcrumbs in your question as to how that went wrong in the first place. Start by checking which library is getting linked into your Fortran program and make sure that you can see distinct libraries generated for your C project in the Debug and Release builds. You need to link the one created by the Debug build.
Related
I have no experience with C/C++. I do not know how to even open files. I am working with SLN files in Visual Studio 2019 trying to compile a program I took off of GitHub (https://github.com/Marlowe97/Expected-Force).
I get these two errors (LNK2005, 'main already defined in TestExpectedForce.obj, and LNK1169 'one or more multiply defined symbols found') when trying to compile the Expected Force solution. The only changes I've made from the downloaded files are the ones directly stated in the instructions on the GitHub page of the program.
Is there someone who can tell me what to look for in as plain of a way as possible? I know basic Python and R so I understand some terms, but I know nothing about C so no other posted solutions to these errors make any sense to me. I'm already pretty concerned that I'm getting errors after following the step by step instructions from GitHub on what seemed to be a pretty basic task.
It's a strange package...
The functionality is provided as a library, to be compiled into your own project.
There are TWO test source files: TestExpectedForce.cpp and TestExpectedForce.cpp, each of them contains main().
They should be in their own projects (possibly, under the same solution).
To quickly move forward, just remove one of the test files from your solution.
Many language environments allow one to "disassemble" a provided function. Since Pypy compiles to C-code (if I understand things correctly). then it seems natural to be able to see a C-code dump from an expression, or a whole python file.
Can I do this? how?
PyPy does not compile python bytecode to C code. The tracing JIT replaces a frequently used piece of code with generated machine code (assembly). You can turn on logging to save the JIT traces to a file and view them with vmprof or jitviewer.
It seems I've got a real problem here due to my lack of any knowledge about Linux systems:
I have downloaded some open source code, which
is written in C
uses complex.h, so I assume it is ANSI C99
comes with makefiles designed for compilation under Linux systems
provides interfaces to IDL, MATLAB, Python etc.
I am indeed familiar about compiling C/MEX files under Windows-based MATLAB environments, but in this case I don't even know where to start. The project is distributed in several folders and consists of dozens of source and header files. And, to begin with, the Visual Studio 2010 compiler I've used to compile MEX files until now does not comply with the C99 standard, i.e. it does not recognize the complex.h header.
Any help towards getting this project compiled would be highly appreciated. In particular, I have the following questions:
1) Is there any possibility to automatically extract compilation information from the MEX files and transfer it to Windows reality?
2) Is there any free compiler being able to compile C99 stuff, which is also easy to embed in MATLAB?
I have done this (moved in-house legacy code inc. mex files to Win64). I can't recommend the experience.
You will have to recompile, no way around it.
Supported compilers for mex depend on your MATLAB version
This File Exchange entry for using Pelles C may be a starting point (if it works with your version of MATLAB).
I am guessing that there is a main makefile which then works through the makefiles in the subdirectories - have a read through the instructions for compiling under Linux, it will give you some idea of what's going on and may also discuss what to do if you want to change compiler. Once you've found a compatible compiler, the next stage is to understand what the makefiles are doing and edit them accordingly (change paths, compiler, compiler flags, etc.)
Then, from memory (it was a while ago), you get to enjoy a magical mystery tour through increasingly obscure compiler errors. Document everything because if you do get it working, you won't be in a mood to do this twice.
MATLAB R2016b on Windows now supports the MinGW compiler. I'm successfully using this to compile code written primarily for Linux/gcc. I installed this from the Add-On menu in MATLAB (search MinGW).
For my case, I'm building with the legacy code tool. The only thing I needed to do differently than normal was to tell the compiler to support c99 via a compiler flag. This does the trick:
legacy_code('compile', def, {'CFLAGS=-std=c99'})
I had trouble getting the flag command just right (I had some extra quotes that apparently broke things), and asked The MathWorks, so credit is due to their support team for this.
If you are using mex, I would expect to do something very similar.
I would guess that the makefiles are irrelevant for your application; you will need to tell the mex or legacy_code function about all of the files necessary to build the whole application or link against pre-built libraries (which it sounds like you don't have).
I hope this helps!
I am working with C code functions that call legacy Fortran code subroutines. The Fortran code subroutines also call other C code functions. The code that I am working with is not the prettiest, but it is fairly challenging to re-write everything from scratch.
Unfortunately, a segfault is occurring somewhere within the program, and I am wondering if there is a software tool with a nice GUI that can be used to accurately pinpoint the location in both C and Fortran code.
Although I am developing the software program on Windows using the Open Watcom compiler to compile both C and Fortran code, I'm willing to move the code to my GNU/Linux box if there is a FOSS tool that can be used.
Alternately, I would wonder if the Intel Composer XE suite could be used to visually pinpoint the location of the segmentation violation. The Intel Composer XE suite includes both C and Fortran compilers.
Since I am working with C and Fortran code, I need some sort of indication where in the code the segfault is occurring. I don't especially want to use calls to the printf() function.
This isn't a GUI, but valgrind is an excellent memory debugging tool. It will tell you not just which line a segfault is on (which you should be able to do with any debugger), but also each time you access uninitialized or unallocated memory, or make a variety of other errors. You do need to port to Linux to use it though.
The Visual Studio integration provided with the Intel Visual Fortran product on Windows allows GUI debugging of mixed Fortran and C code.
On Linux Intel ship their own GUI based debugging environment (idb) with their compiler products.
I hope the answer to this question isn't too simple or obvious. I've been trying to get used to using a text editor and MinGW to compile some C code but I've found that I can't quite tear myself away from Visual C++ (mostly because of the IDE). The thing is, I've never used Visual C++ to just compile C/C++ into an executable; I always used the debugger and ran the program from inside Visual C++.
I just want to compile my program into a simple executable. How do I need to set up Visual C++ 2010 Express to do that? Don't I just set it to release mode and compile? Is there anything else I need to do (any settings I need to change)? Thanks.
If you've run the program in the debugger, then you've already compiled it!
Just find the executable in the correct folder. If it's a debug build, it'll be under Debug/, similarly for Release/
Note that you can't distribute a debug binary because it depends on the debug CRT which will only be available on a machine with VS installed.
If you just want to run existing code that you have written then you can compile in debug or release mode in Visual Studio. You code will be compiled into an executable file that you can find in the Debug or Release folder in your project. Just double click this file to run it.
Now, if you compiled the debug version, it will be much bigger that the release version and it will (probably) link with debug versions of the C runtime and other VS DLLs. It will still run independently of the debugger though.
It is a common mistake to release or test an application that has been compiled in debug mode. The debug builds often don't expose some bugs as they run more slowly and the executable code is not optimised by the compiler.
If you want to write C appilcations, you can still use Visual studion - just write your code in files that you save as file.c not file.cpp. The compiler will figure it out.
If you want to write C code with a different IDE/compiler, I'd recommend Eclipse as an IDE and GCC as the compiler. MinGW is generally used to build applications that are targeted at Linux, you don't need it if you just want to write in C for a Windows platform.