July 2009 - mingw - Fedora mailing-lists

Fwd: Goocanvas for Mingw32
by Richard W.M. Jones 28 Jan '12

28 Jan '12

Thanks Egil, I am forwarding your message and the spec file to the fedora-mingw mailing list. I looked quickly over the spec file and it looks good. Rich. ----- Forwarded message from Egil Kvaleberg <egil(a)kvaleberg.com> ----- Subject: Goocanvas for Mingw32 Date: Mon, 27 Apr 2009 13:54:27 +0200 From: Egil Kvaleberg <egil(a)kvaleberg.com> To: rjones(a)redhat.com I have played around with the Mingw32 for Fedora, and it absolutely seems like a very cool thing. For my purposes, I am using GTK2, which is supported, but I also need a canvas. I have been using Goocanvas (not sure what really is *the* canvas for GTK2, but I have been happy with Goocanvas). However, a Goocanvas package does not seem to be available, so I built one. Goocanvas may be of interest to others, so if you think it is suitable then please use the attached spec-file or tell me how to get involved. The spec-file for Fedora 11 is attached. Sincerely, Egil Kvaleberg -- Company: Kvaleberg AS Office: +47 22 44 31 75 Mobile: +47 920 22 780 Fax: +47 22 44 46 77 Web: http://www.kvaleberg.com/ ----- End forwarded message ----- -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v

3 4

[Bug 489100] New: No cross-DLL exceptions in mingw32 compilers
by Red Hat Bugzilla 29 Dec '11

29 Dec '11

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: No cross-DLL exceptions in mingw32 compilers https://bugzilla.redhat.com/show_bug.cgi?id=489100 Summary: No cross-DLL exceptions in mingw32 compilers Product: Fedora EPEL Version: el5 Platform: All OS/Version: Linux Status: NEW Severity: high Priority: low Component: mingw32-gcc AssignedTo: rjones(a)redhat.com ReportedBy: wolfgang.glas(a)ev-i.at QAContact: extras-qa(a)fedoraproject.org CC: lfarkas(a)lfarkas.org, berrange(a)redhat.com, rjones(a)redhat.com, fedora-mingw(a)lists.fedoraproject.org Classification: Fedora Version 4.3.2-12 of EPEL's version of the moingw32 cross-compiler do not support cross-DLL exceptions. I've attached the gcc bug report below. This make running a non-trivial C++ program impossible an renders the mingw32 toolchain unusable for real-world C++ programs. The mingw-w64 toolchain has solved this problem by supplying a shared libgcc, hopefully the mingw32 toolchain will follow this approach in the near future. Please keep on your tremendous work on providing the ming32 toolchain in the EPEL. TIA, Wolfgang -- 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.

1 15

[Bug 499992] New: Review Request: mingw32-WebKit - MinGW Windows web content engine library
by Red Hat Bugzilla 17 Dec '10

17 Dec '10

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Review Request: mingw32-WebKit - MinGW Windows web content engine library https://bugzilla.redhat.com/show_bug.cgi?id=499992 Summary: Review Request: mingw32-WebKit - MinGW Windows web content engine library Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: Package Review AssignedTo: nobody(a)fedoraproject.org ReportedBy: erik-fedora(a)vanpienbroek.nl QAContact: extras-qa(a)fedoraproject.org CC: notting(a)redhat.com, fedora-package-review(a)redhat.com, fedora-mingw(a)lists.fedoraproject.org Depends on: 499983,499986,499991 Classification: Fedora Spec URL: http://www.ftd4linux.nl/contrib/mingw32-WebKit.spec SRPM URL: http://www.ftd4linux.nl/contrib/mingw32-WebKit-1.1.5-1.fc11.src.rpm Description: WebKit is an open source web browser engine. Koji scratch build: none for now because mingw32-libsoup, mingw32-libxslt and mingw32-libidn aren't in Fedora yet Approved MinGW packaging guidelines are here: http://fedoraproject.org/wiki/Packaging/MinGW -- 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.

