Remote debug a linux app from XCode - c++

it's simple i had this linux pc which i connect remote and i have this application that i run there and i want to debug it, but i just don't know how.
It's the simpler c++ app on the world, load some libraries, do some calculus, print some output and return,
It's just that, i just haven't any clue.
So any help would be appreciated. Thxs anyway

You can't use Xcode for this - just use gdb (which is what Xcode uses under the GUI anyway).
[You might be able to do it indirectly, if you build and debug the code on your Mac, but that assumes that you're not doing anything non-portable (i.e. Linux-specific) in the code, and there aren't any other platform-specific dependencies (e.g. third party libraries, etc). You would still need to do final test and debug on the Linux machine but at least you could potentially squash any logic bugs on the Mac first.]

Related

where can I find grpc library for c++ windows and Linux both

I am trying to setup grpc server for a embedded device which runs the C++ environment. I have followed the link at https://github.com/grpc/grpc/blob/master/INSTALL.md, but I am unable to understand what needs to be done there in a order for grpc library to be available or installed in C++ libs.
Setting up grpc for C++, I assume to be having a generic approach for windows/Linux environment apart from the specifics of C++ run time location
The approach at above location says to build, but its failing for me at step,
With error as below,
Anyone if having more detailed link/reference to step by step process would be really helpful
For building gRPC under Windows nowadays, I would highly encourage people to use the provided CMakefile.
We haven't done any work towards supporting cygwin however, and we don't have any plans in supporting it at the moment. Most of the Windows-specific codebase would expect msys/mingw or VC, and I wouldn't be surprised if it would fail at runtime with cygwin even if you manage to compile, as our usage of the Linux API is probably too advanced for cygwin's emulation layer.
The Makefile should potentially behave properly under msys, if you insist on using it.

Apache thrift build on VxWorks

My aim is to use Apache thrift on one of our device having vxWorks 6.8 (C++).
I need steps to build thrift lib(.so) or sample application on vxWorks. It would be great help if someone could suggest way out. I am using Windriver Workbench 3.2 on windows 7 and target is PENTIUM3gnu. I can use boost but not C++ 11.
Well, as someone who had to make Thrift build on a bog-normal Fedora PC, and as someone who knows the pain of making it work on embedded platforms¹, I can assure you that your confusion is at least partly caused by Thrift's sub-par build system.
I can't actually give you detailed descriptions on how to build it on vxWorks, but here's the general consensus on what needs to be done when building it on something that doesn't happen to be very similar to the maintainer's machines:
massage all the ./configure options, and explicitly disable every single thing you don't need. Even after much script fixing, I couldn't build the examples/tutorials, so I had to disable them
explicitly state dependency paths. The autoconfigure scripts seem to have been modified in a manner that makes auto-detection of libraries work worse than it normally does with autoconf
try to build. Find the places where for some reasons, the build system uses hardwired locations and hence fails
rinse, repeat.
¹ OpenEmbedded, Android

Development in Cygwin C++

