I am developing a plugin for a third-party host application on MacOS that compiles as a .dylib (with associated DSYM directory). The .dylib and DSYM directory is automatically copied to the host's plugin directory by a supplied build script. The build script uses clang to build the .dylib. The host application is able to open the plugin.
With Xcode, I am able to debug the .dylib with lldb within Xcode, because Xcode is somehow able to identify that the sources match the dylib once it is loaded.
I wish to set up a similar system with CLion, however I have not been able to get CLion to associate the breakpoint lines in the source with the dylib. When I create a breakpoint in the source it warns me that "Breakpoint will not currently be hit. No executable code is associated with this line". I almost expect this kind of warning because the image hasn't been loaded into the host application yet. However loading the plugin does not trigger the breakpoints.
I tried setting the Configuration's Executable to the .dylib, and setting the working directory to the location of the .dylib and the DSYM directory (this is what I have to do when running lldb manually), and this does not seem to help.
My questions are:
Does CLion use lldb internally?
Is what I am trying to do possible with CLion?
If so, what is the correct configuration for this situation?
One important thing to note is that I am not building the .dylib with CLion directly, it is build by an external build system, I am just trying to debug the resulting image with CLion, which I understand should work (it works with Xcode & lldb at least). I have a basic CMakeLists.txt that is sufficient for CLion to understand the code base, but it is not used to build it (beyond any background compilation that CLion might do to check syntax etc).
I downloaded bitcloud, the atmel zigbee stack and I am trying to compile one of the default applications, ZLLDemo.
It is located currently at:
C:\Users\Ryan\Desktop\BitCloud_MEGARF_3_1_0\Applications\ZLLDemo\atmelStudio_projects\ATmega256RFR2.cproj
Everytime I try to compile the application I get a windows message screen for "mkdir.exe" error 0xc0000142. In the Output screen I see the line "make: *** [directories] Error -1073741502"
This same error and error code occurs later in the build process for cp.exe if I manually make the folders myself.
I have tried the following things to fix the error:
Change folder and contents to different owners, everyone having full
privileges
run make command manually from a command prompt window as admin
clean solution before retrying
all other examples files
ran directly from C: as "C:\BitCloud_MEGARF_3_1_0\Applications\ZLLDemo\atmelStudio_projects\ATmega256RFR2.cproj" - as per general suggestion for the windows error I tried
"sfc /scannow" in case mkdir had somehow been corrupted
Changed AppInitDLLs Reg key to 0 to load all DLLs at start of application
Disabled Internet security
Does this have a general fix or is there perhaps something else at work here? General compilations work, its just external ones. My friend did the same and it seems to work just fine for him.
Windows 8.1
Atmel Studio 6.2
Avrfreaks had a solution that I finally found here.
Their solution is to download an old version of the msys file for winavr. Which means that their is something more than likely wrong with the latest version of winavr for windows 8.1
sebastor wrote:
I found solution.
Copy this file:
http://www.madwizard.org/download/electronics/msys-1.0-vista64.zip
to utils\bin directory (WinAVR)
I have been using MinGW and the GNU Fortran compiler for a while in order to compile Fortran programs on Windows, which has always been a successful method. However, I have been getting the following error for the past 4 days:
The application was unable to start correctly (0xc000007b). Click OK to close the application.
The error only happens when running applications that I wrote myself, and that I compiled using the MinGW/gfortran combo. When compiling using Visual Studio and iFort, I have no problem running the applications. The error seems retroactive: applications that were compiled using gfortran a long time ago and ran perfectly until now also break, even though I didn't recompile them. This leads me to think that it is a dynamic library problem. Online searches show that it probably is a compatibility problem between a 64-bit dll and a 32-bit application
I am using Windows 7. One of the latest things I remember doing before starting to get the problem was trying to update MinGW ; I used the mingw-get update and mingw-get upgrade command lines.
After looking around online, I have tried the following fixes:
- reinstalled the Visual C++ Runtime Environment
- reinstalled the .NET framework
- downloaded and replaced a bunch of .dlls like mscvr100.dll, mscvr100d.dll, etc...
- uninstalled and reinstalled MinGW in order to make sure I had the latest gcc version
- run Dependency Walker on a simple application ("Hello World!" type program)
Dependency Walker tells me that a number of .dlls cannot be found (full list: API-MS-WIN-APPMODEL-RUNTIME-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL, API-MS-WIN-SHCORE-SCALING-L1-1-1.DLL, DCOMP.DLL, GPSVC.DLL, IESHIMS.DLL).
It also highlights in red the libquadmath-0.dll (on which libgfortran-3.dll seems to depend). Indeed, it seems that libquadmath-0.dll is a 64-bit DLL in the middle of a 32-bit program. When opening said .dll with Dependency Walker, I can see that all the modules in this library are x86 except the library itself which is x64 (CPU column of DW). I am not exactly sure how this is possible / how to fix it. The library is found in the Python/Anaconda folder (I installed Python and Anaconda a few weeks ago, the problem did NOT appear at that time).
If anybody has an idea of how to get my environment to work again without reinstalling Windows, I would greatly appreciate it! Thanks!!
I had a similar problem. Looking at Dependency Walker I wasn't loading API-MS-WIN-CORE entries. However, when I went to edit my path it turned out that by bin folder wasn't on the path. Adding, in my case the mingw64 bin folder to the path fixed this issue for me. I only mention the API-MS-WIN-CORE entries since I thought it might be the problem, but in reality it wasn't causing my issue.
I was getting this same error code, and used Dependency Walker to discover that, in my case, the 64-bit version of libwinpthread-1.dll was not being found. This helped me resolve my issue.
So, the solution is to determine the missing dll, track it down on your system and reference its location in your path variable, or find out how to install it if you don't have it.
That said, I also came across the following caveat that's important to know about when using Dependency Walker. It's currently out of date and will actually show false results for WIN-CORE dlls: https://stackoverflow.com/a/36244483/4438237
To work around this, there's a newer program called Dependencies by lucasg, that properly interprets these and won't mistakenly tell you about these falsely missing dlls.
I was getting same Error, as mentioned in above answers the problem is "path not being set" aside from setting path you can alternatively Do this; if u don't want to set the path for some reason:
Open CMD
cd C:\MinGW\bin to navigate to the bin directory of mingw
now u can compile the code as following Gcc (dir of ur .c file) -o (ur output dir) for ex : gcc I:\dir\Hello.c -o I:\dir\output.exe
alternatively if u want to automate the process u can make a batch file to automatically do it for you.
here's the batch file if anyone needs it
#echo off
C:
cd \MinGW\bin\
gcc I:\dir\*.c -o "I:\dir\Output.exe" Rem Replace "dir" with your own directory and * with ur own FileName!
pause
I had a similar error but over came it by editing my environment variables.
I had g77 as part of my path variables and by removing it and leaving gfortran alone, the error disappeared
I was on Windows 10 using cmake-gui to generate a MinGW-w64 project and meet same problem.
My solution: go to start windows, search and open MinGW-w64 terminal, then in terminal call cmake with specifiying cmake options.
Yes the old posts got it right. It is the environmental parameters messed up. I got the same error. It is solved by putting the msys64 path to the first:
Path=c:\msys64\mingw64\bin;%PATH%
The msys64 path was the last, now it is the first. Type it once at the command line after Windows started, or edit the Path environmental parameter if you have the admin right.
I am doing C development using Netbeans on OS X and my project fails to build, stating "...this installation of Open MPI was not compiled with Fortran 90 support"
I have installed a newer gcc and Open MPI (along side the default versions), and I can build using them via make on a command line. This leads me to believe that Netbeans is using the default Open MPI installation (which did not have fortran support). If I am correct, how do I get it to use the new installation? I told Netbeans about the other compilers via the Tool Collection Manager (File->Project Properties->Build->Tool Collection->[...]). However, I do not know of a way to tell it about Open MPI.
I have a working solution. This solution exists in two parts.
1) I reran configure on the command line for my project and specified full paths for MPICC and MPIFC. This solved the problem of getting Netbeans to use the right mpicc compiler. However, it created another issue: the mpif90 wrapper could not find gfortran.
2) I altered the 'GUI environment' PATH variable to put gfortran in my path using the /etc/launchd.conf method found here (http://stackoverflow.com/questions/135688/setting-environment-variables-in-os-x).
After a reboot, Netbeans compiles my project. So, I'm claiming success.
I need to step through the Qt code to help solve a bug in my C++ application. I've downloaded qt-mac-opensource-src-4.5.2.tar from here and followed the install instructions that came with this:
unpacked the file to /tmp.
typed ./configure -debug.
typed make.
typed sudo make install.
edited the PATH environment variable as instructed.
set the DYLD_IMAGE_SUFFIX environment variable to _debug.
This installed Qt and my Qt application runs, but I still can't step into the Qt code.
I'm using Xcode 3.1.3 and tried changing the Executable Info to "use debug suffix when loading frameworks". This generated a lot of warnings like:
warning: Could not find object file "/private/tmp/qt-mac-opensource-src-4.5.2/src/corelib/.obj/debug-shared/qmalloc.o" - no debug information available for "global/qmalloc.cpp".
warning: Could not find object file "/private/tmp/qt-mac-opensource-src-4.5.2/src/corelib/.obj/debug-shared/qnumeric.o" - no debug information available for "global/qnumeric.cpp".
and also a lot of non-qt related warnings.
I'd shutdown the Macbook Pro overnight, which I can only assume clears the tmp directory as the unpacked file is no longer there.
I think I could fix it by rebuilding Qt without frameworks, but this is more of a work-around than a fix that will probably come back to bite me. I'm also a bit reluctant to do this, when each rebuild takes between 3 and 4 hours.
Alternatively, would downloading the binaries and debug libs work?
I'd be grateful for any suggestions on what I'm missing and how I address this.
Thanks.
With the help of Qt support, I've now resolved this.
There were a couple of issues:
The Qt debug "make install" doesn't currently generate dSYM files for the _debug stuff. They've raised a bug about this. To get round this:
4a. cd /usr/local/Trolltech/Qt-4.5.2/lib
4b. Type /usr/bin/dsymutil -o QtGui.framework/QtGui_debug.dSYM QtGui.framework/Versions/4/QtGui_debug
4c. Repeat for each Qt framework.
The tmp directory does indeed get wiped on each reboot. To get round this:
7- Copy the entire contents of /tmp/qt-mac-opensource-src-4.5.2 to a new directory ~/Qt .
I also added both the frameworks and source code to the Xcode project.
Have a look at this http://doc.trolltech.com/4.5/debug.html
There is a section especially for debugging under MacOSX and Xcode...
I guess you need to generate a makefile with debug option using qmake !
In OS X 10.6 and 10.6.1, setting DYLD_IMAGE_SUFFIX to _debug will cause problems. Hopefully this will be addressed by a future update of OS X 10.6.