Mac OS X cross-compiler coming soon to a Fedora near you (or maybe not?)
by Erik van Pienbroek
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
14 years, 9 months
stripping of DLLs?
by Adam Goode
Hi,
I am looking at the comtents of
/usr/i686-pc-mingw32/sys-root/mingw/bin/ with i686-pc-mingw32-nm. There
are a lot of symbols there!
Shouldn't these all be stripped? Is there a bug in the search script?
Thanks,
Adam
14 years, 10 months
Interest in mingw wxWidgets
by Max Jonathan Spaulding
Hi,
I have a need for wxWidgets in a mingw app and will be building my own libs in
a few weeks or next month sometime.
I was wondering 1, if a wxWidgets package for mingw would be useful to anyone
else but me?
and 2, if anyone would be interested in being a co-maintainer for this package
with me?
-Max
--
Max Jonathan Spaulding - MC2 Research, LLC
3658 Shoshone St. Denver, Co 80211
email: maxj(a)groff.net - phone: (720) 854-5434
linkedin: http://www.linkedin.com/in/maxjspaulding
14 years, 10 months
rpms/mingw32-sqlite/devel sqlite-3.6.13-iotest-nodirsync.patch, NONE, 1.1 sqlite-3.6.12-memalign.patch, 1.1, NONE sqlite-3.6.12-no-sqlite-doc.patch, 1.1, NONE
by sailer
Author: sailer
Update of /cvs/pkgs/rpms/mingw32-sqlite/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv17059
Added Files:
sqlite-3.6.13-iotest-nodirsync.patch
Removed Files:
sqlite-3.6.12-memalign.patch sqlite-3.6.12-no-sqlite-doc.patch
Log Message:
clean up patches
sqlite-3.6.13-iotest-nodirsync.patch:
--- NEW FILE sqlite-3.6.13-iotest-nodirsync.patch ---
diff -up sqlite-3.6.13/test/io.test.nodirsync sqlite-3.6.13/test/io.test
--- sqlite-3.6.13/test/io.test.nodirsync 2009-05-14 12:12:21.000000000 +0300
+++ sqlite-3.6.13/test/io.test 2009-05-14 12:13:51.000000000 +0300
@@ -426,7 +426,8 @@ sqlite3_simulate_device -char safe_appen
# on the journal file between steps (2) and (3) above.
#
if {$::tcl_platform(platform)=="unix"} {
- set expected_sync_count 3
+ # normally 3 but with -DSQLITE_DISABLE_DIRSYNC its 2
+ set expected_sync_count 2
} else {
set expected_sync_count 2
}
--- sqlite-3.6.12-memalign.patch DELETED ---
--- sqlite-3.6.12-no-sqlite-doc.patch DELETED ---
14 years, 10 months
rpms/mingw32-sqlite/devel .cvsignore, 1.3, 1.4 mingw32-sqlite.spec, 1.8, 1.9 sources, 1.3, 1.4
by sailer
Author: sailer
Update of /cvs/pkgs/rpms/mingw32-sqlite/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv15979
Modified Files:
.cvsignore mingw32-sqlite.spec sources
Log Message:
update to 3.6.14.2, enable debuginfo
Index: .cvsignore
===================================================================
RCS file: /cvs/pkgs/rpms/mingw32-sqlite/devel/.cvsignore,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- .cvsignore 23 Apr 2009 11:39:18 -0000 1.3
+++ .cvsignore 25 Jun 2009 10:18:52 -0000 1.4
@@ -1,2 +1 @@
-sqlite-3.6.6.2.tar.gz
-sqlite-3.6.12.tar.gz
+sqlite-3.6.14.2.tar.gz
Index: mingw32-sqlite.spec
===================================================================
RCS file: /cvs/pkgs/rpms/mingw32-sqlite/devel/mingw32-sqlite.spec,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -p -r1.8 -r1.9
--- mingw32-sqlite.spec 23 Jun 2009 09:50:06 -0000 1.8
+++ mingw32-sqlite.spec 25 Jun 2009 10:18:52 -0000 1.9
@@ -1,13 +1,17 @@
-%define __strip %{_mingw32_strip}
-%define __objdump %{_mingw32_objdump}
-%define _use_internal_dependency_generator 0
-%define __find_requires %{_mingw32_findrequires}
-%define __find_provides %{_mingw32_findprovides}
+%global __strip %{_mingw32_strip}
+%global __objdump %{_mingw32_objdump}
+%global _use_internal_dependency_generator 0
+%global __find_requires %{_mingw32_findrequires}
+%global __find_provides %{_mingw32_findprovides}
%define __debug_install_post %{_mingw32_debug_install_post}
+# bcond default logic is nicely backwards...
+%bcond_without tcl
+%global tclversion 8.5
+
Name: mingw32-sqlite
-Version: 3.6.12
-Release: 5%{?dist}
+Version: 3.6.14.2
+Release: 1%{?dist}
Summary: MinGW Windows port of sqlite embeddable SQL database engine
License: Public Domain
@@ -22,8 +26,7 @@ BuildArch: noarch
Patch1: sqlite-3.6.12-libdl.patch
# Avoid insecure sprintf(), use a system path for lempar.c, patch from Debian
Patch2: sqlite-3.6.6.2-lemon-snprintf.patch
-Patch3: sqlite-3.6.12-no-sqlite-doc.patch
-Patch4: sqlite-3.6.12-memalign.patch
+Patch3: sqlite-3.6.13-iotest-nodirsync.patch
# Patches for MinGW port.
Patch1000: mingw32-sqlite-3.6.12-no-undefined.patch
@@ -42,6 +45,11 @@ BuildRequires: /usr/bin/tclsh
Requires: pkgconfig
+%if %{with tcl}
+BuildRequires: /usr/bin/tclsh
+BuildRequires: mingw32-tcl
+%endif
+
%description
SQLite is a C library that implements an SQL database engine. A large
@@ -63,8 +71,7 @@ for Windows.
%setup -q -n sqlite-%{version}
%patch1 -p1 -b .libdl
%patch2 -p1 -b .lemon-sprintf
-%patch3 -p1 -b .no-sqlite-doc
-%patch4 -p1 -b .align
+%patch3 -p1 -b .nodirsync
%patch1000 -p1
# Ships with an old/broken version of libtool which cannot create
@@ -85,7 +92,10 @@ export config_TARGET_EXEEXT=.exe
# add compile flags to enable rtree, fts3
export MINGW32_CFLAGS="%{_mingw32_cflags} -DSQLITE_ENABLE_COLUMN_METADATA=1 -DSQLITE_DISABLE_DIRSYNC=1 -DSQLITE_ENABLE_FTS3=3 -DSQLITE_ENABLE_RTREE=1 -fno-strict-aliasing"
-%{_mingw32_configure}
+%{_mingw32_configure} %{!?with_tcl:--disable-tcl} \
+ --enable-threadsafe \
+ --enable-threads-override-locks \
+ --enable-load-extension
make
@@ -98,6 +108,10 @@ rm $RPM_BUILD_ROOT%{_mingw32_libdir}/lib
chmod 0644 $RPM_BUILD_ROOT%{_mingw32_libdir}/libsqlite3.dll.a
+%if %{with tcl}
+install -d -m755 $RPM_BUILD_ROOT%{_mingw32_datadir}/tcl%{tclversion}/sqlite3/
+mv $RPM_BUILD_ROOT%{_datadir}/tcl%{tclversion}/sqlite3/pkgIndex.tcl $RPM_BUILD_ROOT%{_mingw32_datadir}/tcl%{tclversion}/sqlite3/
+%endif
%clean
rm -rf $RPM_BUILD_ROOT
@@ -113,10 +127,14 @@ rm -rf $RPM_BUILD_ROOT
%{_mingw32_includedir}/sqlite3.h
%{_mingw32_includedir}/sqlite3ext.h
%{_mingw32_libdir}/pkgconfig/sqlite3.pc
-
+%if %{with tcl}
+%{_mingw32_datadir}/tcl%{tclversion}/sqlite3/
+%{_mingw32_datadir}/tcl%{tclversion}/sqlite3/pkgIndex.tcl
+%endif
%changelog
-* Mon Jun 22 2009 Thomas Sailer <t.sailer(a)alumni.ethz.ch> - 3.6.12-5
+* Tue Jun 23 2009 Thomas Sailer <t.sailer(a)alumni.ethz.ch> - 3.6.14.2-1
+- update to 3.6.14.2
- add debuginfo packages
* Thu Apr 23 2009 Thomas Sailer <t.sailer(a)alumni.ethz.ch> - 3.6.12-4
Index: sources
===================================================================
RCS file: /cvs/pkgs/rpms/mingw32-sqlite/devel/sources,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- sources 23 Apr 2009 11:39:18 -0000 1.3
+++ sources 25 Jun 2009 10:18:53 -0000 1.4
@@ -1 +1 @@
-13600865a69a3f54d2ac42a0d6b743db sqlite-3.6.12.tar.gz
+4c074691b48cd45854899ae4fece6301 sqlite-3.6.14.2.tar.gz
14 years, 10 months
rpms/mingw32-filesystem/devel mingw32-filesystem.spec,1.24,1.25
by Erik van Pienbroek
Author: epienbro
Update of /cvs/pkgs/rpms/mingw32-filesystem/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv20170
Modified Files:
mingw32-filesystem.spec
Log Message:
Updated ChangeLog comment from previous version as the RPM variable
__debug_install_post needs to be overridden instead of __os_install_post
for -debuginfo subpackage generation
Index: mingw32-filesystem.spec
===================================================================
RCS file: /cvs/pkgs/rpms/mingw32-filesystem/devel/mingw32-filesystem.spec,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -p -r1.24 -r1.25
--- mingw32-filesystem.spec 22 Jun 2009 10:18:35 -0000 1.24
+++ mingw32-filesystem.spec 24 Jun 2009 17:27:24 -0000 1.25
@@ -2,7 +2,7 @@
Name: mingw32-filesystem
Version: 52
-Release: 1%{?dist}
+Release: 2%{?dist}
Summary: MinGW base filesystem and environment
Group: Development/Libraries
@@ -165,11 +165,16 @@ rm -rf $RPM_BUILD_ROOT
%changelog
-* Mon Jun 22 2009 Erik van Pienbroek <epienbro(a)fedoraproject.org> - 52-0
+* Wed Jun 24 2009 Erik van Pienbroek <epienbro(a)fedoraproject.org> - 52-2
+- Updated ChangeLog comment from previous version as the RPM variable
+ __debug_install_post needs to be overridden instead of __os_install_post
+ for -debuginfo subpackage generation
+
+* Mon Jun 22 2009 Erik van Pienbroek <epienbro(a)fedoraproject.org> - 52-1
- Add script to create -debuginfo subpackages
This script was created by Fridrich Strba
- All mingw32 packages now need to add these lines to their .spec files:
- %%define __os_install_post %%{_mingw32_debug_install_post}
+ %%define __debug_install_post %%{_mingw32_debug_install_post}
%%{_mingw32_debug_package}
* Thu Jun 4 2009 Adam Goode <adam(a)spicenitz.org> - 51-1
14 years, 10 months
[Bug 507751] New: python-magic depends on older file package.
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: python-magic depends on older file package.
https://bugzilla.redhat.com/show_bug.cgi?id=507751
Summary: python-magic depends on older file package.
Product: Fedora
Version: 11
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: mingw32-gcc
AssignedTo: rjones(a)redhat.com
ReportedBy: dulsi(a)identicalsoftware.com
QAContact: extras-qa(a)fedoraproject.org
CC: berrange(a)redhat.com, rjones(a)redhat.com,
fedora-mingw(a)lists.fedoraproject.org
Classification: Fedora
Description of problem: python-magic depends on file=5.03-1.fc11 but
file-5.03-2.fc11 is installed. mingw32-gcc-c++ fails to install.
Version-Release number of selected component (if applicable):
python-magic-5.03-1.fc11
How reproducible: Try to install python-magic or mingw-gcc-c++.
Steps to Reproduce:
1. yum install python-magic
Actual results:
python-magic-5.03-1.fc11.i586 from fedora has depsolving problems
--> Missing Dependency: file = 5.03-1.fc11 is needed by package
python-magic-5.03-1.fc11.i586 (fedora)
Error: Missing Dependency: file = 5.03-1.fc11 is needed by package
python-magic-5.03-1.fc11.i586 (fedora)
Expected results: Success
Additional info:
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
14 years, 10 months
Compile error
by Fabrício Godoy
I'm getting error compiling in Fedora 11, in Fedora 10 I was compiling
without errors.
Please, see attached file.
14 years, 10 months