For a few years I was writing programs in Visual Studio for Windows and with GCC (Code Blocks) for Linux. Most of my libs compiled seamlessly as they worked both in Windows and Linux. However at the moment I am a bit confused, as I have to create an app using Cygwin. I don't really understand if I am still in UNIX/Linux environment, just running app on Windows by some "emulation", or I am rather on Windows just having access to some Linux/Unix functionality. From what I understood from the FAQ's and documentation it looks like I just should behave like in Linux environment.
All explanations I found in internet usually are very general and don't explain the detailed differences from programmers viewpoint.
Short question: Can I just write programs like I did for Linux without any major changes when using Cygwin?
Maybe.
A lot of code written for Linux will compile in Cygwin with very few problems, which can mainly be fixed by messing with preprocessor definitions.
However, any code written for linux which:
Uses a Linux driver
Directly accesses the kernel
Relies on any code which does either of these two things (and doesn't have a Windows counterpart)
will quite definitely not work, regardless of how much you modify the code.
Much as it tries to, Cygwin cannot fully emulate (yes it is an emulator, of sorts) everything a POSIX system can normally do. Cygwin is not windows, just a conversion layer from its own machine language.
For more information, read cygwin's wikia
Can I just write programs like I did for Linux without any major
changes when using Cygwin?
The platforms are not identical, so you can not realistically expect to write the program in Linux, and then POOF expect it to build and work under Cygwin. But if you don't use things not available under Windows, then you won't need major changes. And you can write non-trivial programs, which will build and work on both, perhaps needing a few #ifdefs in places.
From your question I take it you want to work on Linux, but write programs for running under Cygwin. In that case you must also build and test it in the Cygwin environment all the time, so:
Use version control, commit often. I recommend a DVCS like git or mercurial which have separate commit and push, it will allow you to do commits more freely.
Whenever you commit/push, do checkout/pull and build on the Cygwin host. You can do this manually or automatically (by simple custom script polling the version control, or by Jenkins or something).
When ever your code stops building or working under Cygwin, fix it before continuing with new code.
If Cygwin is not absolute requirement, then I would look into using Qt SDK. It can be used for non-Qt projects too, the MinGW toolchain on Windows is very similar to gcc on Linux. And if you're willing to use Qt, then it has all sorts of platform-independent features for things you might want to do, such as discover locations of standard directories for saving files, use threads, print things, have GUI...

How to use a windows .lib on linux using WINE

I have been using Qt (uses c++ code + Qt libraries) on the windows platform and am in the process of porting my project onto the Linux platform.
Using Qt this has been a very simple process and my project works on the Linux platform with barely any changes required.
However, we need to use a 3rd party windows compiled .lib with an associated header file. Clearly this file cannot work under Linux, but I have been reading posts that suggest I could use Wine to do this.
So in general my project will work as a normal Linux (Ubuntu) project, but I would like to include this .lib file using Wine. I have not been able to find a definitive answer "how to do this". I am not sure if you use Wine to translate the .lib into a .so file or if you have to statically link it in with some "Wine-like" convention...
Can anyone help point me in the right direction?
Thanks :)
AFAIK, you can't make hybrid applications with Wine (i.e. link C++ Linux executable with some Linux static libraries and Windows static libraries).
One of the solution I suggest is to encapsulate you Windows library in a Windows program that act as some network service, then you make your Linux application talk to your Windows library through the network.
However, it adds complexity to your software, requires you know how to do some network programing (however, these days it is quite easy to do) and is not suitable to every kind of library, especially if your library has some kind of GUI.
Have you tried compiling under Windows and running the entire program under Wine?
I'm not sure you can splice Wine and Linux programs.
I cannot imagine that a hybrid approach would work. In any case, running part of your program as a native application and the other part inside WINE will not give you much advantage over the complete program running in WINE. In either case, WINE is needed.
The main disadvantage of running the complete program in WINE is the look and feel of the GUI which might look a little alien to the system. However, using a proper setup for WINE will minimize the problem. And as a side note, most Linux users are used to different GUI concepts due to the different desktop environments available. Personally I have a lot of GNOME applications running in my KDE desktop.
I would personally try running your program in WINE. It makes development much easier. A circuit simulation tool that is quite famous with electrical engineers uses this approach. It is called LTSpice. While only Windows binaries are available, the developers test it with WINE to ensure that it runs on Linux. Admitted, it is a tool offered for free but the community accepts this approach.

step into system, CRTL functions with Eclipse in Linux

