I have a Xcode project for library arith.
I could build it with debug configuration, and I need to debug it. How can I do that?
The ideal method would be to set up a test code to build an execution in a project file, and then set a breakpoint in a source code in arith library.
However, it seems that Xcode arith project doesn't allow to add another use_arith project that uses the arith library.
What method people use to debug a dynamic library in Xcode?
ADDED
I googled and found some ways to debug dll. Attaching to a running process can be one way of debugging dynamic library. And, for iPhone/iPad programming dynamic library is not allowed, so static library is used.
Attaching to a Running Process - http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Attaching-to-a-Running-Process.html
Debugging a library with Xcode - Debugging a library with Xcode
Easy, Modular Code Sharing Across iPhone Apps: Static Libraries and Cross-Project References - http://www.clintharris.net/2009/iphone-app-shared-libraries/
I could find a way to debug dynamic library in Xcode.
Build
Make a library, I'll call this arith library. Debug build to make libarith.dylib.
Make a project to use the library, I'll call this usearith.
For userarith, Project->Add To Project, and add the arith library.
Open Project info, and open the Build tab.
Go to Search Paths/Library Search Paths, drag and drop the arith library. You should remove the library name as you need only specify the path. Specify the header directory with 'Header Search Paths'.
Go to Linking, set Other Linker Flags, add -larith
Running
Now, you should be able to link the execution binary to the library.
For running, you need to copy the dynamic library to the directory where the execution binary is located.
Debugging
You need to set the breakpoints both arith/usearith.
You can run debugger in arith and use the step into to debug the code in a arith project.
I faced the same problem and no one of the previous answer worked for my case so I share my solution (for Xcode):
If you need to debug a c/c++ dylib which is loaded by an external (executable) program:
First be sure that your dylib is build with the same architecture as your external program.
Then Go to --> Product —>Scheme—>Edit scheme
Got to Tab Run(Debug) and check "Debug Executable" , then select into the dropdown button your external program as executable. Then check "Launch Automatically"
Additionally if you program needs extra argument you can add it into the
"Arguments" tab.
Finally you set some breakpoints to your c source file and finally click run.
Related
I am attempting to start a new project in Code:: Blocks (v17.12) using WxWidgets (v3.1.3) on Windows (10).
(For context, I am new to compiling- I'm a script coder trying to branch out. So... don't be afraid to talk to me like I'm an idiot. I'm prepared to accept that possibility.)
I downloaded the official 3.1.3 source, expanded it to "D:\code\wxw"
I successfully compiled it using mingw32-make that came with Code::Blocks-- there is a directory "D:\code\wxw\build\msw\gcc_mswudll" and "D:\code\wxw\lib\gcc_dll", the latter containing .dll files.
So I go into code blocks, and I:
Create New Project -> wxWidgets Project
Select wxWidgets 3.1.x
Project Title "HelloWorld", under D:\code\C++\tinker-- everything else autofilled.
Project details-- my info.
Preferred GUI Builder - None. Application Type - Dialog.
wxWidgets' location: D:\code\wxw
Compiler: GNU GCC
Selected "Create Release Configuration" because that's how it was compiled.
It provides an Output dir of "bin\Release\" and an Objects output dir of "obj\Release\", which I do not change.
Selected use DLL, built as monolithic, and enable Unicode-- the latter matching my compile settings.
When I click next, it tells me "A Matching Release configuration cannot be found in the wxWidgets directory you specified. This means that the Release target of your project will not build."
I've found multiple hits searching on this error message, but they all devolve into discussions of monolithic vs polylithic compiling and critique of other compiler settings and not actually addressing the problem.
EDIT:
Based on http://wiki.codeblocks.org/index.php?title=WxWindowsQuickRef
I used the following settings for compiling. I set them in config.gcc
BUILD=release SHARED=1 MONOLITHIC=1 UNICODE=1 CXXFLAGS=-fno-keep-inline-dllexport
The most important page of the wizard is the 8th page. Based on the settings you gave above, it should look exactly like this:
Also, instead of giving the path on the 6th page, I would define a global variable named wx in codeblocks like this:
Then on the 6th page, you would enter $(#wx) instead of the actual path. This will make using your projects much easier if you ever upgrade the wxWidgets library. You'll only need to change the location in the global variable settings.
I want to force Xcode to use a custom compiler ('clang-llvm' build from the src) so I can use the clang plugin. My Xcode version is 7.3.1.
People say it is possible with custom toolchains. I didn't make a research on them because easier solution worked well for me:
It is also possible to run frontend plugins directly by setting appropriate "build settings" of Xcode. (Several ways to do this, you can set them on the command line for instance: xcodebuild build FOO=bla.) Here are a few build settings that I found useful to inject C flags:
OTHER_CFLAGS, OTHER_CPLUSPLUSFLAGS or to replace the compiler(s) and linker(s):
CC, CPLUSPLUS, LD, LDPLUSPLUS, LIBTOOL
The same approach works to control the "analyze" action: CLANG_ANALYZER_EXEC, CLANG_ANALYZER_OTHER_FLAGS
Disclaimer: some of those build settings are undocumented (afaik). Use at your own risk.
(Taken from [cfe-dev] Compile/refactor iOS Xcode projects)
For me it was enough to define the following User-Defined Settings in Build Settings of Xcode projects:
CC=my-c-compiler
CXX=my-cxx-compiler
LIBTOOL=my-linker-for-static-libraries
If you use CMake, the way to inject your compiler automatically is to use
set_target_properties(your-target PROPERTIES XCODE_ATTRIBUTE_CC "${YOUR_CC}")
set_target_properties(your-target PROPERTIES XCODE_ATTRIBUTE_CXX "${YOUR_CXX}")
Couple of years ago I've written an article that addresses exactly the problem you describe: Creating and using Clang plugin with Xcode
To enable custom clang you need to actually patch internals of Xcode.app itself, it is technically doable but:
it will break when you update Xcode
it will work correctly on your machine
the version of a plugin and your compiler should match, i.e.
they should be compiled using the same tree
So in general it doesn't really scale, so be careful :)
There's a somewhat obscure feature of Xcode where it supports "alternative toolchains". For example, Swift.org provides installable toolchains for Swift built from current sources.
Unfortunately, while Apple's documentation describes how to install and use such alternative toolchains, it doesn't describe how to create them. There are scripts in the Swift source base which build a toolchain and you can look at them to figure out how it's done. They are in https://github.com/apple/swift/tree/master/utils. Start at build-toolchain, which calls build-script and go from there.
Method 1: Change the User Defined settings
Under the project or target Build Settings add the User Defined settings for
CC=/path/to/cc
CXX=/path/to/c++
This is useful if you have a single compiler or linker you want to call, or if you want to call out to a trampoline that decides what to call on the fly.
Method 2: Create a complete custom toolchain via plugin
Using Clang LLVM 1.0.xcplugin as a template (found in the Xcode.app plugins folder), you can modify the plist to point at your own alternative compiler and linker.
This OLLVM on iOS tutorial walks through it.
From project setting go to build setting with target selected. then select All beside the Basic from the top bar. then under build option you can see the compiler option.
Refer below screenshot,
Update :
I think you should refer Using C and C++ in an iOS App with Objective-C++ and this tutorial.
I'm porting a C project compiled on linux to an arm platform using Eclipse Luna on Ubuntu 16.04
When I switch from CC=gcc to CC=arm-none-eabi in the Makefile I get a lot of missing headers and that's ok, that's what the porting job is about.
What bothers me is that when I CTRL-click on a symbol Eclipse doesn't open the corresponding file for the arm toolchain. For instance if I CTRL-click on <time.h> it does NOT open:
/media/BUILDS/arm_gcc493/arm-none-eabi/include/time.h
but instead it always reverts to its linux system counterpart, in this case
/usr/include/i386-linux-gnu/time.h
because that's where gcc would look for but I'm compiling with arm-none-eabi-gcc instead!
I don't want Eclipse to do that because debugging gets really confusing. If I have a problem with the header/source I'm actually trying to compile with, I want Eclipse to open me that file and not the default system one. I fiddled with Project Properties and Eclipse Preferences but with no luck.
Even worse, whenever <sys/socket.h> is included I get an error because the arm toolchain does not have socket.h but if I CTRL-click on it Eclipse takes me to /usr/include/i386-linux-gnu/sys/socket.h
I dont' want that, if the header needed for compilation is not there, it's just not there. I don't want Eclipse to show me other stuff, how do I do that?
The project was created importing into the workspace "Existing Code as Makefile Project" under C/C++
Thank you very much
EDIT:
I did the proper thing and started from scratch creating a project for the Cross ARM GCC Toolchain (with the proper plug-in). My mistake was creating a "Linux GCC" Project and pretending that Eclipse understood what I was trying to achieve just by launching a different "make" command. If, however, you can't restart from scratch, the accepted solution instructs you on how to fix the situation manually.
To resolve this situation you need to update the Preprocessor Include Paths, Macros, etc. setting to use your custom-prefix GCC.
To make the change:
Open Project Properties (Right-click on project and choose Properties)
In C/C++ General -> Preprocessor Include Paths, Macros, etc., choose Providers tab
Select CDT GCC Built-in Compiler Settings
Uncheck Use global provider shared between projects
Replace ${COMMAND} with arm-none-eabi-gcc or arm-none-eabi-g++
Alternatively, you can also edit the same setting at the workspace level to affect all the projects in your workspace. Go to Window -> Preferences -> C/C++ -> Build -> Settings -> Discovery tab instead.
Here are some screenshots that may help.
Before:
Project Properties:
After:
So I was trying to add some files to my project and double clicked on library and before I know it the whole entire library was being referenced into my project.
At first I thought, okay no big deal I'll just remove the reference, I did that it took some time, I saved afterword all seem fine, I even added some code.
From here I closed my project, come in the next day open the project and the library is in my project indexing itself. I try removing the reference again and it seems to go away, but now some of my work from the day before isn't there however some of it is, so my program can't run. To top things off Xcode crashes, open up my project again and library is still there, can someone help me with this?
From the Apple Developer Website:
http://developer.apple.com/library/ios/technotes/iOSStaticLibraries/Articles/configuration.html#//apple_ref/doc/uid/TP40012554-CH3-SW1
Select the Build Settings tab in your application target editor. Find the “Other Linker Flags” build setting. Add the flag -ObjC to this build setting’s value if it is not already present. This flag will tell the linker to link all Objective-C classes and categories from static libraries into your application, even if the linker can’t tell that they are used. This is needed because Objective-C is a dynamic language and the linker can’t always tell which classes and categories are used by your application code.
So I recommend to see if this has been done in your project settings and if it has then delete the flag in your build settings.
I am using Visual Studio 2010 to debug an application mostly written in C. Normally, I can attach the debugger just fine, but I am running in to some problems when I link in a library written in C++ / CLI.
If I compile the library with the /clr flag (which I will eventually have to do for this as of yet unwritten library) then I lose all ability to debug the entire C application, even the parts that have nothing to do with the library calls. I get the empty circle with the yellow triangle and exclamation mark where a red break point circle ought to be. Hovering over it gives me only a tool tip that says "The breakpoint will not currently be hit. No executable code is associated with this line. Possible causes include: conditional compilation or compiler optimizations."
Then if I link with the exact same library compiled without the /clr flag, I am again able to debug my application.
I understand that visual studio will not likely be able to debug the library written in C++ / CLI, and that is OK. I just want to keep the ability to debug the rest of the application and at least see the results of my calls to the external library.
Another complicating factor is that this project is not being built by visual studio. It is compiled using an external make system that uses cl, so I can customize any commands that need to be issued to the compiler that way.
Does anyone know why I can't currently debug the libraries the way I want to? Any advice for how I can?
You have to select the kind of debugger when you attach. Note the "Attach to" label in the dialog. Press the Select button and tick "Native" to get support for debugging native code. The DLL also needs to be loaded before any of your breakpoints can hit. If you are not sure whether or not that was done then look in the Debug > Windows > Modules debugger window to see loaded DLLs. The breakpoint indicator turns from hollow to solid red as soon as the debugger saw the DLL load and armed the breakpoint.
Debugging C++/CLI is otherwise supported, you can tick both the "Managed" and "Native" checkboxes. And set breakpoints in either kind of code. The only thing not supported is single-stepping from managed to native code and back. A mode-switch is required to activate the correct debugging engine, that requires code to hit a breakpoint.
And consider the Debug options in your native project, you can specify an EXE to start. So that you can simply press F5 to start debugging and skip the attach hassle.
It might also have to do with the Debugger Type!
(but that depends on your specific building configuration about which I do not know enough)
If any of your projects is complied with Common Language Runtime Support (/clr) you should set the Debugger Type in your startup project to "Mixed", since the default setting "Auto" might fail!
Imagine, you have two projects:
1) A non-CLR C++ project, which is your startup project that generates some .exe file.
2) A C++ project, that generates mylibrary.dll, which is compiled with Common Language Runtime Support, because it uses some managed code. The .exe from the first project calls mylibrary.dll.
If you start the first project with Debugger Type set to its default value "Auto", you'll be able to debug into the first project, but not into the second one. The debugger selector does not realize that you will be calling a CLR-library.
So set Project Properties -> Configuration Properties -> Debugging -> Debugger Type to "Mixed"!