3 29

[Bug 508746] New: noarch MinGW debuginfo packages don't get placed in the debuginfo repository
by Red Hat Bugzilla 13 Oct '10

13 Oct '10

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: noarch MinGW debuginfo packages don't get placed in the debuginfo repository https://bugzilla.redhat.com/show_bug.cgi?id=508746 Summary: noarch MinGW debuginfo packages don't get placed in the debuginfo repository Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: mash AssignedTo: notting(a)redhat.com ReportedBy: erik-fedora(a)vanpienbroek.nl QAContact: extras-qa(a)fedoraproject.org CC: notting(a)redhat.com, jkeating(a)redhat.com, fedora-mingw(a)lists.fedoraproject.org Classification: Fedora This bug was originally reported at the rel-eng trac ( https://fedorahosted.org/rel-eng/ticket/1949 ), but I was asked to report this here: A few days ago we (the Fedora MinGW SIG) started experimenting with generating -debuginfo subpackages for our libraries. For this we've created some custom scripts to strip out debug information to separate files and added some RPM macro's to create -debuginfo subpackages containing these files. This has been discussed at http://lists.fedoraproject.org/pipermail/fedora-mingw/2009-June/001748.html The RPM scripts were added in mingw32-filesystem-52-1.fc12 and some of our regular MinGW packages were rebuild as can be seen at http://koji.fedoraproject.org/koji/buildinfo?buildID=111400 After waiting for the next rawhide push we discovered that the mingw32-glib2-debuginfo subpackage wasn't published in the rawhide-debuginfo repository. We think it's caused by the fact that our mingw32 packages are noarch. -- 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.

1 8

[Bug 504782] New: libpng: Interlaced Images Information Disclosure Vulnerability
by Red Hat Bugzilla 04 Aug '10

04 Aug '10

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: libpng: Interlaced Images Information Disclosure Vulnerability https://bugzilla.redhat.com/show_bug.cgi?id=504782 Summary: libpng: Interlaced Images Information Disclosure Vulnerability Product: Security Response Version: unspecified Platform: All OS/Version: Linux Status: NEW Status Whiteboard: source=gentoo,reported=20090606,public=20090604,impact =low? Keywords: Security Severity: medium Priority: medium Component: vulnerability AssignedTo: security-response-team(a)redhat.com ReportedBy: thoger(a)redhat.com CC: paul(a)city-fan.org, lfarkas(a)lfarkas.org, tgl(a)redhat.com, berrange(a)redhat.com, rjones(a)redhat.com, fedora-mingw(a)lists.fedoraproject.org Classification: Other Target Release: --- Quoting Secunia advisory SA35346: http://secunia.com/advisories/35346/ A vulnerability has been reported in libpng, which can be exploited by malicious people to disclose potentially sensitive information. The vulnerability is caused due to an error when processing 1-bit interlaced images. This can be exploited to disclose uninitialised memory via specially crafted images having widths that are not divisible by 8. The vulnerability is reported in versions prior to 1.2.37. -- 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.

1 21

[Bug 481433] New: w32api 3.13 dropped libglut32.a, we should package glut
by Red Hat Bugzilla 28 Jun '10

28 Jun '10

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: w32api 3.13 dropped libglut32.a, we should package glut https://bugzilla.redhat.com/show_bug.cgi?id=481433 Summary: w32api 3.13 dropped libglut32.a, we should package glut Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: mingw32-w32api AssignedTo: rjones(a)redhat.com ReportedBy: rjones(a)redhat.com QAContact: extras-qa(a)fedoraproject.org CC: berrange(a)redhat.com, rjones(a)redhat.com, fedora-mingw(a)lists.fedoraproject.org Classification: Fedora Target Release: --- As described here: http://www.mail-archive.com/cygwin-apps@cygwin.com/msg21163.html libglut32.a was dropped from the latest w32api package. Some of our packages depend on this. It seems the right way to do this is to package glut as a separate RPM. Note that SGI glut has a possibly non-free license, but there is a workalike called freeglut that we can use instead. http://freeglut.sourceforge.net/ -- 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.

1 2

[Bug 499987] New: Review Request: mingw32-curl - MinGW Windows port of curl and libcurl
by Red Hat Bugzilla 09 Jun '10

09 Jun '10

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Review Request: mingw32-curl - MinGW Windows port of curl and libcurl https://bugzilla.redhat.com/show_bug.cgi?id=499987 Summary: Review Request: mingw32-curl - MinGW Windows port of curl and libcurl Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: Package Review AssignedTo: nobody(a)fedoraproject.org ReportedBy: erik-fedora(a)vanpienbroek.nl QAContact: extras-qa(a)fedoraproject.org CC: notting(a)redhat.com, fedora-package-review(a)redhat.com, fedora-mingw(a)lists.fedoraproject.org Depends on: 499979,499986 Classification: Fedora Spec URL: http://www.ftd4linux.nl/contrib/mingw32-curl.spec SRPM URL: http://www.ftd4linux.nl/contrib/mingw32-curl-7.19.4-1.fc11.src.rpm Description: cURL is a tool for getting files from HTTP, FTP, FILE, LDAP, LDAPS, DICT, TELNET and TFTP servers, using any of the supported protocols. cURL is designed to work without user interaction or any kind of interactivity. cURL offers many useful capabilities, like proxy support, user authentication, FTP upload, HTTP post, and file transfer resume. This is the MinGW cross-compiled Windows library. Koji scratch build: none for now because mingw32-libidn and mingw32-libssh2 aren't in Fedora yet Approved MinGW packaging guidelines are here: http://fedoraproject.org/wiki/Packaging/MinGW -- 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.

1 20

[Bug 513824] New: glib cannot be found while cross compiling
by Red Hat Bugzilla 08 Jun '10

08 Jun '10

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: glib cannot be found while cross compiling https://bugzilla.redhat.com/show_bug.cgi?id=513824 Summary: glib cannot be found while cross compiling 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: 513819 Classification: Fedora Target Release: --- Description of problem: The glib configure macros will not detect glib correctly. Part of the problem is that the \mingw paths are not available inside Wine. The part this bug is concerned about, is that the glib macros require a working touch binary. This can be as simple as: #include <unistd.h> #include <fcntl.h> #include <stdio.h> #include <errno.h> #include <utime.h> int main(int argc, char **argv) { int i; struct utimbuf u; u.actime = time (NULL); u.modtime = time (NULL); for (i = 1; i < argc; i++) { int fd = open (argv[i], O_WRONLY | O_EXCL | O_CREAT, 0600); if (fd == -1) { if ((errno == EACCES || errno == EISDIR) && utime (argv[i], &u) == -1) perror ("touch"); } else close (fd); } } and (if bug 513819 is fixed, which is a prerequisite anyway) it should be placed in c:\windows so that a more complete mingw installation including GNU touch would override it. -- 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.

1 8

[Bug 497492] New: mingw32-libjpeg crash on windows, typedef
by Red Hat Bugzilla 03 Jun '10

03 Jun '10

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: mingw32-libjpeg crash on windows, typedef https://bugzilla.redhat.com/show_bug.cgi?id=497492 Summary: mingw32-libjpeg crash on windows, typedef Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: mingw32-libjpeg AssignedTo: rjones(a)redhat.com ReportedBy: mikkel(a)linet.dk QAContact: extras-qa(a)fedoraproject.org CC: lfarkas(a)lfarkas.org, berrange(a)redhat.com, rjones(a)redhat.com, fedora-mingw(a)lists.fedoraproject.org Classification: Fedora Mikkel Kruse Johnsen <mikkel(a)linet.dk> changed: What |Removed |Added ---------------------------------------------------------------------------- Flag| |fedora-review? Created an attachment (id=341131) --> (https://bugzilla.redhat.com/attachment.cgi?id=341131) Patch for SPEC file, to include jpeg-6b-typedefs.patch Description of problem: Testing with webkitgtk and loading pages containing jpeg images courses a crash How reproducible: Always Steps to Reproduce: 1. Load ex http://arabic.cnn.com in webkitgtk Actual results: Crash Expected results: Should load 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.

2 17

[Bug 510949] New: upgrade to gcc 4.4.0 proper and mingw upstream
by Red Hat Bugzilla 24 May '10

24 May '10

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: upgrade to gcc 4.4.0 proper and mingw upstream https://bugzilla.redhat.com/show_bug.cgi?id=510949 Summary: upgrade to gcc 4.4.0 proper and mingw upstream Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: low Priority: low Component: mingw32-gcc AssignedTo: rjones(a)redhat.com ReportedBy: htl10(a)users.sourceforge.net 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: gcc 4.4 was released on 21st April, a little later than feature fedora 11 freeze; and the mingw people has also released a mingw patch set, with some mingw specific changes a few weeks ago... wouldn't it be nice to upgrade and synchronization with upstream (gcc or mingw)? I also noted that the fedora shipped compiler uses sjlj exception, apparently dwarf2 is the supported model... -- 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.

1 13

Fedora 12: What projects for F12?
by Richard W.M. Jones 20 Mar '10

20 Mar '10

Fedora 11 is nearly in beta, and thanks to some judicious cuts at the end, we made it to 100% feature complete. Thanks to the many people who helped out reviewing packages and testing. What do we want to aim for in Fedora 12? Some ideas - please add your own to this thread. (1) Win64 support (see: http://lists.fedoraproject.org/pipermail/fedora-mingw/2009-February/thread.… ) (2)? Use mingw-w64 project to build 32 bit w32api/runtime, since mingw-w64 seems to be more active. (3) Darwin / OS X support (see: https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00397.html ) (4) Get some of the issues resolved in the packaging guidelines: http://fedoraproject.org/wiki/MinGW/Packaging_issues (5) Expand active members, particularly packagers. I would like to start by having a website which doesn't suck like our current one. (6) Move educational materials to a single place. (7) Have a FAQ. (8) I'd like to have a reasonable Python story. I spent a lot of time trying to get Python and Python libs to cross-compile, without any success. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 68 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

5 20

mingw32-SDL_image and mingw32-SDL_mixer
by Jason Woofenden 17 Nov '09

17 Nov '09

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

4 6

[Bug 513826] New: .pc files for mingw32 library include the sysroot
by Red Hat Bugzilla 09 Sep '09

09 Sep '09

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.

1 13

[Bug 514187] New: compiled mingw files include the sys-root path
by Red Hat Bugzilla 09 Sep '09

09 Sep '09

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.

1 5

[Bug 513825] New: missing i686-pc-mingw32-pkg-config
by Red Hat Bugzilla 29 Aug '09

29 Aug '09

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.

1 11

[Bug 502388] New: Review Request: mingw32-enchant - MinGW Windows Enchanting Spell Checking Library
by Red Hat Bugzilla 12 Aug '09

12 Aug '09

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Review Request: mingw32-enchant - MinGW Windows Enchanting Spell Checking Library https://bugzilla.redhat.com/show_bug.cgi?id=502388 Summary: Review Request: mingw32-enchant - MinGW Windows Enchanting Spell Checking Library Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: Package Review AssignedTo: nobody(a)fedoraproject.org ReportedBy: erik-fedora(a)vanpienbroek.nl QAContact: extras-qa(a)fedoraproject.org CC: notting(a)redhat.com, fedora-package-review(a)redhat.com, fedora-mingw(a)lists.fedoraproject.org Depends on: 502387 Blocks: 499992 Classification: Fedora Spec URL: http://www.ftd4linux.nl/contrib/mingw32-enchant.spec SRPM URL: http://www.ftd4linux.nl/contrib/mingw32-enchant-1.4.2-6.fc11.src.rpm Description: A library that wraps other spell checking backends. This is the MinGW build of enchant Koji scratch build: none yet because mingw32-hunspell isn't in Fedora yet Approved MinGW packaging guidelines are here: http://fedoraproject.org/wiki/Packaging/MinGW -- 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.

1 12

Mac OS X cross-compiler coming soon to a Fedora near you (or maybe not?)
by Erik van Pienbroek 31 Jul '09

31 Jul '09

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.ht… [13]: https://fedoraproject.org/wiki/Licensing:Main#Bad_Licenses

6 30

cross compilation wiki
by Maróy Ákos 29 Jul '09

29 Jul '09

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

1 0

DJGPP crosscompiler chain
by H. Peter Anvin 29 Jul '09

29 Jul '09

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.

1 1

Re: Rewinding the discussion on MinGW+Wine
by Paolo Bonzini 28 Jul '09

28 Jul '09

> 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

5 11

Rewinding the discussion on MinGW+Wine
by Paolo Bonzini 27 Jul '09

27 Jul '09

All, this email will summarize my recent flurry of bugs, all coming from the attempt to use the cross-compilation and Wine environments together. The reason for this attempt is that I had to *develop* a port, not just to compile it; therefore I had to test it. The fact that my particular package runs itself at make time, so that (at the moment) it needs Wine to compile, is secondary and would confuse the matter. Secondarily, I wanted to make sure that the compilation works not just for me, but also for people running native Windows, hence my installing MSYS under Wine. While not something that I want to do day-to-day, this is important to support MinGW as well as possible, and I wanted to reuse as much of the Fedora cross-compilation install in order to achieve it. Now, I can say my attempt succeeded but only after working around what seemed to me like bugs. Maybe they are, maybe not; so, let's look at them. 513819: this is just the fact mingw's sys-root is *not* exported to Wine. Nothing else, nothing more. It is totally unrelated from the fact that Autoconf thinks it's not cross-compiling anymore. The question is one, we can frame it in two ways: 1) Do we want this? If not, why? 2) Or as a meta-question: What relationship do we want between Wine and the cross-compilation environment? Isolation or cooperation? (Of course having one require the other is a no-no). A side note: one reason to do this, is to have a place to install updates that would propagate automatically to all users' ~/.wine directories. Again, maybe it's a good reason---maybe not. 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. There are more ways to fix this: 1) provide a minimal touch binary in mingw32-glib. The problem is where to place it so that the Wine filesystem sees it. Placing it in /mingw requires forward thinking (because MSYS 1.0.11 can be installed in /mingw and we want to avoid conflict with MSYS's touch.exe) and it would require agreeing on fixing 513819 would be a good start, even though probably it would not work for people that already have a .wine in their home directories. 2) provide a minimal touch binary with Wine. Kind of sucks, again because of people that already have a .wine in their home directories. It also feels terribly out-of-place. 3) package MSYS and make mingw32-glib depend on it. Overkill for people that do not require wine, but maybe the simplest alternative. 4) find a way to define a config.site file (coordinating with the Fedora setup.rpm maintainers) and disable glibtest for MinGW (but also gtktest, etc.). 513825: I think there is consensus that mingw32-pkg-config should be renamed or at least both names should be provided. The other discussions in the bug are about: 1) mingw32-configure and mingw32-make. This can be ignored as long as we agree that "./configure --host=i686-pc-mingw32 && make" should be a valid way to compile mingw32 packages. 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. 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. Second, some run-time testcases may detect problems in usage or in the existing installation, as is the case with the glib testcase in bug 513825. Third, they remove the need (for the casual user of the cross-compiler, not for the packager) to define a config.cache or config.site file in case the package does not support cross-compilation. The question is obvious: So, is it a bug or a feature? 513826: This is currently just an aesthetic problem, but if we decide to export the sys-root to Wine it becomes worse, because then it would be very very hard to install pkgconfig under Wine. I think that there is no reason to make it so hard. Installing MinGW and MSYS themselves under Wine is extremely easy, it works, and there are use cases for doing it, even though it may seem a weird thing to do. If you want to free developers from using Windows, allowing them to use MSYS is a good thing. That said, this bug requires touching all packages and the packaging guidelines. So, it's something that maybe you would like to have, but it's nevertheless likely to be postponed indefinitely. I would understand that. That's it; thanks for reading all this. Paolo

