mingw32-SDL_image and mingw32-SDL_mixer
by Jason Woofenden
Hi all,
I'm pretty new to this packaging and cross-compiling, but I put
together a couple packages anyway:
http://jasonwoof.com/downloads/mingw32-SDL_image-1.2.6-1.fc11.src.rpm
http://jasonwoof.com/downloads/mingw32-SDL_mixer-1.2.8-1.fc11.src.rpm
They seem to work quite well for me, but I don't really know what I'm
doing, so I'd appreciate more knowledgeable folk looking over my spec
files.
Here's what I did and where everything came from: (all in F11)
1) I set up my .rpmmacros so it would store sources in separate
directories by package name-version by adding this line:
%_sourcedir %{_topdir}/SOURCES/%{name}-%{version}
I was worried that multiple source rpms would have files in them with
the same name (which turned out to be the case) and I wanted to make
sure I could tell what packages what files came from.
2) I used yumdownloader to download source rpms for SDL SDL_mixer
SDL_image and SDL and installed them in my local rpmbuild tree
3) I duplicated SOURCES/SDL_image-1.2.6/ to SOURCES/mingw32-SDL_image-1.2.6/
4) I copied SPECS/mingw32-SDL-1.2.13.spec to SPECS/mingw32-SDL_image-1.2.6.spec
5) I edited that new spec file, mostly by looking at existing
SDL_image-1.2.6.spec and pulling useful parts from it. tweaking as
neccesary.
And basically did the same for SDL_mixer.
Some notes:
I didn't modify anything in the SOURCES folder (just copied whole
folders as described above).
I used all the patches that were used for the native versions.
I commented out lines to install (and build in one case) little
executable programs from both packages that I didn't understand the
point of.
I've cross-compiled my game (vor) which uses both of these libraries,
and it works great under wine. (Gets at least 40% better framerate
under wine than it does when compiled for linux.) Though I have not
tested them on Windows.
I have a fedoraproject.org account (so I can edit the wiki and such)
but don't have any connections or access or anything to get these into
the fedora distrobution. If/when they are ready, I'd love someone to
take care of this, or help me do it. Right now I don't even know what
the process is.
Looking forward to hearing your thoughts/feedback.
Take care, - Jason
14 years, 5 months
[Bug 513826] New: .pc files for mingw32 library include the sysroot
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: .pc files for mingw32 library include the sysroot
https://bugzilla.redhat.com/show_bug.cgi?id=513826
Summary: .pc files for mingw32 library include the sysroot
Product: Fedora
Version: 11
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: mingw32-glib2
AssignedTo: rjones(a)redhat.com
ReportedBy: pbonzini(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: lfarkas(a)lfarkas.org, t.sailer(a)alumni.ethz.ch,
berrange(a)redhat.com, rjones(a)redhat.com,
fedora-mingw(a)lists.fedoraproject.org
Depends on: 513825
Classification: Fedora
Target Release: ---
Description of problem:
The paths in the .pc files for mingw32 include the
/usr/i686-pc-mingw32/sys-root component. This would prevent using them within
the MSYS shell, for example.
It would be more correct to install them without the path and, in a
i686-pc-mingw32-pkg-config (see bug 513825), provide the PKG_CONFIG_SYSROOT_DIR
variable. The script would work like this then:
#! /bin/sh
PKG_CONFIG_SYSROOT_DIR=`i686-pc-mingw32-gcc --print-sysroot`
prefix=$PKG_CONFIG_SYSROOT_DIR/mingw
PKG_CONFIG_LIBDIR=$prefix/lib/pkgconfig:$prefix/share/pkgconfig
export PKG_CONFIG_LIBDIR # PKG_CONFIG_SYSROOT_DIR
exec pkg-config "$@"
--
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, 7 months
[Bug 514187] New: compiled mingw files include the sys-root path
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: compiled mingw files include the sys-root path
https://bugzilla.redhat.com/show_bug.cgi?id=514187
Summary: compiled mingw files include the sys-root path
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: redhat-rpm-config
AssignedTo: jonathan(a)jonmasters.org
ReportedBy: pbonzini(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: lfarkas(a)lfarkas.org, t.sailer(a)alumni.ethz.ch,
berrange(a)redhat.com, pmatilai(a)redhat.com,
rjones(a)redhat.com, erik-fedora(a)vanpienbroek.nl,
jonathan(a)jonmasters.org,
fedora-mingw(a)lists.fedoraproject.org
Blocks: 513826
Classification: Fedora
Target Release: ---
Clone Of: 513826
+++ This bug was initially created as a clone of Bug #513826 +++
Description of problem:
The paths in the .pc files for mingw32 include the
/usr/i686-pc-mingw32/sys-root component. This would prevent using them within
the MSYS shell, for example.
It would be more correct to install them without the path and, in a
i686-pc-mingw32-pkg-config (see bug 513825), provide the PKG_CONFIG_SYSROOT_DIR
variable. The script would work like this then:
#! /bin/sh
PKG_CONFIG_SYSROOT_DIR=`i686-pc-mingw32-gcc --print-sysroot`
prefix=$PKG_CONFIG_SYSROOT_DIR/mingw
PKG_CONFIG_LIBDIR=$prefix/lib/pkgconfig:$prefix/share/pkgconfig
export PKG_CONFIG_LIBDIR # PKG_CONFIG_SYSROOT_DIR
exec pkg-config "$@"
--- Additional comment from pbonzini(a)redhat.com on 2009-07-26 15:15:36 EDT ---
To clarify: the paths work, but still they are not correct. Right now if I
want to install MSYS under Wine I have two choices:
1) I proceed as in bug 513819 so that the Fedora mingw root is visible under
MSYS. Then however I cannot use pkg-config under MSYS.
2) I copy everything from /usr/i686-pc-mingw32/sys-root/mingw under Wine's
c:/mingw, and then I lose all the updates that come through Fedora's package
manager. I also have to update the .pc files manually.
It's a lose-lose situation, and PKG_CONFIG_SYSROOT_DIR was meant exactly to
support this.
--- Additional comment from erik-fedora(a)vanpienbroek.nl on 2009-07-26 18:20:13
EDT ---
Why would you want to install MSYS under Wine? MSYS just provides some tools
which we already have native on Linux. The bash/sh from MSYS is also way slower
than native bash/sh
--- Additional comment from pbonzini(a)redhat.com on 2009-07-27 03:05:30 EDT ---
For testing. I want to make sure that there are no hidden bits in the
configure/make files that *only* work when crosscompiling (the typical example
is forgetting to quote a variable that could contain Windows \ paths).
Besides, the idea of a sysroot is to match *exactly* what would be on the
non-native system. I could take the Fedora sysroot and copy it to a real
Windows machine, and it should just work. Now instead if I do this and install
the Windows version of pkg-config, it will not work because the .pc files
contains pointers to the Fedora images.
This is not easy to fix (it is a "flag day" bug, you have to fix all packages
at once), so it may not have a high priority. But it is serious.
--- Additional comment from rjones(a)redhat.com on 2009-07-27 04:53:55 EDT ---
(In reply to comment #3)
> For testing. I want to make sure that there are no hidden bits in the
> configure/make files that *only* work when crosscompiling (the typical example
> is forgetting to quote a variable that could contain Windows \ paths).
>
> Besides, the idea of a sysroot is to match *exactly* what would be on the
> non-native system. I could take the Fedora sysroot and copy it to a real
> Windows machine, and it should just work. Now instead if I do this and install
> the Windows version of pkg-config, it will not work because the .pc files
> contains pointers to the Fedora images.
This isn't how we install on Windows at all. We use NSIS to
build installers.
And the aim of this project is to free developers from having to
use Windows at all, not to allow people to copy binaries onto a
Windows machine and continue development there.
The *.pc files contain the correct paths for cross-compiling
to a Windows host from a Fedora build system, which is precisely
the aim of this project.
--- Additional comment from pbonzini(a)redhat.com on 2009-07-28 04:36:53 EDT ---
Created an attachment (id=355373)
--> (https://bugzilla.redhat.com/attachment.cgi?id=355373)
redhat-rpm-config part of the patch
The remaining part is to change the packages to do a change similar to what the
patch does to %{_mingw32_makeinstall}.
--
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, 7 months
[Bug 513825] New: missing i686-pc-mingw32-pkg-config
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: missing i686-pc-mingw32-pkg-config
https://bugzilla.redhat.com/show_bug.cgi?id=513825
Summary: missing i686-pc-mingw32-pkg-config
Product: Fedora
Version: 11
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: mingw32-glib2
AssignedTo: rjones(a)redhat.com
ReportedBy: pbonzini(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: lfarkas(a)lfarkas.org, t.sailer(a)alumni.ethz.ch,
berrange(a)redhat.com, rjones(a)redhat.com,
fedora-mingw(a)lists.fedoraproject.org
Blocks: 513824
Classification: Fedora
Target Release: ---
(Reported here for lack of a better place).
Description of problem:
When compiling a program that uses glib, the host pkg-config program is used,
and this might cause the version numbers in the library to have a mismatch with
the mingw version of glib.
Luckily, pkg-config is a *tool*, so it is first searched prefixed with $host.
It is enough to put this script in /usr/bin/i686-pc-mingw32-pkg-config then:
#! /bin/sh
prefix=`i686-pc-mingw32-gcc --print-sysroot`/mingw
PKG_CONFIG_PATH=$PKG_CONFIG_PATH${PKG_CONFIG_PATH:+:}$prefix/lib/pkgconfig
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$prefix/share/pkgconfig
export PKG_CONFIG_PATH
exec pkg-config "$@"
How reproducible:
You must have the latest F11 glib (2.20.4) installed, since mingw-glib2 is
still at 2.20.1.
Steps to reproduce:
1. Add c:\mingw links as explained in bug 513819
2. Install a touch program as explained in bug 513824
3. Try configure script in bug 513819 (./configure --host=i686-pc-mingw32)
Actual result:
The script diagnoses a version mismatch
Expected result:
The script should work.
Additional info:
This bug and bug 513824, if fixed, would allow to compile glib programs without
--disable-glibtest. Fixing bug 513819 however is enough to actually *run*
crosscompiled glib/gtk programs.
A similar bug applies to other packages with an independent -config script,
such as sdl. That is more problematic because sdl-config is searched as a
program, not as a tool. Still, installing i686-pc-mingw32-sdl-config would at
least allow the user to specify it manually with the SDL_CONFIG environment
variable.
--
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, 8 months
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
cross compilation wiki
by Maróy Ákos
Hi,
I find the Fedora MinGW project very exciting. As I've been playing
along with cross-compilation issues myself for some time,
and have found no single location for this kind of information, I
decided to open a wiki to collect such information into one place.
See the very initial form of this here: http://cross-compile.info/
Of course, the Fedora MinGW project is very well documented, and also
includes a repository. Thus there's some shared interest between the two
pages.
My hope is that this wiki will contain a range of information that is
related to cross-compilation. I'd really appreciate anyone interested
would consider contributing as well. Therefore I welcome all of you
interested to register at the wiki, and extend the pages as you see fit.
I'd be also glad to give interseted parties write access to the
subversion repository I created, so as the collect files in relation to
cross-compiling at a single location.
And of course, all feedback is welcome!
Akos
14 years, 9 months
DJGPP crosscompiler chain
by H. Peter Anvin
I have been using the following rpm ports of DJGPP (MS-DOS with DPMI),
maintained by Andris Pavenis, for quite a while now to compile DOS
binaries under Linux; they are used among other things
http://ap1.pp.fi/djgpp/
It would be great to see these in Fedora, too...
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
14 years, 9 months
Re: Rewinding the discussion on MinGW+Wine
by Paolo Bonzini
> The idea that Wine and cross-compilation are either isolated or
> "cooperate" is a false dichotomy. The only reason this problem occurs
> for you is that you're using some other glib which isn't mingw32-glib.
> Use mingw32-glib and our cross-compilation environment, or explain why
> we should support some other binary glib that we have no control over.
But I'm not! I'm just using *your* glib and I happen to have the
Linux one installed! When I said "non-mingw glib" I was referring to
the normal Linux glib.
>> 513824: definitely a hack, but one that we cannot skip if we want the
>> cross-compilation environment to cooperate Wine. It is extremely stupid
>> to use touch instead of open, but glib does it; bummer. Fixing it
>> upstream will require years to propagate to packages.
>
> Why can't this "other" glib (whatever it is) use /usr/bin/touch?
It is not "another" glib, it is glib-2.0.m4 that is the same for every
package and every architecture. It runs touch from within a runtime
test, so it tries to use a non-existing Windows touch.
>> 2) Problems in the default RPM macros. This can be skipped,
>> except maybe for making -mms-bitfields the default in the
>> compiler. I can bring this upstream.
>
> We used to require -mms-bitfields to make interoperable C structures.
> _If_ that's now the default, we can drop it.
It's not the default, we have to bring the case upstream then.
>> 513825, reprise. There is another aspect of this bug. When Wine is
>> installed, Autoconf executes run-time testcases. This can be seen as a
>> bug, but it is also a feature---and for three reasons.
>>
>> First, in most cases run-time testcases choose a conservative answer
>> when cross-compiling, so that allowing them would make for slimmer or
>> more efficient binaries.
>
> Nevertheless, we can't use wine at compile time, no matter how much
> better it might theoretically make things. We can't use it because
> (a) it doesn't work in Koji, and (b) cross-compilation should not need
> to run generated binaries at build time [autoconf section 6.6 Checking
> Runtime Behavior].
First of all, let's put aside Make-time generated binaries. They are
just complicating the discussion, the problem occurs with any program
that uses glib (*).
I understand perfectly why you do not want to use Wine at compile
time. Someone in the bugzilla audit trails said it does not require X
. And
that's not the reason indeed, just like the reason is not that it
requires a $HOME (it does not---just use WINEPREFIX). The reason is
that you want the packages to build on any architecture where the
cross-compiler builds, which makes lots of sense.
And I agree that run-time tests should not be needed.
My question is this one: where does the scope of Fedora MinGW end? Do
you want to discourage/allow/encourage *users* from coupling it with
Wine so that it is an *emulation* environment and the cross-compiler
becomes sort-of native? As I said, it wouldn't be unheard of; I know
of companies that do the same using Qemu's user-space Linux emulation.
And if so, do you agree that allowing run-time configure tests can be
advantageous because of possibly increased precision and easier setup?
Paolo
(*) Try it yourself. Install wine, glib2-devel, mingw-glib2, and run
this script:
cat > configure.ac << \EOF
AC_INIT
AM_PATH_GLIB_2_0(2.0.0)
AC_OUTPUT(Makefile)
EOF
cat > Makefile.in << \EOF
CC = @CC@
CFLAGS = -O2 -g
EXEEXT = @EXEEXT@
override CFLAGS += @GLIB_CFLAGS@
override LIBS += @GLIB_LIBS@
hello$(EXEEXT): hello.o ; $(CC) -o $@ $^ $(LIBS)
hello.o: hello.c
Makefile: Makefile.in config.status; ./config.status
config.status: configure; ./config.status --recheck
configure: configure.ac; autoconf
clean: ; rm config.status Makefile hello.o hello$(EXEEXT)
EOF
cat > hello.c << \EOF
#include <glib.h>
#include <stdio.h>
int main()
{
printf ("%s\n", g_strdup ("Hello, world!"));
}
EOF
aclocal && autoconf
./configure --host=i686-pc-mingw32 && make
./hello.exe
14 years, 9 months
