Need help with MingW64

[sprange]

I am currently evaluating VisualGDB as a potential -big- time saver for a current (non commercial) task. There is a GCC based project that compiles fine in cygwin but I’d like to remove its dependency on cygwin.dll and possibly create a static library for use in other programs. The code is VERY GCC centric and will take a lot of effort to make it compile with Microsoft’s C compiler. Intel’s compiler does slightly better, but the easiest route will be compiling it with Mingw64. To this end I’ve installed VisualGDB into my VS 2013 Pro but I’m having difficulties.

Somewhere in the online documentation it states that I need MSYS installed (which I do), but I have no idea how to configure GDB so that the makefiles are executed within the MSYS shell. I end up with build failures because other programs (rm, mv, grep/etc/etc) cannot be found. Most of these have Win32 ports that I could include in the system path but I’m not sure what to expect. Regarding my toolchain I’ve tried the downloaded mingw64 version, my msys-mingw64 builds 4.9 version, etc all with the same result (build failure due to makefile). Am I doing something wrong or am I expecting too much from importing a Makefile? Thanks!

Sean

[support]

Hi,

The easiest thing to start with would be adding the msys binary directory to PATH when building your makefile (this can be changed on the Build Settings page in VisualGDB Project Properties). That may still require some additional tweaking, e.g. if your Makefile expects the output of ‘pwd’ to have a /cygdrive syntax.

[sprange]

Thanks for the reply. I’ve tried a few alternatives to VisualGDB but I think this program is a winner. I tracked down a few problems relating to the verification of the tool chain. I’ve learned that it’ll complain even if there isn’t a problem. For example if I have something like this in the library path of the setup window

(in Configuration Makefile Settings)
Library directions: something$(BINARYDIR)
Library names: something

The test will fail to find libsomething.a but if I ignore the toolchain error I’ll be able build and link against libsomething without a problem.

I’m still having problems with large projects that have multiple executables in the same directory. I either have to use a solution with many different projects (each in their own directory which is not convenient), or I need to master the VGD makefiles. I find it difficult to have more than one target in the makefile. I really wish I could just use the ones in the project (with some modifications) but that is challenging too!

[support]

Hi,

The include/library directory settings do not support any variables. They do support relative paths, however.
If you want to reference a VisualGDB library project, simply add it to the build dependencies of your main project and VisualGDB will figure out the path to the binary automatically.
We don’t support multiple targets per project as it would make some things overcompilcated (e.g. project references or mapping of source files to targets) and it’s not supported by normal Visual Studio projects. You can instead use one of the following workarounds:
1. Create several VisualGDB projects in different directories
2. Manually edit the makefiles to add more targets (you will then have to manually track which sources belong to which targets)
3. Create several VisualGDB projects in the same directory and override the Makefile name for them (e.g. Makefile2 instead of Makefile).

[Author]

Posts