I have XCode 5 installed, I can use command-line lldb just fine. Now I want to create my own application that will link with LLDB C++ interface. I tried to search through the XCode package and found no .a archives, no headers. Does this mean I need to build LLDB locally (and go through the signing process)?
it is indeed correct that there are no header files included in the LLDB.framework that comes with Xcode
With that said, you have two possible avenues:
build LLDB from source, as you said, and then use the built ToT to write your app
obtain the headers from our open source repository and put them in the magical location in the Xcode-provided LLDB.framework and that should enable you to link successfully against whatever LLDB you have.
The incantation should be to make an Headers folder in LLDB.framework/Versions/A and copy all the PUBLIC headers from our sources into there (you want LLDB.h, all the SB*.h files and lldb-defines,enumerations,forward,public,types,versioning.h) - then go into LLDB.framework and make a symlink named Headers to Versions/Current/Headers
Just an FYI - the public API (SB*.h) is all that is pretty much supported and guaranteed to be relatively stable. If you start trying to use the private layer (lldb_private::*), you are going to be on your own and breakages might be fairly frequent as the internals of the debugger evolve
Related
I have an executable that makes use of /usr/lib/libcrypto.0.9.8.dylib. I've (more or less) figured out some breakpoints within that library that I'd like to understand better.
However, I do not remember if this is the stock openssl on the system, or if I later installed it (don't think so, pretty sure that homebrew would have put it elsewhere).
This is for macOS Mojave (10.14). If the debug symbols have been stripped in libcrypto, I'm not sure I even know how to check that (nm?). I have, however, downloaded and extracted the source (matching the version).
Is there any way to configure lldb such that it can show me the source code instead of assembly language? If the debugging symbols have been stripped (without even checking, I'd assume so) can you even do this?
I'm trying to do my own research for this, but I'm not even sure I know what keywords to search with yet.
The tools on Darwin don't store debug information in the binaries, but rather in a separate standalone bundle (a dSYM). So if you don't have a dSYM for your libcrypto then you don't have debug information for it, and there's no way to reconstruct the code->source map.
Some distributions have debug packages as well as release ones that include the dSYM's. lldb matches dSYM to binary using a common UUID computed by the linker. You can print the UUID with the command dwarfdump --uuid <PATH TO BINARY> and then see if wherever you got the library from kept that dSYM.
But if you can't find the dSYM, you aren't going to be able to do any source level debugging.
I want to compile the IOSerialFamily kext bundle on my own machine (OSX 10.14.4) using Xcode 10.2. I downloaded the source tarball from Apple's open source repository, but even though the project contains a .xcodeproj file, it's obviously not set up to compile on a personal machine. The project does not use the public SDK, but instead uses a macosx.internal SDK which I assume to be available only to Apple employees.
I switched it to use the installed SDK, but many problems followed. For example, the "internal" SDK's sys/tty.h file must contain a full definition of struct tty, whereas the public SDK only contains a forward declaration of the struct. I suspect I can patch in the version from the darwin-xnu kernel, but that would only fix one of the many errors. I'm looking for a solution that would help me fix them all simultaneously.
Does anyone have any experience compiling these "Open Source" projects? How can I set up my environment to do this? Do I have to go through and painstakingly hack away at each individual compiler error? Is there somewhere else that I can obtain a working copy of the IOSerialFamily kext source that will compile on a machine with the public SDK?
I'd like to use open source library on Windows. (ex:Aquila, following http://aquila-dsp.org/articles/iteration-over-wave-file-data-revisited/) But I can't understand anything about "Build System"... Everyone just say like, "Unzip the tar, do configure, make, make file" at Linux, but I want to use them for Windows. There are some several questions.
i) Why do I have to "Install" for just source code? Why can't I use these header files by copying them to the working directory and throw #include ".\aquila\global.h" ??
ii) What are Configuration and Make/Make Install? I can't understand them. I just know that configuration open source with Windows need "CMake", and it is configuration tool... But what it actually does??
iii) Though I've done : cmake, mingw32-make, mingw32-make install... My compiler said "undefined references to ...". What this means and what should I do with them?
You don't need to install for sources. You do need to install for the libraries that get built from that source code and that your code is going to use.
configure is the standard name for the script that does build configuration for the software about to be built. The usual way it is run (and how you will see it mentioned) is ./configure.
make is a build management tool (as the tag here on SO will tell you). One of the most common mechanisms for building code on linux (etc.) is to use the autotools suite which uses the aforementioned configure script to generate build configuration information for use by generated makefiles which make then uses to build the software. make is also the way to run the default build target defined in a makefile (which is often the all target and which usually builds the appropriate library/binary/etc.).
make install is a specific, secondary, invocation of the make tool on the install target which (generally) installs the (in this case previously) built code into an appropriate location (in the autotools/configure universe the default location is generally under /usr/local).
cmake is, again as the SO tag says, a build system that generates configuration files for other build tools (make, VS, etc.). This allows the developers to create the build configuration once and build on multiple platforms/etc. (at least in theory).
If running cmake worked correctly then it should have generated the correct information for whatever target system you told it to use (make or VS or whatever). Assuming that was make that should have allowed mingw32-make to build the software correctly (assuming additionally that mingw32-make is not a distinct cmake target than make). If that is not working correctly then something is still missing from your system (and cmake probably should have caught that).
But to give any more detail you will need to give more detail about what errors you are actually getting and from what command.
(Oh, and on Windows, and especially if you plan on building your software with VS (or some other non-mingw32-make tool) the chances of you needing to run mingw32-make install are incredibly small).
For Windows use cmake or latest ninja.
The process is not simple or straight, but achievable. You need to write CMake configuration.
Building process is not simple and straight, that's why there exists language like Java(that's another thing though)
Rely on CMake build the library, and you will get the Open-Source library for Windows.
You can distribute this as library for Windows systems, distribute and integrate with your own software, include the Open Source library, in either cases, you would have to build it for Windows.
Writing CMake helps, it would be helpful to build for other platforms as well.
Now Question comes: Is there any other way except CMake for Windows Build
Would you love the flavor of writing directly Assembly?
If obviously answer is no, you would have to write CMake and generate sln for MSVC and other compilers.
Just fix some of the errors comes, read the FAQ, Documentation before building an Open Source library. And fix the errors as they lurk through.
It is like handling burning iron, but it pays if you're working on something meaningful. Most of the server libraries are Open Source(e.g. age old Apache httpd). So, think before what you're doing.
There are also not many useful Open Source libraries which you could use in your project, but it's the way to Use the Open Source libraries.
I can't stand XCode, but really love OpenFrameworks, and I know it works on Linux+Win32 so I don't see why it should be XCode dependent. If I need to have XCode installed that's fine, I just don't want to use it at all.
Xcode internally uses gcc/llvm. in fact from the command line you can cd into a directory that contains an openFrameworks project and just type xcodebuild. but this won't allow you to edit the project file and add new source code, etc.
the Linux makefiles could be adapted to work on OSX as well. they already contain a lot of the information necessary about finding the correct source files, library paths etc. however Linux allows us to install many more components as shared system libraries, while on OSX we link most of the libs statically, so a number of extra library paths would need to be added. probably the biggest gotcha is that everything has to be compiled 32 bit, which means passing -arch i386 everywhere, so you can't just install dependant libs using Homebrew or MacPorts. we are in the process of transitioning to 64 bit but there are still some QuickTime calls that require us to stick with 32 bit, mainly around accessing legacy video capture devices that a lot of us still use for computer vision.
like #cdelacroix points out, we only maintain Xcode project files on OSX. this is mainly due to the lack of a decent alternative. there is a version of Code::Blocks for OSX but it is not very well supported, has some issues with native gui rendering and tends to lag behind the other platforms. Xcode is also the easiest way to install a toolchain on OSX so for most users installing Xcode is necessary.
if you do get a makefile based build system working, and would be interested in maintaining it medium to long term, please consider contributing it to the GitHub repository, it would be gladly accepted.
As of March 2013, openFrameworks has official makefile support for compiling the library itself. However, at the time of this writing, the changes haven't yet been merged into the stable release. You'll need to clone the Git repository and switch to the development branch.
git clone https://github.com/openframeworks/openFrameworks
cd openFrameworks && git checkout develop
cd libs/openFrameworksCompiled/project
make
As far as I can tell, we still need to use the unofficial solutions for compiling apps against the library.
You need Xcode, or at least a set of compilers (more information is available here), but otherwise, no, you can edit/work with the code in whatever editor or environment you want.
Here's a link to a makefile which will compile an OpenFrameworks application on OsX:
https://gist.github.com/labe-me/1190981
Place the makefile in the apps' directory and run make. Tested on OsX 10.6, but haven't tried with addons yet.
As #mipadi said, there is no requirement to actually use Xcode, you can do pretty much everything you do in Xcode with make or cake or any of your build system of choice. All you have to do is find the right set of command line options to pass to the usual tools (compiler, linker, strip, etc.), and sometimes the easier way is to... look in the Xcode build window how it is doing stuff (expand the lines with the small button on the right of each line).
For example you can link with your framework of choice with ld -framework Framework -FPathToFramework foo.o or your dynamic library with ld -lLib -LPathToDylib foo.o. You might have to learn about #rpath, #loader_path and install_name_tool to ship a self-contained packaged application.
As for OpenFrameworks, the "requirement" for Xcode is that the authors decided to maintain only Xcode project files. I just looked at how they do it, they ship source code and Xcode project files that build static libraries, so it will be even more simple for you (although you will need to link the library dependencies by hand). You will have to choose between compiling everything from source in your build system (if you want more customization power without touching Xcode), or just produce the 2 static libraries (openFrameworks.a and openFrameworksDebug.a) with Xcode once, then use them in your build system (recommended until you really need continuous customization).
I'm still not 100% sure with the framework linking process, but from what I've seen here before nobody has asked a similar question, perhaps because this could be a silly question, but I'll give it a go anyway.
In my current X-Code project, I'm using a custom framework, say example.framework. At the moment, as far as I'm aware of, in order for the program to function with the framework, I need to have it either in /Library/Frameworks, or I need to have it copied into the bundle resources in the build phase.
Would anybody know about adding a framework to a project in a way that it gets compiled into the executable, so I don't have to include the raw framework with the app? I'd rather not share the whole framework...
Thank you in advance! Any suggestions are also welcome!
A Mac OS X framework is basically a shared library, meaning it's a separate binary.
Basically, when your main executable is launched, the OS will load the framework/dylib into memory, and map the symbols, so your main executable can access them.
Note that a framework/dylib (bundled into the application or not), does not need to contain the header files, as those are only needed at compilation time.
With Xcode, you can actually decide whether or not to include the header files, when you are copying the framework to its installation directory (see your build phases).
If you don't copy header files, people won't be able to use your framework/dylib (unless they reverse-engineer it, of course).
If you still think a framework is not suitable for your needs, you may want to create a static library instead.
A static library is a separate object file (usually .a) that is «included» with your final binary, at link time.
This way, you only have a single binary file, containing the code from the library and from your project.