osxcross
osxcross copied to clipboard
tpoechtrager
Contents of the sdk tarballs
Many thanks for supplying the links, but, with my internet being as slow as it is, I'd rather not download something I more than likely already have; I have in my posession a tarball of the contents of the Xcode.app, obtained from my hackintosh install; would you be able to provide a list of the contents of the 10.9 sdk tarball (not en-totale, just a generic overview) to that effect?
Sure.
http://i.imgur.com/HBYU2sw.png
The SDK is usually in Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs, make sure the *.tar.xz has the same layout as shown in the picture, then move it into the tarball directory.
from your link
" B. Other Use Restrictions . The grants set forth in this License do not permit you to, and you agree not to, install, use or run the Developer Software on any non-Apple-branded computer, or to enable others to do so. Except as otherwise expressly permitted by the terms of this License or as otherwise licensed by Apple: (i) only one user may use the Developer Software at a time, and (ii) you may not make the Developer Software available over a network where it could be run or used by multiple computers at the same time. You may not rent, lease, lend, sell, sublicense or otherwise redistribute the Developer Software or exploit any services provided by or through the Developer Software in any unauthorized way"
wow. it sounds like the only legit way to do it is to run linux on a VM inside OSX
On Wed, Mar 26, 2014 at 1:11 AM, Aidan Steele [email protected]:
I imagine the tarballs are subject to Xcode EULAhttps://www.apple.com/legal/sla/docs/xcode.pdfand are not freely distributable.
Reply to this email directly or view it on GitHubhttps://github.com/tpoechtrager/osxcross/issues/4#issuecomment-38652787 .
This is a Noob question, but if the Darling project progresses by leaps and bounds, would it be able to 'replace' the tarballs in osxcross.... somewhat how MingW works with the MXE cross build system?
http://www.darlinghq.org/
http://en.wikipedia.org/wiki/Darling_%28software%29
No, I don't think so as that project's goal is just to be a loader for compiled binaries.
https://github.com/shinh/maloader is a similar (interesting) project.
I have a related question regarding this. When going through the SDK tree there are in target/SDK/MacOSX10.*.sdk/usr/{include, lib} a lot of libraries which could (should?) be build by the cross tool chain. Things like libz, libssl, etc. Would it be possible to setup the toolchain more like mxe (provide a package manager and have as much deps build by the cross tool chain as possible)? And use only the MacOSX specific libraries from the SDK?
I'm looking into cross building boost (I feel adventurous), but seeing the comments in MacPorts about broken stuff in Apple's code base/binaries makes me wonder how feasable replacing Apple's versions of libraries would be.
@BioMike: Yes, should be absolutely doable, but you would have to link against static libraries then, otherwise you may end up with ABI incompatibilities (or ship the dylibs with your application).
Btw, there is no need to cross-compile boost, you could use osxcross-macports instead:
osxcross-macports install boost :smile:.
FYI —
It is theoretically possible to create to re-create "SDKs" via the "Current OS" SDKs (header packages, distributed in Software Updates), with other Software Updates + strip -s (is that the flag? the one that creates stub DMGs), without agreeing to the the Xcode EULA. I've done so a few times manually. If there's enough people who would wan't this, I'd consider writing a script to do this automatically. Thoughts?
@geoff-codes I'm interested in knowing how you accomplished this. Are those packages you repack into an SDK legally redistributable, and under what license?
Personally, I'd love to be able to redistribute packages, or at least have something to point automated build scripts toward that doesn't require hosting potentially infringing artifacts. For instance, I think it'd be great to use osxcross and wclang to make buildbots that can produce binaries targeting all three major platforms.
I don't think that is legal (or the moral right thing) to do. I assume the "Current OS" also has an EULA, which you agreed to.
@zarvox
Personally, I'd love to be able to redistribute packages, or at least have something to point automated build scripts toward that doesn't require hosting potentially infringing artifacts.
Probably not legally redistributable no, but not hosting potentially infringing artifacts, definitely; all the relevant code, etc. is pulled from publicly available software update servers over unsecured HTTP.
For instance, I think it'd be great to use osxcross and wclang to make buildbots that can produce binaries targeting all three major platforms. This is exactly the use case I've done this with.
I'll post more details in the next couple of days with regards the process.
@BioMike I'd prefer not to get into the nitty-gritty of the legal argument here... what I will say is that while one arguably is bound to this EULA (±the standard Apple consumer EULA), it is significantly less stringent than the language in the Xcode/ADC EULA (see sections 2.2 and 2.5), which probably "applies" to the presently used methods of extracting SDKs.
I have tried a similar approach a while ago.
I have created C stub source files, which can be compiled to .dylibs, which then can be used to re-create the SDK in combination with the header files from opensource.apple.com.
For example: http://git.io/vLpoP represents libc++.
But I threw it away rather quickly because the SDK doesn't make a lot of sense without all the proprietary stuff (frameworks, ...).
Wouldn't worry too much regarding the legality of distributing Apple's SDK.
Mac OS X well and truly violates the BSD4.4 license agreement of which its entire codebase was developed from. You cannot take something that is open-source, with very specific conditions for redistribution and relicense it as proprietary software (with open source 'portions', give me a break).
Corporate thieves.
