8:30 a.m.
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....
[13]: https://fedoraproject.org/wiki/Licensing:Main#Bad_Licenses
8:37 a.m.
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
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
9:29 a.m.
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.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 75 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
9:08 a.m.
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?
--
Levente "Si vis pacem para bellum!"
9:48 a.m.
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
11 a.m.
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/...
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
9:14 a.m.
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
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
9:20 a.m.
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/00046...
(see also the following messages).
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://et.redhat.com/~rjones/libguestfs/
See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html
9:27 a.m.
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/00046...
(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
9:57 a.m.
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.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 75 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
11:07 a.m.
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/00046...
>
> (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.
--
Levente "Si vis pacem para bellum!"
4:30 a.m.
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
6:43 a.m.
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.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
3:57 p.m.
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
4:16 p.m.
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.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
8:26 a.m.
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
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
4:13 p.m.
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
4:20 p.m.
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.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
4:31 p.m.
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
5:49 p.m.
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
11:33 p.m.
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:
http://ap1.pp.fi/djgpp/gcc/
... 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
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
6:22 a.m.
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.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
9:19 a.m.
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/
11:43 p.m.
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
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
5:01 a.m.
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.
5:19 p.m.
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
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
5:32 p.m.
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
5:48 p.m.
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...
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
6:01 p.m.
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
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
6:04 p.m.
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
5394
days inactive
5439
days old
30 comments
6 participants
participants (6)
-
Daniel P. Berrange -
Erik van Pienbroek -
Farkas Levente -
H. Peter Anvin -
Kevin Kofler -
Richard W.M. Jones