Hi all,
In the last two weeks I've been experimenting with getting a Mac OS X cross-compiler operational on Fedora. This was done according to documentation [1] which Richard W.M. Jones mentioned [2] on the mailing list some weeks ago.
The documentation uses mostly open source tools (odcctools [3] and GCC [4]) but the Mac OS X SDK from Apple is also used. The Mac OS X SDK is part of XCode which can be downloaded from the Apple website by registered users [5]. The SDK contains headers and libraries which are needed to compile applications for regular Mac OS X environments.
There are two different SDK's which can be used. There's one for Mac OS X 10.4 (Tiger) and one for Mac OS X 10.5 (Leopard). There are also two versions of GCC available, GCC 4.0 and GCC 4.2. For my experiments I used the 10.4 SDK and GCC 4.2 (GCC 4.0 failed to compile because of a strange error in the libstdc++ configure script).
I managed to translate the documentation into several .spec files so that everything integrates nicely in Fedora. I've also ported several mingw packages to this toolchain so that GTK based applications can be tested on a Mac OS X environment. The complete list of packages is:
darwinx-filesystem darwinx-odcctools darwinx-sdk darwinx-gcc darwinx-gettext darwinx-libpng darwinx-libjpeg darwinx-jasper darwinx-pixman darwinx-cairo darwinx-glib2 darwinx-atk darwinx-pango darwinx-gtk2 darwinx-libsoup darwinx-gtkhtml darwinx-ige-mac-integration darwinx-gtk-quartz-engine
This is also the order in which the packages need to be compiled.
In this list there are some new packages which aren't in Fedora-MinGW.
The first one is darwinx-gtkhtml. The MinGW variant of this package isn't in Fedora yet because it is heavily patched to drop all the (unnecessary) GNOME dependencies. The patch is too ugly right now for inclusion in the Fedora-MinGW project and needs to be cleaned up.
Two other new packages are darwinx-ige-mac-integration and darwinx-gtk-quartz-engine. These are two GNOME projects [6][7] which make GTK integrate better in Mac OS X environments.
All the srpms for these packages can be found at [8]. The srpm for darwinx-sdk is missing. This is done on purpose because the XCode package itself is about 1GB in size. The .spec file and other sources/patches for the SDK are placed in a separate folder. The resulting .noarch.rpm of the SDK is also placed in that folder (which is 32MB in size).
Now about the results: With this toolchain I managed to get one of my personal open source projects, NNTPGrab [9], operational, but there are still some strange bugs involved. This project is a GTK based application which makes use of GObject signals. In my first try on the Mac OS X toolchain, the signals were emit, but the parameters in the callback functions were always NULL. After that I dropped some potentially conflicting files from the SDK (headers installed by GCC) and rebuild everything. Now the GObject signals work fine, but the fonts are really messed up. It's basically the same as described in a WebKit bug report [10] as I've also seen the same error message while running my application. Unfortunately I don't have a solution to that yet, but I suspect it's caused by a compiler mismatch (Mac OS X 10.4 is based on GCC 4.0 while Mac OS X 10.5 is based on GCC 4.2).
Another technical issue which I haven't thought of yet is the use of fat binaries/univeral binaries [11]. With fat binaries the application can be run on multiple architectures like ppc, x86 and x86_64. It requires multiple cross compilers which are bundled together using special compiler flags. For now I've only prepared a i686-apple-darwin9 toolchain.
On to everybody's favorite subject (ahum..), the legal stuff. First of all, I didn't do a thorough research yet about all the licenses involved. For GCC and odcctools I don't see any license incompatibilities which prevent it from inclusion in Fedora.
The Mac OS X SDK seems to be a mix a various licenses. I've seen files with the following licenses: - Apple Public Source License version 1.0 - Apple Public Source License version 1.1 - Apple Public Source License version 2.0 - GPLv2+
According to [12] and [13] the APSL 1.0 and 1.1 licenses are a no-go for Fedora, so that may indicate the whole project isn't welcome in Fedora.. We could try to extract all the APSL 2.0 and GPLv2+ pieces from the SDK, but I'm afraid it won't be enough to compile regular applications.
Another issue we have is that the SDK contains several libraries which are needed to compile regular applications. The source code for a number of these libraries isn't open source so that may also be another reason why the SDK isn't welcome in Fedora.
To wrap it all up, it's technically possible to cross-compile Mac OS X applications but there are still some major roadblocks up ahead.
Regards,
Erik van Pienbroek
[1]: http://devs.openttd.org/~truebrain/compile-farm/apple-darwin9.txt [2]: http://lists.fedoraproject.org/pipermail/fedora-mingw/2009-May/001327.html [3]: http://code.google.com/p/iphone-dev/ [4]: http://opensource.apple.com/release/developer-tools-312/ [5]: http://developer.apple.com/mac/ [6]: http://live.gnome.org/GTK%2B/OSX/Integration [7]: http://sourceforge.net/apps/trac/gtk-osx/wiki [8]: http://build2.openftd.org/darwinx/ [9]: http://www.nntpgrab.nl [10]: https://bugs.webkit.org/show_bug.cgi?id=24220 [11]: http://wiki.openttd.org/Universal_libraries [12]: https://www.redhat.com/archives/fedora-legal-list/2009-February/msg00009.htm... [13]: https://fedoraproject.org/wiki/Licensing:Main#Bad_Licenses
On Mon, Jun 15, 2009 at 03:30:30PM +0200, Erik van Pienbroek wrote:
On to everybody's favorite subject (ahum..), the legal stuff. First of all, I didn't do a thorough research yet about all the licenses involved. For GCC and odcctools I don't see any license incompatibilities which prevent it from inclusion in Fedora.
The Mac OS X SDK seems to be a mix a various licenses. I've seen files with the following licenses:
- Apple Public Source License version 1.0
- Apple Public Source License version 1.1
- Apple Public Source License version 2.0
- GPLv2+
According to [12] and [13] the APSL 1.0 and 1.1 licenses are a no-go for Fedora, so that may indicate the whole project isn't welcome in Fedora.. We could try to extract all the APSL 2.0 and GPLv2+ pieces from the SDK, but I'm afraid it won't be enough to compile regular applications.
Another issue we have is that the SDK contains several libraries which are needed to compile regular applications. The source code for a number of these libraries isn't open source so that may also be another reason why the SDK isn't welcome in Fedora.
If licenses don't meet the Fedora requirements, there may still be the option of pushing it to RPM Fusion Free or Non-Free repos.
Daniel
On Mon, Jun 15, 2009 at 02:37:08PM +0100, Daniel P. Berrange wrote:
On Mon, Jun 15, 2009 at 03:30:30PM +0200, Erik van Pienbroek wrote:
On to everybody's favorite subject (ahum..), the legal stuff. First of all, I didn't do a thorough research yet about all the licenses involved. For GCC and odcctools I don't see any license incompatibilities which prevent it from inclusion in Fedora.
The Mac OS X SDK seems to be a mix a various licenses. I've seen files with the following licenses:
- Apple Public Source License version 1.0
- Apple Public Source License version 1.1
- Apple Public Source License version 2.0
- GPLv2+
According to [12] and [13] the APSL 1.0 and 1.1 licenses are a no-go for Fedora, so that may indicate the whole project isn't welcome in Fedora.. We could try to extract all the APSL 2.0 and GPLv2+ pieces from the SDK, but I'm afraid it won't be enough to compile regular applications.
Another issue we have is that the SDK contains several libraries which are needed to compile regular applications. The source code for a number of these libraries isn't open source so that may also be another reason why the SDK isn't welcome in Fedora.
Excellent work BTW Erik.
If licenses don't meet the Fedora requirements, there may still be the option of pushing it to RPM Fusion Free or Non-Free repos.
I'll agree with Dan here and say that it's worth getting this into rpmfusion, getting the licenses clear, and then seeing what if anything we can take into Fedora.
Also as Levente said, do we really need Apple's GCC? IIRC gcc 4.4 could be used.
Rich.
Erik van Pienbroek wrote:
Hi all,
In the last two weeks I've been experimenting with getting a Mac OS X cross-compiler operational on Fedora. This was done according to documentation [1] which Richard W.M. Jones mentioned [2] on the mailing list some weeks ago.
just 2 quick questions: - wouldn't we like to merge all 3 platform (mingw32, mingw64, darwin) into a common name and package set as discussed earlier? - why not use the same gcc on all platform? ie. gcc-4.4. isn't it build on darwin?
Op maandag 15-06-2009 om 16:08 uur [tijdzone +0200], schreef Farkas Levente:
Erik van Pienbroek wrote:
Hi all,
In the last two weeks I've been experimenting with getting a Mac OS X cross-compiler operational on Fedora. This was done according to documentation [1] which Richard W.M. Jones mentioned [2] on the mailing list some weeks ago.
just 2 quick questions:
- wouldn't we like to merge all 3 platform (mingw32, mingw64, darwin)
into a common name and package set as discussed earlier?
Looks like a good idea to me
- why not use the same gcc on all platform? ie. gcc-4.4. isn't it build
on darwin?
The GCC used by Apple is a forked version of GCC which Apple also maintains. I don't think that all the Apple changes are upstreamed.. I could try creating a GCC 4.4 version of the i686-apple-darwin9 compiler, but I fear it won't be possible.
Regards,
Erik van Pienbroek
On Mon, Jun 15, 2009 at 04:48:36PM +0200, Erik van Pienbroek wrote:
Op maandag 15-06-2009 om 16:08 uur [tijdzone +0200], schreef Farkas Levente:
Erik van Pienbroek wrote:
Hi all,
In the last two weeks I've been experimenting with getting a Mac OS X cross-compiler operational on Fedora. This was done according to documentation [1] which Richard W.M. Jones mentioned [2] on the mailing list some weeks ago.
just 2 quick questions:
- wouldn't we like to merge all 3 platform (mingw32, mingw64, darwin)
into a common name and package set as discussed earlier?
Looks like a good idea to me
- why not use the same gcc on all platform? ie. gcc-4.4. isn't it build
on darwin?
The GCC used by Apple is a forked version of GCC which Apple also maintains. I don't think that all the Apple changes are upstreamed.. I could try creating a GCC 4.4 version of the i686-apple-darwin9 compiler, but I fear it won't be possible.
Yes this is right. I checked the darwinx-gcc package that I built before, and it did use Apple's GCC, not upstream GCC.
http://hg.et.redhat.com/cgi-bin/hg-misc.cgi/fedora-mingw--devel/file/tip/dar...
Rich.
On Tue, Jun 16, 2009 at 04:09:31PM +0200, Kevin Kofler wrote:
Farkas Levente wrote:
- wouldn't we like to merge all 3 platform (mingw32, mingw64, darwin)
into a common name and package set as discussed earlier?
Huh? How would that work? MinGW and darwinx are very different targets.
The whole idea is academic if the licensing of the toolchain does not allow us to submit darwinx to Fedora.
Daniel
On Tue, Jun 16, 2009 at 04:09:31PM +0200, Kevin Kofler wrote:
Farkas Levente wrote:
- wouldn't we like to merge all 3 platform (mingw32, mingw64, darwin)
into a common name and package set as discussed earlier?
Huh? How would that work? MinGW and darwinx are very different targets.
As Dan says it's somewhat academic if we can't add the compiler(s) to Fedora. But we did come up with a coherent plan for how to do this:
http://lists.fedoraproject.org/pipermail/fedora-mingw/2009-February/000464.h...
(see also the following messages).
Rich.
Richard W.M. Jones wrote:
As Dan says it's somewhat academic if we can't add the compiler(s) to Fedora.
Indeed. The required MacOS X SDK cannot be distributed in Fedora, if at all. (Apple allows downloading it only with a registration, so are you sure they allow redistributing it at all? It cannot go even into RPM Fusion if it cannot be redistributed!)
But we did come up with a coherent plan for how to do this:
http://lists.fedoraproject.org/pipermail/fedora-mingw/2009-February/000464.h...
(see also the following messages).
That sounds like a bad plan. The targets don't have any more in common than they do with the native version. It makes sense to keep them in separate SRPMs for the same reason it makes sense to keep them separate from the native package.
I don't see a problem with building mingw64-* from mingw32-* SRPMs or the opposite, as that's the same target OS, just on different hardware platforms, but building darwinx-* from the same SRPM as mingw* sounds very artificial to me. They're likely to need different patches, dependencies etc.
Kevin Kofler
On Tue, Jun 16, 2009 at 04:27:13PM +0200, Kevin Kofler wrote:
That sounds like a bad plan. The targets don't have any more in common than they do with the native version. It makes sense to keep them in separate SRPMs [..]
No, I disagree.
Entering hypothetical territory, _if_ it turns out we are allowed to distribute the Mac OS X SDK :-)
As a developers, I would want an environment where I can build my program for all four [inc. native] targets very easily. It would be simpler if, for example, the same, identical version of Gtk was on all four targets, because that would reduce any potential incompatibilities and differences in features.
On the Fedora side of things, having one library build from a single SRPM into all targets reduces management overhead. For example, we only build each library once and we don't need to track differences in versions between SRPMs.
Now in the original email I did point out cases where you would want separate SRPMs. Quoting myself:
The only time I could see it making sense to build from different SRPMS would be if either (a) different people needed to manage the ports, or (b) for some reason we had to use a different upstream on one of the platforms.
I think those are still the only valid exceptions.
[..] for the same reason it makes sense to keep them separate from the native package.
In the original proposal for the Fedora MinGW project, we discussed building mingw as sub-RPMs of the native RPMs. The reasons this was rejected was essentially point (a) above - ie. different people need to manage them.
I don't see a problem with building mingw64-* from mingw32-* SRPMs or the opposite, as that's the same target OS, just on different hardware platforms, but building darwinx-* from the same SRPM as mingw* sounds very artificial to me. They're likely to need different patches, dependencies etc.
Point taken, but I'd hope that we can push upstreams so that they accept any patches required to build on all platforms. A good thing about the Fedora MinGW project is that we have effectively provided a way for upstreams to routinely test and build their libraries for Windows, which many upstreams were never able to do before.
Rich.
Kevin Kofler wrote:
But we did come up with a coherent plan for how to do this:
http://lists.fedoraproject.org/pipermail/fedora-mingw/2009-February/000464.h...
(see also the following messages).
That sounds like a bad plan. The targets don't have any more in common than they do with the native version. It makes sense to keep them in separate SRPMs for the same reason it makes sense to keep them separate from the native package.
I don't see a problem with building mingw64-* from mingw32-* SRPMs or the opposite, as that's the same target OS, just on different hardware platforms, but building darwinx-* from the same SRPM as mingw* sounds very artificial to me. They're likely to need different patches, dependencies etc.
why maintain 3 spec file for eg mingw32-zlib which are exactly identical on all platform or even a for cycle would be enough in the build section. it keeps simple clean and easier to maintain these even now too much packages.
Op maandag 15-06-2009 om 15:30 uur [tijdzone +0200], schreef Erik van Pienbroek:
Now about the results: With this toolchain I managed to get one of my personal open source projects, NNTPGrab [9], operational, but there are still some strange bugs involved. This project is a GTK based application which makes use of GObject signals. In my first try on the Mac OS X toolchain, the signals were emit, but the parameters in the callback functions were always NULL. After that I dropped some potentially conflicting files from the SDK (headers installed by GCC) and rebuild everything. Now the GObject signals work fine, but the fonts are really messed up. It's basically the same as described in a WebKit bug report [10] as I've also seen the same error message while running my application. Unfortunately I don't have a solution to that yet, but I suspect it's caused by a compiler mismatch (Mac OS X 10.4 is based on GCC 4.0 while Mac OS X 10.5 is based on GCC 4.2).
Hi all,
In the last few days I continued with the toolchain. I discovered that the Apple upstream of odcctools has been revived for Mac OS X 10.6 (Snow Leopard) support: http://svn.macosforge.org/repository/odcctools/trunk/ChangeLog.odcctools Because of this I replaced the odcctools from the iphone-dev project (based on cctools-622.3) with the odcctools tools from Apple (based on cctools-698.1).
This update was also necessary to generate a compiler based on the Mac OS X 10.5 SDK. Next to this, I also discovered some hidden environment variables which are needed to indicate which version of Mac OS X is required to run the application. The entire SDK has also been moved to a separate directory (%{_darwinx_sysroot}/SDKs) just like regular Mac OS X environments and this location has been added to the CFLAGS in the %{_darwinx_configure} script.
I'm still rebuilding all the packages, but I hope to get more satisfying results than before.
So what's next to happen? Here's a small list of tasks which need to be done before everything can be imported in Fedora or RPMFusion: - Support for fat/universal binaries This requires multiple GCC compilers which are tied together by a small wrapper. This wrapper (which is called /usr/bin/gcc on regular Mac OS X environments) accepts arguments like '-arch i386 -arch ppc' and calls the corresponding compilers and uses lipo to merge the results together - License research This consists of three major questions: - Are we allowed to redistribute XCode/the SDK or could we get an exception from Apple for this? - Are the APSL 2.0 + GPL bits enough to get applications working? - Can we regenerate the .dylib files which are bundled with the SDK from source code (which is a requirement for Fedora) so that we get something like w32api? - Debug symbols On regular Mac OS X environments GCC executes a tool called 'dsymutil' during the compilation. This tool is required to add debug information to libraries/executables. Without this information only function names will be shown in gdb (no line numbers etc). AFAIK the source code of this tool isn't available. For now I've patched the calls to 'dsymutil' out of gcc so that the compilation of libraries/executables shouldn't fail - Merge the .spec files for the normal libraries (pixman, cairo, gtk2, etc) with their mingw32 counterparts The discussion about this was already started in this thread, but it's kinda dependent on the results of the license research. For fat/universal binaries one doesn't need to perform separate compile passes for each platform (ppc/i386/x86_64) as that all happens in one go (when the gcc wrapper I spoke of earlier is in place) - End user installers We need something like nsiswrapper for Mac OS X environments. On Mac OS X environments, all applications are bundled in one directory, a so called '.app'. This directory contains some standard files (containing application information, an icon, etc) and of course the application itself along with it's dependencies and data files. These .app folders can be packed in a .zip file or a .dmg file which end-users can open directly to run/install the application
There probably are more tasks remaining to be done, but these are the things that came to my mind while writing this status update.
Regards,
Erik van Pienbroek
On Thu, Jun 18, 2009 at 11:30:19AM +0200, Erik van Pienbroek wrote:
http://svn.macosforge.org/repository/odcctools/trunk/ChangeLog.odcctools Because of this I replaced the odcctools from the iphone-dev project (based on cctools-622.3) with the odcctools tools from Apple (based on cctools-698.1).
That's good - does cctools now have real 64 bit support (ie. are they trying to make the code 64 bit clean -- previously we had to compile the whole thing with -m32)?
- Support for fat/universal binaries This requires multiple GCC compilers which are tied together by a small wrapper. This wrapper (which is called /usr/bin/gcc on regular Mac OS X environments) accepts arguments like '-arch i386 -arch ppc' and calls the corresponding compilers and uses lipo to merge the results together
What do we lose if we just build everything for, say, i386? PPC Macs are a bit long in the tooth now aren't they?
- Can we regenerate the .dylib files which are bundled with the SDK from source code (which is a requirement for Fedora) so that we get something like w32api?
My thought for this one is can we rebuild these files just from a table of the exported symbols? (ie. nm *.dylib)
- End user installers We need something like nsiswrapper for Mac OS X environments. On Mac OS X environments, all applications are bundled in one directory, a so called '.app'. This directory contains some standard files (containing application information, an icon, etc) and of course the application itself along with it's dependencies and data files. These .app folders can be packed in a .zip file or a .dmg file which end-users can open directly to run/install the application
Doesn't odcctools provide something to do this?
Rich.
Op donderdag 18-06-2009 om 12:43 uur [tijdzone +0100], schreef Richard W.M. Jones:
does cctools now have real 64 bit support (ie. are they trying to make the code 64 bit clean -- previously we had to compile the whole thing with -m32)?
x86_64 support is one of the major features in the latest Mac OS X (Snow Leopard) so I guess things have improved in that area. However, when trying to build the odcctools on my x86_64 laptop a compile error occurred. Help is appreciated to get the odcctools operational for x86_64 Linux hosts. Support for x86_64 targets should be the next step.
- Support for fat/universal binaries This requires multiple GCC compilers which are tied together by a small wrapper. This wrapper (which is called /usr/bin/gcc on regular Mac OS X environments) accepts arguments like '-arch i386 -arch ppc' and calls the corresponding compilers and uses lipo to merge the results together
What do we lose if we just build everything for, say, i386? PPC Macs are a bit long in the tooth now aren't they?
Support for ppc environments could be dropped as only Intel-based Macintosh'es were fabricated and sold in the last few years. However, fat/universal binaries are still used nowadays containing i386 and x86_64 binaries. I think we should aim for those two targets.
- Can we regenerate the .dylib files which are bundled with the SDK from source code (which is a requirement for Fedora) so that we get something like w32api?My thought for this one is can we rebuild these files just from a table of the exported symbols? (ie. nm *.dylib)
Would that be legal enough? I've heard rumors on several places that such acts are considered 'reverse engineering' which isn't allowed/questionable. The only way to create something like this in a fully legal way would be by using the public Apple documentation.
- End user installers We need something like nsiswrapper for Mac OS X environments. On Mac OS X environments, all applications are bundled in one directory, a so called '.app'. This directory contains some standard files (containing application information, an icon, etc) and of course the application itself along with it's dependencies and data files. These .app folders can be packed in a .zip file or a .dmg file which end-users can open directly to run/install the application
Doesn't odcctools provide something to do this?
Not that I'm aware of. The odcctools only provide a set of tools which offer the same kind of functionality as with binutils for Linux environments (linker, assembler, etc).
Regards,
Erik van Pienbroek
On Fri, Jun 19, 2009 at 10:57:30PM +0200, Erik van Pienbroek wrote:
Would that be legal enough? I've heard rumors on several places that such acts are considered 'reverse engineering' which isn't allowed/questionable. The only way to create something like this in a fully legal way would be by using the public Apple documentation.
If it works, I can check with Red Hat Legal. I'm highly doubtful that a simple list of symbols can be protected, but we would get a lawyer decision on it.
Rich.
On Fri, Jun 19, 2009 at 10:16:35PM +0100, Richard W.M. Jones wrote:
On Fri, Jun 19, 2009 at 10:57:30PM +0200, Erik van Pienbroek wrote:
Would that be legal enough? I've heard rumors on several places that such acts are considered 'reverse engineering' which isn't allowed/questionable. The only way to create something like this in a fully legal way would be by using the public Apple documentation.
If it works, I can check with Red Hat Legal. I'm highly doubtful that a simple list of symbols can be protected, but we would get a lawyer decision on it.
Its a question for Fedora Legal really
http://www.redhat.com/archives/fedora-legal-list/
Regards, Daniel
Op donderdag 18-06-2009 om 11:30 uur [tijdzone +0200], schreef Erik van Pienbroek:
I'm still rebuilding all the packages, but I hope to get more satisfying results than before.
The results really were more satisfying than before :)
With the new toolchain (based on the Mac OS X 10.5 SDK) all the strange side effects I had were solved. For people interested, I've also pushed binary packages of two open source projects of mine based on the Mac OS X toolchain online at http://www.nntpgrab.nl/snapshots/osx/ and http://www.openftd.org/snapshots/osx/ for testing.
All my recent work on the Mac OS X toolchain has been published online at http://build2.openftd.org/darwinx/
The darwinx-sdk package has been adjusted so that the SRPM only contains the Mac OS X 10.5 SDK archive instead of the entire XCode suite.
A yum repository containing the binary (i586/noarch) and source RPM's has also been set up. To make use of this repository, drop the file http://build2.openftd.org/darwinx/darwinx.repo in /etc/yum.repos.d
There probably are more tasks remaining to be done, but these are the things that came to my mind while writing this status update.
And here are some more tasks which need to be done:
- Create wrapper scripts for commands like 'darwinx-env', 'darwinx-configure' and 'darwinx-make' This basically is porting the mingw32-runtime package to darwinx
- Automatic RPM Requires/Provides The package darwinx-filesystem contains the scripts /usr/lib/rpm/darwinx-find-provides.sh and /usr/lib/rpm/darwinx-find-requires.sh. These files currently try to execute i686-apple-darwin9-objdump to find out the dependencies, but as this tool isn't available in odcctools this script needs to be updated. Dependencies information can be retrieved using i686-apple-darwin9-otool -L somelib.dylib
- x86_64 host support The odcctools currently can't be compiled on x86_64 hosts. This needs to be investigated
- x86_64 target support One of the major features of the newest Mac OS X (Snow Leopard) is improved support for x86_64. We need to get an x86_64 compiler operational which can be used to create universal/fat binaries
- Strip the SDK headers Because of the legal issues it might be a good idea to find out which include headers from the Mac OS X SDK are required to get GUI libraries like Gtk and QT compiled and try to find out whether the licenses used in those headers are open enough for Fedora.
Would it be a good idea if I created a wiki page for this list of tasks to keep it more centralized?
Regards,
Erik van Pienbroek
On Fri, Jun 19, 2009 at 11:13:17PM +0200, Erik van Pienbroek wrote:
The darwinx-sdk package has been adjusted so that the SRPM only contains the Mac OS X 10.5 SDK archive instead of the entire XCode suite.
I'm not sure I understand what the difference is, but anyway what is the licensing like on each file? Can you run a script over them and gives us some figures, like:
GPLv2+ 20 headers APSL 1.0 15 headers ... ?
Debian have a script which does something like this, but I can't find it right at the moment ...
Rich.
Op vrijdag 19-06-2009 om 22:20 uur [tijdzone +0100], schreef Richard W.M. Jones:
On Fri, Jun 19, 2009 at 11:13:17PM +0200, Erik van Pienbroek wrote:
The darwinx-sdk package has been adjusted so that the SRPM only contains the Mac OS X 10.5 SDK archive instead of the entire XCode suite.
I'm not sure I understand what the difference is...
The darwinx-sdk package was initially using the XCode image (about 1GB) as Source0 in the .spec file (and the Mac OS X 10.5 SDK was extracted from that image during the %build phase). This resulted in the .src.rpm being over 1GB in size. Now I've changed that so the Mac OS X 10.5 SDK is used as Source0 instead of the entire XCode image (resulting in an .src.rpm of 50MB in size). The resulting binary RPM is still the same.
...but anyway what is the licensing like on each file? Can you run a script over them and gives us some figures, like:
GPLv2+ 20 headers APSL 1.0 15 headers ... ?
If such a script exists, sure
Regards,
Erik van Pienbroek
Hi all,
The darwinx toolchain is still going strong. I just published updated packages in the darwinx-testing repository [1][2].
What has changed between the last status update and now ? - The %{_darwinx_prefix} was changed from /usr/i686-apple-darwin9 to /usr/darwinx. This was done for universal binary support - The source code of the GCC wrapper (to create universal binaries) was found somewhere in the GCC tarball. This wrapper is now compiled along with darwinx-gcc and installed as /usr/bin/darwinx-gcc and /usr/bin/darwinx-g++. With these wrappers, one can compile source code for multiple architectures by using the arguments '-arch i386 -arch ppc -arch x86_64' along with the regular GCC arguments - The RPM scripts darwinx-find-provides.sh and darwinx-find-requires.sh have been implemented so dependency generation should work now - All the packages have been rebuild and now support both i386 and ppc environments. I also tried to build the packages with x86_64 support but I dropped it for now as it caused compile errors in cairo and pango (due to the removal of deprecated symbols in ATSUI)
As you can see, all the packages now contain universal binaries. For now the architectures ppc and i386 are used. I left in ppc for now because there is still some demand for it and it's more mature than x86_64. I plan to revisit x86_64 support when Mac OS X Snow Leopard gets released this September. By that time ppc support should be obsolete.
For people who want to experiment with x86_64 support, be aware that there is no x86_64-apple-darwin9-gcc compiler! Apple decided to add x86_64 support to the i686-apple-darwin9-gcc compiler only. To compile source code for a x86_64 target you have to use the command 'darwinx-gcc -arch x86_64 mycode.c -o myproject'
About integration in Fedora: I noticed that the Feature Freeze for Fedora 12 is just 2 weeks away [3]. I don't think that will be enough time to get all the legal issues cleared up, so I'm afraid we have to postpone the darwinx toolchain as a feature until Fedora 13. AFAIK nobody has started on getting the legal issues cleared up so that's the next major roadblock ahead of us. Help in this area is really appreciated. If somebody can help with getting these packages in RPMFusion then that would also be very appreciated.
Regards,
Erik van Pienbroek
[1]: http://build2.openftd.org/darwinx/darwinx.repo [2]: http://build2.openftd.org/darwinx/ [3]: https://fedoraproject.org/wiki/Releases/12
Erik van Pienbroek wrote:
Hi all,
The darwinx toolchain is still going strong. I just published updated packages in the darwinx-testing repository [1][2].
Very cool! I'm hoping to use this toolchain to add MacOS X support to the automatic builds of NASM on http://www.nasm.us/.
ALL those binaries are build automatically on a Fedora system! This requires two compilers which are currently not in Fedora or RPMFusion to the best of my knowledge: DJGPP (for MS-DOS support) and OpenWatcom (for OS/2 support.)
DJGPP already comespackaged as RPMs from:
... and it would be really cool to get those or something like them into Fedora... I have been using them for quite a while with great success.
-hpa
On Sun, Jul 12, 2009 at 12:49:25AM +0200, Erik van Pienbroek wrote:
About integration in Fedora: I noticed that the Feature Freeze for Fedora 12 is just 2 weeks away [3]. I don't think that will be enough time to get all the legal issues cleared up, so I'm afraid we have to postpone the darwinx toolchain as a feature until Fedora 13. AFAIK nobody has started on getting the legal issues cleared up so that's the next major roadblock ahead of us. Help in this area is really appreciated. If somebody can help with getting these packages in RPMFusion then that would also be very appreciated.
Could you give a quick summary of the remaining legal issues?
Rich.
Op zondag 12-07-2009 om 12:22 uur [tijdzone +0100], schreef Richard W.M. Jones:
On Sun, Jul 12, 2009 at 12:49:25AM +0200, Erik van Pienbroek wrote:
About integration in Fedora: I noticed that the Feature Freeze for Fedora 12 is just 2 weeks away [3]. I don't think that will be enough time to get all the legal issues cleared up, so I'm afraid we have to postpone the darwinx toolchain as a feature until Fedora 13. AFAIK nobody has started on getting the legal issues cleared up so that's the next major roadblock ahead of us. Help in this area is really appreciated. If somebody can help with getting these packages in RPMFusion then that would also be very appreciated.
Could you give a quick summary of the remaining legal issues?
The darwinx toolchain consists of at these base packages: - cctools/odcctools (the darwin equivalent of binutils) - the Mac OS X SDK (containing system headers and libraries) - gcc (Apple's forked version)
The cctools are provided by Apple [1], but these are mostly targeted for real Mac OS X environments. So some patches were collected to get it operational on other environments in a project called odcctools. The script to patch the cctools and the individual patches are maintained at [2]. The odcctools development seem to be reasonable active these days.
The cctools project (and thus also odcctools) is licensed under the APSL2.0 license. Upon a closer look (a grep on 'license') I've noticed that all the files from the 'as' part are licensed under the GPL1+ license (whoa, that's old!) or the GPL2+ license (the code is forked from the GNU Assembler/GAS project).
There are also some other files in cctools/odcctools which are licensed under the GPLv1+/GPLv2+: include/coff/syment.h (GPLv2+) include/coff/scnhdr.h (GPLv2+) include/coff/aouthdr.h (GPLv2+) include/coff/ms_dos_stub.h (GPLv2+) include/coff/filehdr.h (GPLv2+) include/opcode/arm.h (GPLv1+)
Unfortunately, also some APSL 1.0/APSL 1.1 files are involved: include/foreign/libkern/machine/OSByteOrder.h (APSL 1.1) include/foreign/libkern/OSByteOrder.h (APSL 1.1) include/foreign/architecture/i386/sel.h (APSL 1.0) include/foreign/architecture/i386/frame.h (APSL 1.0) include/foreign/architecture/i386/fpu.h (APSL 1.0) include/foreign/mach/ppc/thread_status.h (APSL 1.1) otool/notify.h (APSL 1.0)
The APSL 1.0 and APSL 1.1 files are a no-go for Fedora.. We might want to ask Fedora Legal to get Apple to relicense these files.
For GCC I didn't do a license audit, but I don't foresee any problems with it (as Apple is bound to publish their changes to GCC in a GPL-compatible license).
The major license problem lies in the SDK. The SDK is only available for registered users from the Apple website (free registration) and is bundled along with XCode.
The SDK contains a bunch of header files and (binary) libraries. The header files are published under an open source license so I guess that we are allowed to redistribute them. The problem lies in the licenses involved. The SDK contains a mix of various licenses like APSL 1.0, APSL 1.1, APSL 2.0, GPLv2+ and LGPLv2+. I didn't make a list yet of header files which contain a forbidden license (APSL 1.0/APSL 1.1). But for these files, we might also want to ask Fedora Legal to get Apple to relicense these files.
Another problem with the SDK is that the libraries bundled with the SDK are only available in binary format. For most libraries we could work around this by creating stub libraries (so that the compilation of other libraries and applications can succeed). Something similar is also done with MinGW so we might find useful code or scripts there to generate such stubs.
I think that some libraries can't be stubbed like static libraries which provide program initialization code. IIRC, the source code for such static libraries is available, but again published under a forbidden license.
To summarize: - We need to create a list of header files in the SDK which contain an forbidden license - We need to create stubs for the libraries bundled with the SDK - We need to get Apple to relicense the forbidden files
So that's basically where we're at right now from a legal point of view.
Regards,
Erik van Pienbroek
[1]: http://opensource.apple.com/release/developer-tools-313/ [2]: http://svn.macosforge.org/repository/odcctools/trunk/
On 07/11/2009 03:49 PM, Erik van Pienbroek wrote:
Hi all,
The darwinx toolchain is still going strong. I just published updated packages in the darwinx-testing repository [1][2].
The darwinx-odcctools conflicts with gcc-objc, which seems like a real problem to me. I can't figure out *why* the conflict, though (it's marked manually in the specfile, but there doesn't seem to be any real reason for it??)
-hpa
Op dinsdag 28-07-2009 om 21:43 uur [tijdzone -0700], schreef H. Peter Anvin:
On 07/11/2009 03:49 PM, Erik van Pienbroek wrote:
Hi all,
The darwinx toolchain is still going strong. I just published updated packages in the darwinx-testing repository [1][2].
The darwinx-odcctools conflicts with gcc-objc, which seems like a real problem to me. I can't figure out *why* the conflict, though (it's marked manually in the specfile, but there doesn't seem to be any real reason for it??)
Yeah that's right. I manually added the Conflicts: gcc-objc. I forgot to add a comment with the motivation to the .spec file. IIRC, there was a compile error with the odcctools when gcc-objc is installed. As I didn't had time to research it in depth at that moment I added the conflict to the .spec file to remind me that more research was needed.
You could remove the conflict and see what happens :)
Speaking about the darwinx toolchain: In my last attempt I've used GCC 4.2. However, when trying to compile Qt I noticed that libstdc++ is missing from the GCC 4.2 tarball.. libstdc++ is only bundled with GCC 4.0 so I'm thinking about downgrading the GCC and rebuilding everything again (while hoping nothing blows up)
Regards,
Erik van Pienbroek
PS. You don't need to CC me as I'm already subscribed to the fedora-mingw list.
On 07/29/2009 03:01 AM, Erik van Pienbroek wrote:
Yeah that's right. I manually added the Conflicts: gcc-objc. I forgot to add a comment with the motivation to the .spec file. IIRC, there was a compile error with the odcctools when gcc-objc is installed. As I didn't had time to research it in depth at that moment I added the conflict to the .spec file to remind me that more research was needed.
You could remove the conflict and see what happens :)
It seems to work if I force the install. I haven't been able to rebuild the srpms, though, which makes me somewhat sad as I was hoping to use this on a Fedora 10 server, but oh well...
-hpa
Op donderdag 30-07-2009 om 15:19 uur [tijdzone -0700], schreef H. Peter Anvin:
It seems to work if I force the install. I haven't been able to rebuild the srpms, though, which makes me somewhat sad as I was hoping to use this on a Fedora 10 server, but oh well...
What errors do you get when building the SRPMS? The SRPMS were created on a Rawhide environment (without the LZMA compression which was recently added to RPM).
Regards,
Erik van Pienbroek
On 07/30/2009 03:32 PM, Erik van Pienbroek wrote:
Op donderdag 30-07-2009 om 15:19 uur [tijdzone -0700], schreef H. Peter Anvin:
It seems to work if I force the install. I haven't been able to rebuild the srpms, though, which makes me somewhat sad as I was hoping to use this on a Fedora 10 server, but oh well...
What errors do you get when building the SRPMS? The SRPMS were created on a Rawhide environment (without the LZMA compression which was recently added to RPM).
Regards,
Erik van Pienbroek
: terminus 20 ; : terminus 19 ; do32 rpmbuild --target i386 --rebuild darwinx-odcctools-691.1-0.20090617.6.fc12.src.rpm Installing darwinx-odcctools-691.1-0.20090617.6.fc12.src.rpm Building target platforms: i386 Building for target i386 error: Failed build dependencies: /usr/lib/gcc/i586-redhat-linux is needed by darwinx-odcctools-691.1-0.20090617.6.fc10.src
It has hard-coded needing the 32-bit-only compiler...
On 07/30/2009 03:48 PM, H. Peter Anvin wrote:
: terminus 20 ; : terminus 19 ; do32 rpmbuild --target i386 --rebuild darwinx-odcctools-691.1-0.20090617.6.fc12.src.rpm Installing darwinx-odcctools-691.1-0.20090617.6.fc12.src.rpm Building target platforms: i386 Building for target i386 error: Failed build dependencies: /usr/lib/gcc/i586-redhat-linux is needed by darwinx-odcctools-691.1-0.20090617.6.fc10.src
It has hard-coded needing the 32-bit-only compiler...
Hm... removing the "temporary hack for smock" lines and it seems to work...
-hpa
Op donderdag 30-07-2009 om 15:48 uur [tijdzone -0700], schreef H. Peter Anvin:
On 07/30/2009 03:32 PM, Erik van Pienbroek wrote:
Op donderdag 30-07-2009 om 15:19 uur [tijdzone -0700], schreef H. Peter Anvin:
It seems to work if I force the install. I haven't been able to rebuild the srpms, though, which makes me somewhat sad as I was hoping to use this on a Fedora 10 server, but oh well...
What errors do you get when building the SRPMS? The SRPMS were created on a Rawhide environment (without the LZMA compression which was recently added to RPM).
Regards,
Erik van Pienbroek
: terminus 20 ; : terminus 19 ; do32 rpmbuild --target i386 --rebuild darwinx-odcctools-691.1-0.20090617.6.fc12.src.rpm Installing darwinx-odcctools-691.1-0.20090617.6.fc12.src.rpm Building target platforms: i386 Building for target i386 error: Failed build dependencies: /usr/lib/gcc/i586-redhat-linux is needed by darwinx-odcctools-691.1-0.20090617.6.fc10.src
It has hard-coded needing the 32-bit-only compiler...
Ah yes, that's also something which needed more research. Others [1][2] have had issues with getting the odcctools compiled on 64bit hosts. You could try to ignore the build dependency and see if something useful gets produced or whether a compile errors occurs.
Regards,
Erik van Pienbroek
[1]: http://devs.openttd.org/~truebrain/compile-farm/apple-darwin9.txt [2]: http://code.google.com/p/iphone-dev/issues/detail?id=14&colspec=ID% 20Type%20Status%20Opsys%20CPU%20Priority%20Owner%20Summary
-
Daniel P. Berrange -
Erik van Pienbroek -
Farkas Levente -
H. Peter Anvin -
Kevin Kofler -
Richard W.M. Jones