I'm a whiz with Visual C++, but Linux development is new to me. In Visual Studio, it's easy to trace into any code implemented by the C run time libraries. I just need to make sure the sources are installed and I can step right into any function I'd like -- malloc(), cout::operator<<(), whatever.
I'm trying to develop using Eclipse's C++ package. How can I step into C run time routines there? Since Linux is open-source, how do I step into operating system routines? Seems like it should e possible -- am I missing debug information, source code, or both? Something in my configuration?
I'm using Ubuntu 12.10 at the moment. I'm using g++. I believe I'm using the Eclipse build system as I never imported a makefile project; I just started with a simple "Hello World" project from the C++ project wizard in Eclipse.
After hacking at this a bit:
I've installed the libstdc++6-4.2-dbg package thinking it would be debug symbols for the libstdc library:
sudo apt-get install libstdc++6-4.2-dbg
I've also installed dpkg-dev, since the next step said I needed it:
sudo apt-get install dpkg-dev
I tried installing libc6 sources into a directory under my home:
apt-get source libc6
At this point, trying to step into printf() tells me that printf.c is missing. I can't step into malloc or strlen, which suggests that I don't understand how the C runtime libraries are factored in Linux. How are libc, glib, and libstdc++ different? Which packages do I need?
If I ask Eclipse to open the printf.c file I do have (at ~/eglibc-2.15/stdio-common/printf.c), it doesn't open the file (doesn't adjust the debugging window to show the source) and repaints the window that shows the error message about not being able to find the file. (Can't find a source file at "printf.c" Locate the file or edit the source lookup path to include its location.)
Whilst, as a Kernel developer on Linux, I do agree that using the individual tools separately will be a good thing to learn, and as such Basile's answer is usefuel.
However, the stepping into C runtime libraries should be equally possible with Eclipse. But just because the OS is open source doesn't mean that it supports you clambering around inside it willy nilly - in fact, you CAN NOT step into the OS itself from user-mode code. You nee KGDB (google it), and you definitely need a second computer to attach to the one being debugged, because when you step into the kernel, you will essentially lock up the machine, at the very least in the context you are stepping, but most likely also prevent other work from being done until you get back out from the kernel, so for example, if you step into open(), at some point the entire filesystem may well stop working altogether until you are back out of whatever lock you are holding. This wll certainly upset some software. Note that this is just an example of how things may work unexpectedly when debugging the kernel, not strictly "I've done this and it happened" - I have debugged kernels with debuggers several times, and you do have to be careful with what you do, and you certainly can not run the debugger on the same machine, as the machine STOPS when you are debugging.
Going back to the usermode, which you CAN debug via Eclipse, essentially all you need to do is install the source code for the runtime library you are interested in, and go... Same principle as on Windows with visual studio - except that nearly all software you ever run on a Linux system is available as source code. You may need to recompile some libraries with debugging symbols, and just like in Windows, you need to make sure the debugger knows how to find the source code. Everything else should be handled by the debugger in Eclipse. I spent about three years using Eclipse for both local and remote debugging, and in general, it works. There are quirks in places, but that's the case with almost any debugger.
Good luck.
First, you don't need Eclipse to develop software on Linux. You should better learn to do that with independent tools (command line) like emacs or gedit (as editor), git (version control), make (builder) which runs the gcc or g++ compiler (both gcc & g++ are part of GCC, the Gnu Compiler Collection).
really, you'll learn a lot more by not depending upon Eclipse; it may just hide you the real commands which are doing the job, and you should understand what they really are.
You want to pass the -g -Wall options to GCC. The -g option asks for debug information, and the -Wall options asks for almost all warnings. Improve your code till no warnings are given.
And the operating system is providing syscalls (which are operations provided by the kernel to applications; from the application's point of view, a syscall is atomic so you cannot step into it; however strace may show you all the syscalls done by some execution). If you wanted to step by step inside system libraries like libc you need the debugging variant of it (e.g. some libc6-dbg package). But there is usually no need to dive inside system libraries.
See http://advancedlinuxprogramming.com/
Then, you will use gdb to debug the binary program.
So, step by step instructions inside a terminal:
edit your source files with emacs or gedit
learn how to use GCC: for a single source C++ program compile it with g++ -Wall -g source.cc -o progbin and type ./progbin in your terminal to run it. Only when the program is debugged and satisfactory would you compile it with optimizations (by giving the -O or -O2 flag to gcc or g++)
Use gdb to debug a program (compiled with -g).
for a multi-file C++ program, consider learning how to use make
use a version control system like git
For beginners, I suggest to avoid Eclipse, because it just hides to you what is really happening underneath (Eclipse is simply running other tools like the above commands)
Software development under Linux requires a different mindset than under Windows: you really are using your own loose combination of independent tools, so better to learn a bit each of them.
NB. to step inside "system" functions like malloc (which is above syscalls like mmap) you need the debug variant of the libc package with aptitude install libc6-dbg, and you need to set LD_LIBRARY_PATH to /usr/lib/debug etc...