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?
Related
I am working on a project that uses Adobe's DNG SDK 1.6 library, and it is supposed to work on Windows and MacOS.
The library has instructions on how to build it for both platforms, but I had to figure out an error that came up on Windows with Visual Studio. I am not very experienced with big C++ projects so it was not trivial but I got it working. Most of my own code will be done in C# .Net Core, calling the native libraries using a wrapper class with P/Invoke.
Now for Mac that's a different story, I have a MacOS 11 VM, installed Xcode 12.5.1 and followed the steps provided, as expected, it does not work. Bare in mind this is my first time touching Xcode and MacOS.
The project I am trying to build is dng_validate, and it depends on two libraries built by these projects: XMPFiles64 and XMPCore64.
The library projects build without any hiccups, each one of them creating a ".a" file in the folder: dng_sdk_1_6/xmp/toolkit/public/libraries/macintosh/intel_64_libcpp/Debug, they are named libXMPFilesStaticDebug.a and libXMPCoreStaticDebug.a respectively.
When I try to build the dng_validate project, I get the following error:
Library not found for -lXMPFilesStaticDebug
Because of the the error starting with an "l" instead of "lib", under both libraries project settings, I changed the "Executable Prefix" setting to "l" instead of "lib". Rebuilt both of them and made sure the file names changed as expected. But the error persists when trying to build the main project.
Under dng_validate's project settings, there is a setting called "Library Search Paths" and it does point to the proper aforementioned folder using a relative path. I even changed it to an absolute path to see if that would make it work.
I am really lost here, does anyone have an idea of what might be causing it?
Well... After asking on other forums and almost hiring a freelancer to fix this for me, I tried another shot in the dark of renaming the library files and it worked.
I changed the extensions of libXMPFilesStaticDebug.a and libXMPCoreStaticDebug.a from ".a" to ".dylib" and it just compiled and blew my mind with it.
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
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've written a Open Source program that I've released as GPL built using the Qt4 LGPL SDK. This program has the ability to search an optional Sqlite3 database for data.
Here is what is making me lose my mind. I compile the program on the development machine. When I try to run it, I can errors about missing DLLs. I copy those dlls into the same directory as the executable and it now works fine ( mingwm10.dll, libgcc_s_dw2-1.dll, QtCore4.dll, QtSql4.dll, QtGui4.dll ), including the database search.
Now, if I copy that folder with the executable and the DLLs to a new machine that has not had the SDK installed on it, it runs fine until I try to search. As soon as I hit the search button, I can the following error:
Title: Microsoft Visual C++ Runtime Library
Runtime Error!
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
I then download and install the SDK, doing nothing else, I can now run the program and search the sqlite3 file just fine!
What magic am I missing?
P.S. Both machines are freshly installed Windows XP systems.
You may have some libs or Qt plugins that are not deployed to the target machine. It most likely is the SQL driver plugin. Here's some info about it: http://doc.trolltech.com/latest/deployment-windows.html#qt-plugins
You'll need to copy the needed Qt plugins to a directory next to your executable. And add something like this in your main():
QApplication::addLibraryPath(QCoreApplication::applicationDirPath() + "/plugins");
(Edited link and added code)
I found the problem.
Stephen Chu was correct in that I was missing the sqlite driver. However, I can into more complications along the way.
The SDK comes with two sets of dlls. One set resides in $BASEDIR/bin and the other in $BASEDIR/qt/bin. The former contains the dlls used by Qt Creator, while the latter are the dlls that you want to ship with your executable.
I needed to take the sqlite plugin ( qsqlite4.dll ) and copy it to APP_DIR/sqlplugins. My problem was I was using the wrong qsqlite4.dll file.
A big thanks to everyone who contributed to this question.
For future reference, this issue was also discussed here: http://www.qtforum.org/article/34639/qt4-program-crashing-unless-sdk-installed.html
I have a framework of code I maintain. It's got mac and iphone objective-c code. And some of it is shared. I'm not having any problems with code. It's a problem with Xcode.
Let's just call my framework "AwesomeKit" for this problem.
The first thing I did was create an xcode Framework project called "AwesomeKit". Add source files to it, link against the common mac frameworks: foundation, cocoa, carbon, etc. It compiles fine.
Then, add a new "static library" target, let's call it "AwesomeKit-iPhone" and set the base SDK in the build settings to iphone device 3.1.3.
The problem comes when I try to add "Existing Frameworks" to the AweseomKit-iPhone target.
First change the current build target to AwesomeKit-iPhone.
Right click on any group and select "Add > Existing Frameworks..."
Choose UIKit.framework
UIKit will immediately be highlighted red, as if it's missing. It is indeed missing because Xcode uses the "Relative SDK" setting from the "Mac OS 10.6" SDK. When it should be using it relative to the current target's base sdk iphone device 3.1.3.
What the heck? Has anyone experienced this? This is really annoying.
I found the solution to this. You have to edit the project.pbxproj file inside of the project.xcodeproj directory. Find any entries like "SDKROOT = XXX" and change it to you real base root. It's probably best to look another project.pbxproj file that has it correctly set. I've used this on multiple occasions now and works like a charm. Usually there's 2 or more of the SDKROOT entries in project.pbxproj.
I think I've seen your problem. I'm still new myself to this, but what I've found when universal static libraries for both simulators and devices is that it's best to keep the Xcode Active SDK set to "Base SDK" rather that selecting an SDK. IN that mode, the current SDK is the SDK of the currently selected target.
Active SDK is rather like overriding the sdk on the command line. If yoy set it, SDK settings on targets will be overridden.
So im my case I wanted two targets to be run at the same time, one using the simulator sdk which compiles for i386 architecture and the other pointing at the device sdk which builds a universal lib for armv6/armv7 architectures.
I have seen the red not found stuff and I seem to remember that doing this, made it go away. I also had the project SDK set to a device rather than Mac. Remember that targets override this so it's a good way to ensure that Xcode is pointing at the right sdk without effecting the settings on targets and the ultimate build.
I'm in the same boat right now, XCode keep tacking the wrong SDK in front of the frameworks. This is project with both OSX and iOS targets. But there's seems to be something really wrong with my Project Build settings. Your screenshots don't show them, but you may want to check them. In my case, many entries are duplicates. So I have two categories "Architectures", totally identical. If I change one, the other changes along with it. This could be related to the problem with the wrong SDK being chosen. I think the project file is corrupted, and I'm now trying to figure out if I can fix it manually.