2 1

[Bug 513819] mingw directory not visible as a wine DOS path
by Red Hat Bugzilla 27 Jul '09

27 Jul '09

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=513819 --- Comment #12 from Richard W.M. Jones <rjones(a)redhat.com> 2009-07-27 04:48:32 EDT --- > 1. install mingw-gcc, mingw-gtk2, and non-mingw glib Hmmm - I don't really care what happens when you install a "non-mingw glib". Use our mingw32-glib. > 1) when given --host, Autoconf tries to run a program to determine if you're > cross compiling. If you have Wine installed the Windows executable are > registered with the kernel binfmt_misc module and then you're not > cross-compiling, or at least Autoconf doesn't think you are. This is a real bug (with autotools). I've raised it with Jim Meyering some time ago. No one has found a good way to fix it, but the workaround is to kill Wine's binfmt_misc handler before running the configure script. > [Smalltalk] Please take a look at how we built mingw32-ocaml. {BTW this should be discussed on the mailing list, because discussing it in Bugzilla entries is hard to follow, and while there may be bugs, I'm not convinced there is a 1-1 correspondence between bugs and the four Bugzillas that happen to be opened now.} -- 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.

1 0

[Bug 513819] mingw directory not visible as a wine DOS path
by Red Hat Bugzilla 27 Jul '09

