Hi,
I have a cocoa app that I cant get running if I select “run w/o debugging”.
I see this in the console
2014-05-04 2:56:07.051 PM Fire[175]: xbuild /Users/JohnMoshakis/Documents/develop/Nougat/SailingLogIOS/SailingLogIOS.sln /nologo /target:Build /verbosity:normal /property:Configuration=Debug /toolsversion:4.0
2014-05-04 2:56:09.619 PM com.apple.launchd.peruser.501[160]: (org.me.SailingLog.100880[2255]) Job failed to exec(3) for weird reason: 13
2014-05-04 2:56:09.620 PM Fire[175]: 8837325: Attempting to SIGCONT to pid #2255 failed, with errno=#3, or the process failed to actually start
2014-05-04 2:56:09.621 PM Dock[191]: no information back from LS about running process LSASN:{hi=0x0;lo=0x51051}
2014-05-04 2:56:09.630 PM Fire[175]: 8837325: Attempting to SIGCONT to pid #2255 failed, with errno=#3, or the process failed to actually start
2014-05-04 2:56:09.641 PM Fire[175]: 8837325: Attempting to SIGCONT to pid #2255 failed, with errno=#3, or the process failed to actually start
2014-05-04 2:56:09.652 PM Fire[175]: 8837325: Attempting to SIGCONT to pid #2255 failed, with errno=#3, or the process failed to actually start
The message Attempting to SIGCONT… appears way more that I have shown.
Yes. works fine here. That said, please please try to not conflate issues. If you cannot run your app from Finder either then clearly it’s not the debugger at fault, and something else is going on. Do you get any log to Console when you run your app from Finder? Can you run it from the commandline LLDB?
$ lldb path/to/YourApp.app/Contents/MacOS/YourApp
(lldb) run
If I go into the .app folder for a cocoa application and look at the permissions on the executable inside Contents/MacOS visual studio doesn’t set it as executable.
If I open the same project inside Fire and do a clean and rebuild the executable bits are set.
Unless I do the clean and rebuild I can’t launch the debugger inside Fire.
Hmm. That’s with VS building from a VM to Mac local folder? VS cannot set +x itself, in that case (no such concept on Windows), but i’ve never had issues with that. what VM type are you using? You can run via CrossBox though, correct?
makes sense. the xbuild toolchain for the Mac has an extra step to set that flag.
i take it the issue are that VS and Fire are building into the same Bin/Debug folder, and Fire will run from there, while VS will run it from a separate copy that it uploaded via CrossBox. Technically, that’s “as designed” behavior. but i guess i could add something to Fire that it forces the +x flag on the exe, before it tries to run it.
I assume this affects only Mac apps, not iOS Simulator (and certainly not iOS Device), correct?
FYI I’ve seen stuff like this. I like to use BetterZip for handling zip files but I found that some stuff was getting unzipped with the execute flag off. These days I unzip your compiler stuff using the built in archive utility and I haven’t had any problems. (E.g. Once the install.sh in your compiler zip was not executable until I ran chmod).
FWIW, next Fire build will have the “for building” compiler embedded, and will no longer require either Mono or the command line compiler to be installed separately.
That’ll be a lot more convenient to get people up and running initially. But that’ll preclude our updating the compiler ourselves between actual Fire releases, right? (Or will it still be possible to drop new compiler bits inside the Fire package?)
There’s two versions of mono, and of the compiler, involved currently.
Fire.app has a custom-build 64-bit version of Mono embedded, that it uses to host the managed code that drives IDE smarts — CC & co. But to build your project, it just calls /usr/bin/xbuild — which uses the “installed” mono version, and the installed compiler (that you install from the zip via install.sh.
In the next build, no more, Fire wil use the embedded compiler and Mono to build. So you can now copy Fire.app to a clean Mac and just hit Build and everything works. (there’s an option to still use the external compiler & Mono if you prefer).
that’s assuming you’ll have a way to get a newer compiler, anyways. I;m pretty close to having Fire’s build integrated with our core build system, which means every build we do will spit out a matching Fire.app as well.