This question has been asked before with prior Xcode versions:
Their solutions were:
Remove armv7 from Valid architectures
Change debug information format to DWARF instead of DWARF with dSYM File
I have tried all of these but the archiving still gets stuck at a particular task, always the same task number.
I have looked into the report navigator, and their are issues. But just warnings. There is one error "FontAwesome" build target, which doesn't say much. But the app use to build with version 10.1
For those that come across this issue, it was because of FontAwesome. I had installed it via CocoaPods. Not sure what the issue was, but I manually installed it into the project and it resolved the issue.
I was able to work around this by EITHER changing my Optimization Level in Release to "No Optimization" OR by changing Compilation Mode from "Whole Module" to "Incremental".
Upload using Xcode 10.1 instead of Xcode 10.2.
Related
Does anyone know what this error means?
I'm working with Netbeans 8.0, gdb 7.8.1 on Linux Machine. Everything was good until two days ago, then I suddenly started to get this error when i'm starting t debug and I have no clue what it means.
So far, I'm trying to clean and reset everything I could think about: reinstall netbeans, clean all local files, rebase my code again, unset all breakpoints and so on and so on.
Could anyone please help me to understand what this error means? I've never set those breakpoints, where does Netbeans take themfrom?
Thanks in advance,
Rachel
EDIT
So now I have a bit more details:
When I'm trying to debug my app directly with GDB, without netbeans I'm getting the following error:
Starting program: ....
warning: Selected architecture i386 is not compatible with reported target architecture i386:x86-64
warning: Architecture rejected target-supplied description
Warning:
Cannot insert breakpoint -1.
Temporarily disabling shared library breakpoints:
breakpoint #-1
Cannot insert breakpoint 1.
Cannot access memory at address 0x8081527
how can I figure out what code\flag in compilation makes my app to be i386? how can I force it to be x86_64?
Thanks again.
OK, the gdb installation on my machine was screwed.
There's no chance anyone could imagine it. I moved to another machine and everything is good now.
This error could appear when you try to use WSL gdb on non-WSL app.
I think you updated the system and the latest version of the glib is not supporting 32bit applications.
Can you do a find to find out which files in all the bin and lib directories on your system were changed within the last 2 days? If it used to support it, but the upgraded version doesn't, then the application which was (probably without your knowledge) compiled to be 32-bit will not be a valid target for all the standard tools on the box.
You specify the target architecture with -m32 or -m64. See if you can specify it explicitly if you are compiling and debugging on different machines.
I have OSX Yosemite 10.10.5, QtCreator 4.1.0, Qt 5.7.0 and Xcode 7.2.1.
If I write any native C++ program in QtCreator (console, gui - anything) I am unable to debug that program from QtCreator. Breakpoints get ignored, the program executes without pause and runs to completion no matter what I try.
I have tried the Xcode's LLDb, system GDB and Homebrew GDB as debuggers. the versions of GDB fail to start. Homebrew GDB has been codesigned.
This all used to (a few year back) just work beautifully and I am at a loss as to what might have changed.
Curiously, if I generate an exception inside the program - like accessing through a null pointer, the debugger shows me where this happens in just the way I would expect so, presumably, the debugger is running but simply treating me with complete disdain.
I know there are many versions of this question but none seem to address the problem adequately or offer workable solutions, or they apply to much older versions of the products.
Any suggestions?
This version of qtCreator (4.1.0) saw the return of the warning about having the build directory at the same level as the project directory. In Windows, this is done automatically. My mac installation does not get it right. (I may have messed a while back - cannot remember).
So - if the build directory is inside the project directory, debugging fails. Move the build directory up to the same level as the project directory and everything seems to work fine.
You can set the default build directory in the preferences/Build & Run dialogue. The path should start with ../
You will need to think about the folder structure before setting up the project unless you want build folders appearing in awkward places. So, a project folder structure like this is OK:
But one like this is not:
If this was already obvious to you, great. I have been messing with this for ages.
Many thanks to those who replied and anyone else who took the time to read the question. What helped e find it was the suggestion by #AlexanderVX that his setup was the same as mine but his worked. The only bit of my setup he could not see in the screenshots was the start of the build path. So that was the clue.
I set up OpenCV with Code::Blocks as per this tutorial: http://kevinhughes.ca/tutorials/opencv-install-on-windows-with-codeblocks-and-mingw/.
I've got as far as building the test program at the end successfully, but when I try to run it I get the following error: "The application was unable to start correctly (0xc00000be). Click OK to close the application."
The one thing that is certainly different from the tutorial for me is that I'm working with OpenCV 3.0.0, Code::Blocks 13.12 and the latest version of mingw (number not obvious from their website or the installer).
I found that other people had had this problem in the past, e.g. The application was unable to start correctly (0xc00000be)
However, it has been a long time since that thread was active, I'm working with newer versions of the software and, most importantly, the answer given there didn't help (I compiled openCV with the same mingw that I'm using with Code::Blocks), so I thought this question would be worth asking (sorry if it's not, I'm rather new to this).
Could anybody suggest a fix that might get rid of this error?
A few other things to note:
I didn't download the Code::Blocks that came with mingw as I was advised against it, I got them separately as per the tutorial
I have installed OpenCV and Code::Blocks on my E: drive, though mingw is still on my C:.
I have added both mingw and OpenCV to my PATH variable, and mingw to my Path variable
I have linked the libraries in both the main compiler settings for Code::Blocks and the Build Options of my project.
I'm working from a 64-bit Windows 7 Laptop, but I have done everything 32-bit style as advised in the tutorial.
Thanks in advance!
So, one solution I've found to this problem is to copy all the .dll files from "...\opencv\build\x86\mingw\bin" to the project file (build directory).
Having done that, the project will run fine. This still doesn't (directly) explain why it wont run without those files (at least, several sources including the tutorial imply it should), and so isn't really optimal. I will continue to look for a solution for this so I don't have to clutter every opencv project I make with the .dlls.
However, for anyone simply wanting to get stuck into coding who is having this problem, I recommend that solution.
I'm writing a C++ application using VS2010 on two dev computers - both are Win7 64bit SP1. I use git to sync the repositories.
On one of the machines the compiled executable (and also the test exec) stopped working with the following error, while on the other machine it works fine and I'm able to continue development.
The application was unable to start correctly (0xc000000d). Click OK to close the application.
I tried deleting the repository and cloning it again. I also made sure I have the same versions of Boost, git, Visual Studio. Also, I tried debugging (stepping in) but the error occurs before any line of code is reached.
Notice as far as I understand I'm tracking Visual Studio's solution\project configuration files as detailed here.
I'm at a loss, how would you debug this?
UPDATE 1:
Only the Debug version fails to run. The Release version runs fine
UPDATE 2: The executable that doesn't work does work on the other computer!
UPDATE 3: I've reinstalled VS2010 (exactly the same version) - didn't help. Surprisingly the compiled files are not the same size between the two machines.
I got the same problem as you mentioned.
My solution:
Clean the manifest file and rebuild
In the property page-> Manifest tool -> make sure "Additional Options" is set to nothing.
(I set it as "/validate_manifest" before).
Or you can try "Embed Manifest -> NO", rebuild and then set back to Yes. It sounds to be ridiculous, but it really works sometimes. I don't know why.
I got the same phenomenon suddenly without a warning on Win7 / VS2010 / C++. Debug App couldn't be launched, got 0xC000000D at initializing and loading multiple dlls. Found one base dll of my own responsible, played around with linker settings. Modifying settings, incremential rebuild -> app starts, rebuild all -> app crashes again. After setting "generate manifest" to "no" in the linker settings the sample app works, but the main app still crashes. After setting "generate manifest" to "no" for the most of my dlls -> the app starts in debug mode again. The stuff is very spurious, because some dlls need the modified settings others do not.
Have a look at the top two answers to this question
Program crashes with 0xC000000D and no exceptions - how do I debug it?
On the machine where it fails, try running the debug executable NOT under the debugger, and update your question to say what happens. If it crashes, are you able to then attach the debugger whilst the message box is still there and get a stack trace that tells you what function it is crashing in?
This is the weirdest thing....
Try deleting the "ipch" directory and then rebuilding.
Hope it works for you, I have wasted hours on this.
disabling/enabling precompiled headers fixed the issue for me.
I was facing crash on Debug x64 only - I guess it was related to an upgrade from boost 1.50 to 1.52, while keeping pch files.
in my case i got it working again by setting generate manifest to NO on all projects
I have changed "Embed manifest" setting to NO and then back to YES but it didn't help.
For me setting General->Platform Toolset to Windows SDK 7.1 for my program and all dependent libraries compiled with it helped.
It's the ipch just delete the entire folder and it will clear it up. I was confused for a while too.
I saw the error while using OpenCV library compiled with MSVC2010 in a project running on MSVC2015. Changing project configuration properties->General->Platform toolset from Visual Studio 2015(v140) to Visual studio 2010(v100) resolved the error.
I’m porting a C++ sdk from Windows to Mac OSX 10.5. I have a problem in Xcode where my breakpoints in certain files will only be hit if I set them while debugging. If I stop debugging and then restart, the breakpoints no longer get hit. If I add them while not debugging, they don't get hit. This is only in certain files and my breakpoints are always dark blue. i.e. I can’t tell the difference between a breakpoint that will get hit and one that won’t.
Specifically, my sdk is made up of various dynamic libraries. These are built using Perforce jam, which calls the various compile and link executables depending on my OS and compiler version (such as Visual Studio’s cl.exe and link.exe). I have a simple (unit testing) command line application that links to these dynamic libraries and calls code in them. This application on Windows is a Visual Studio project, in which I set breakpoints on library code and expect them to be hit.
I’ve created the same C++ command line utility application in Xcode 3.1.2 that links to the sdk dylibs and calls code in them. Some of the breakpoints work fine. I can set breakpoints in code that’s called from the troublesome code, and step out to the troublesome code, which I can then step through fine. The troublesome code is compiled into the same dylib as code that works fine. It’s also long and complicated enough not to be a candidate for inlining.
I’ve tried the following:
Turn Load symbols lazily off.
Compile with both gcc 4.0 and gcc 4.2.
Do a full clean and shutdown.
Delete the user-specific files of the xcodeproj package.
Rename the files so they can’t clash with system files.
Clear everything out of the Breakpoints window.
Create a new Xcode project.
My application is compiled in debug with DWARF format and my libraries are built with the –g flag (along with –v, –arch i386 and –fvisibility-inlines-hidden).
Help would be much appreciated. Thanks.
Update: sorry for not updating this, my Mac port project was postponed. I never resolved this, but discovered that it actually only occurs in constructor bodies. I'll revisit this as and when I hit the problem again.
Have you tried these?
Why aren't my breakpoints working?
Not really an answer: You should make a bug report in the official Apple bugtracker. The chances are high that you get an answer sooner or later there - or perhaps it is really a bug.