27 Jul '09

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=513819 --- Comment #11 from Paolo Bonzini <pbonzini(a)redhat.com> 2009-07-27 02:58:45 EDT --- Wait wait, we're talking about two different things. I'm not talking about packaging GNU Smalltalk for Fedora. I'm talking about developing Windows programs on Linux using MinGW and Wine, and the problems I had with it *while trying it out on GNU Smalltalk*. (Don't be confused by my @redhat.com; this is not something I'm doing for my job). > I'm guessing this is a bootstrapping problem - ie. the Smalltalk > compiler/runtime is written in Smalltalk, so must be compiled > using Smalltalk. Yes, it runs the VM executable to compile the runtime. It would be possible to do as said in comment #9 (the output file is the same for i686-linux and i686-mingw32,some files are even the same for all architectures), or just to BuildRequire the native package and copy bits from its /usr/share and /var/lib into the target package. But let's not get distracted from the main issue, which is about interactions between wine (which makes the i686-pc-mingw32 not really a cross compiler anymore) and the cross compilation environment. Wine and a cross-compiler will not really be installed together by Koji, but they definitely will be together on a Fedora user's machine (such as me). -- 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.

1 0

[Bug 509940] Cmake can't build sdl program with mingw32
by Red Hat Bugzilla 26 Jul '09

26 Jul '09

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=509940 --- Comment #6 from Erik van Pienbroek <erik-fedora(a)vanpienbroek.nl> 2009-07-26 17:59:36 EDT --- mingw32-cmake is only available in mingw32-filesystem-51-1.fc12 (or higher) so only rawhide -- 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.

1 0

[Bug 513819] mingw directory not visible as a wine DOS path
by Red Hat Bugzilla 26 Jul '09

26 Jul '09

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=513819 --- Comment #10 from Thomas Sailer <t.sailer(a)alumni.ethz.ch> 2009-07-26 16:50:26 EDT --- > Actually there's an even more fundamental problem - Wine > requires an X server and a $HOME directory to function, and > for those reasons I never managed to get it to run under > Koji (even using Xvfb). You don't necessarily need an X server, I successfully use wine with a windows console application without X (just unset DISPLAY before calling wine). -- 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.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

mingw July 2009